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