Re: SourceID.Net - SqlFederationhandler.
David Waite <[email protected]> Fri, 29 Aug 2003 13:30:11 -0600
| Newsgroups | gmane.comp.sourceid.sso.devel |
|---|---|
| Message-ID | <[email protected]> |
Cholan NSamy wrote: >Hi David, > >Thanks very much for your reply David. I'm able to understand the >process. I still have some doubts, but before that, regarding logout > > <snip> >And regarding my doubt, let's say my website acts as a service provider. >From my site I need to provide facility for my users to access another >website. Let say for example, similar to yahoo portal I have a website. >So from my site I have to provide access to lets say amazon.com for >online shopping. > >1. How to proceed further in designing the application? >2. What are the necessary things I have to consisder? >3. I tried to create another application apart from sp-sample and >idp-sample. It just throws an error given below. > > With Liberty 1.0 and 1.1,the idea is that different sites can trust one another to behave certain ways. By trusting a site, you can allow it to make assertions (of the SAML kind) from an identity provider to a service provider that a user has been authenticated, or that a user wants to associate their identity with both sites. At least with Liberty 1.0 and 1.1, your users must have user accounts on your identity provider and your service provider(s) in order to be able to sign-in with them. Liberty is about single-sign-on authentication, not one site dictating identity information and authorization to another site. I would recommend reading this document: http://www.projectliberty.org/specs/archive/v1_1/liberty-architecture-overview-v1.1.pdf . In addition to being a good overview, there are a few examples from a user's point of view starting on page 9. If this document doesn't answer all your questions, I will be happy to assist further. <snip> >4. In the account_federations table there are two records for each >account. >cholan Sample SourceID.NET Service Provider idtWMJ5A%3d%3d:: >idtWMJ5A%3d%3d:: >cholan1 SourceID.NET Sample IDP idtWMJ5A%3d%3d:: idtWMJ5A%3d%3d:: > >Can I use cholan account to access another website available in the >trust circle? Or do I have to federate my account with each site >available in the trust circle in order to access it (which will create >another 2 records in the account_federations table I suppose)? >Can you please help me to sort out the problem? > > > Liberty is very user-privacy oriented, so this assertion gives a generated pseudonym representing the user, usually just a random string of characters. In your table below, one of the pseudonyms is "idtWMJ5A%3d%3d::". This actually is meant to be unique per identity provider and per service provider - by knowing the pseudonym that a user is known by on one service provider site, I can't track their identity on another site. So what would happen is that you are authenticated on the sample IDP with an account of 'cholan1', and there is an association with the sample SP with an account named 'cholan'. If you go to the sample SP with the database set up as above, and click the link on the bottom of the page to sign in with the sample IDP, it redirects you to the IDP site and ask for your username and password information. When you submit this, it redirects you back to the original SP site, and provides the SP site with information which says 'the user matching your name identifier "idtWMJ5A%3d%3d::" has just been authenticated', along with various security information. Your SP looks up "idtWMJ5A%3d%3d::" in its database table, and finds out the IDP is talking about the local user 'cholan'. The IDP and SP do not know any account information about the user outside their own domain. If you had a second SP set up, you could go to the second SP and get a login page. Clicking the IDP link on the bottom would redirect you to the IDP to log in, which would immediately bounce back to the second SP saying that you are authenticated. There would be a different string representing you on the second SP site, but you authenticated without entering a username or password. There are other features to make the authentication less intrusive. If you know which IDP or IDPs to try, you can automatically try authenticate the user when they go to a SP. You redirect, this time setting the request as 'passive'. This means that the IDP should always redirect you immediately back to the SP, and not prompt for login information. There are more HTTP requests sent out by the client when first going to a site, but if the user is logged into the IDP already the SP site authentication will appear 'automatic'. -David Waite