I have a requirement where I need to implement SSO between two different websites.
One of the website say www.abc.com is written using ASP.NET and is hosted on IIS 7.0. The second website say www.xyz.com is written using PHP and uses Apache web server. Both the websites uses different databases and uses different algorithms to authenticate the user.
I cannot use a third party SSO as that would mean changing the authentication for both the websites. Wanted to know if this is possible and if yes, what should be the approach?
Thanks in advance...
We could find an alternative approach. Basically, we were trying to address this issue by using two cookies (one each for www.abc.com and www.xyz.com created by each site), but since we were unable to find a way for reading cross-domain cookies, we were stuck up.
But then, I stumbled upon the way forums.asp.net and hotmail works. They use the live.microsoft.com to set the authentication cookie.
Now, we plan to create a third website for authenticating the user. The login forms in both the www.abc.com and www.xyz.com will call the third website to set the authentication cookie. Using this authentication cookie, we will be able to allow user to have seamless browsing across both the websites.
Also, found a very good article on this implementation.
http://www.codeproject.com/Articles/114484/Single-Sign-On-SSO-for-cross-domain-ASP-NET-applic
Related
anybody know is possible to use Persona for SSO purposes for cross site login, where each site is it's own domain? Very similar to 37signals and how they set up basecamp, Highrise and campfire.
Would like to have user create something similar to a 37 signals ID.
thanks.
If all of your sites share a common domain (e.g. foo.example.com and bar.example.com) then you could have a login server (say login.example.com) that sets an example.com-wide cookie that each subdomain can use.
For cross-domain sites, there has been a realm proposal but it's not currently being worked on.
im am currently using a evaluation version of the PingFederate software and reading documentation all the time but still struggling to understand how i can create multiple IdPs for my SP.
I am hosting services, and setting up PingFederate as an SP. Currently in my tests i have one single IdP and all is working fine... I have set up the IIS Agent to intercept traffic and it redirects to my SP to start SP initiated SSO and that all works ok (coming in on the default startSSO url).
However, im struggling to see how i can configure the system for multiple IdP's and was wondering if someone could give a high level overview or point me at some documentation?
I understand that i have to configure the second IdP connection and i somehow need to use the PartnerIdpId URL parameter to distinguish which IdP the user is sent to.... but im not sure where i do that control/configuration for routing to different Idps? Do i need multiple agents on my IIS box that listen on different urls and can then forward the requests themselves to the right SP urls (/startSSO?partnerIdpId=XYZ) within the agent config file?
Thanks for any help,
Craig
I think your question is more around how do you trigger SP-Init SSO for multiple IDPs when using the IIS Integration Kit.
As you've figured out, as the Service Provider, you can create multiple IDP Connections (each with its own unique EntityID). You trigger SP-Init SSO by calling the /sp/startSSO.ping Application Endpoint and pass in the appropriate PartnerIdpId value that matches the EntityID of the IDP you wish to issue the AuthnRequest. You can do this one of two ways -- either hard-code the URL into the IIS Kit pfisapi.conf file so that a single entity is called each time (not the best solution) or you can manually host the URL on a page that isn't protected by the IIS Kit. Unfortunately, a lot of this design decision comes down to how your IIS application is designed and the choice of integration kit.
I would suggest talking through this with your RSA as they can help show you the pros/cons of each integration kit to match up what works best for your application & customers.
HTH,
Ian
PS
I work for Ping.
I would like to have some guidance regarding how to handle authentication for my restful service to be able to support a couple of different scenarios, see included image?
I've been thinking about this problem for a couple of week without finding a solution for all of the cases and even if I'll make trade offs I'll be running into problems
If we skip the Mobile application and the use of Curl, there's no need to expose the service to the public and it would be possible to use basic authentication for the server to server communication. But we'll still need to put some responsibility at the "Web site for ninjas only" to pass the (openid authenticated user) as part for the http header?
In this case we're using Google apps to manage credentials for our co-workers and I don't like the idea to manage another username/password within the service if it's possible to avoid.
Is there any sustainable solution for my dreams, so that I can build awesome features for the client and implement a tight api that manages the authorization for different resources for a specific user?
Another possible to solution might be to integrate the service with the openid provider, but then I'll have problem with passing the user from "Web site for ninjas only"
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?
I've seen many questions about restful-authentication but I'm wondering what strategies are being used to keep browser user agents stateless while authenticating to a RESTful web-service.
Doing it with a custom REST Client is "easy": We can use Basic Auth, Digest, OAuth or roll your own (custom headers, tokens, signatures etc). Thus, for machine to machine we are pretty much covered but I'm only interested in authentication with everyday browser user agents (IE, Firefox etc). For example JSON is out since the browser can not render / use it ;)
Here are some of my thoughts in terms of browser limitations:
AFAICS there is no way for a browser to send custom headers such as those used by OAuth? (Right?)
I have a feeling that one should be able to have a login page (html+ssl for example) where the user does a login. (No Basic auth) The browser then captures a token(s) and passes it back the server with each request. The problem I have with Basic Auth is that I do not have a “nice custom login page”. Is the current authentication mechanism to extensible that we can keep it restful?
I'm careful in breaking / relaxing REST constraints because of the risk of loosing the benefits of scalability.
A similar answer here but I have a special case against cookies : (without going to much detail): The way browsers currently work in using cookies is out of the question since the server is in control of the cookies. ("Set-Cookie" header from server side state). The client does not understand or interpret the contents of cookies it's fed and just returns it. The problems is that the client is not in control of the cookie. Thus, yes we can use cookies in a restful way in "custom/machine to machine clients" but it's not the way browsers implements it.
What strategies and best practices are there that you have been using and what are your experiences? Any extra comments?
I think the browser limitations you mention are essentially insurmountable for most use cases. Our personal solution is to have a lightweight non-RESTful layer presented to the user which contains a custom REST client; for example, for JavaScript apps we expose a server-side REST client via JSON-RPC.
If you are using an apache web server, you might want to take a look at this document.