RE: [liberty-dev] Single sign-on and unique name identifiers


To <liberty-dev@emailprotection.org>
From “Wotk Rap” <WotkRap@TrustEngineering.co.uk>
Date Fri, 20 Sep 2002 11:22:55 +0100
Importance Normal
In-reply-to <20020920104425.02D1.E-LIYAN@po.ntts.co.jp >
Reply-to liberty-dev@emailprotection.org
Sender liberty-dev-owner@emailprotection.org

Yes, I can see that the association of the opaque
IDP/SPProvidedNameIdentifier pair with the Principal would be an internal
one and something like your UserID would need to be implemented to maintain
an internal link.  This would then need to be held in the authentication
session object so as to allow subsequent 'seamless' sign-ons.

Having glanced at the code yesterday, I believe that this is how it's done
in the Liberty implementation prototype (the 'IPL') which Sun issued a few
days ago.

I guess this follows from the two uniqueness rules in
[LibertyProtSchemas]3.2.3 (lines 554-557):

* The name identifier MUST be unique across all Principals in the scope of
the service provider-identity provider pairwise relationship.
* The name identifier for the specific Principal MUST be unique across all
service providers with which an identity federation exists with the identity
provider.

I read these rules as follows:

        The IDPProvidedNameIdentifier must be unique across all the 
federations the
IdP knows about

/Regards,

Wotk Rap

> -----Original Message-----
> From: liberty-dev-owner@emailprotection.org
> [mailto:liberty-dev-owner@emailprotection.org]On Behalf Of Li,Yan
> Sent: 20 September 2002 02:54
> To: liberty-dev@projectliberty.org
> Subject: Re: [liberty-dev] Single sign-on and unique name identifiers
>
>
> > On subsequent sign-ons, in which the IdP does not engage the user in any
> > authentication, I assume that the 'authenticated' status is
> derived from the
> > HTTP session which the IdP has established for the user first
> time through.
> > In other words, the SP sends an AuthnRequest to the IdP, the
> IdP sees the
> > authenticated state in the session and sends an AuthnResponse
> back to the
> > SP.
> >
> > How does it know which pair of federated name identifiers to
> put into the
> > <saml:Subject> element of AuthnResponse?
> >
> > The original authentication returned a pair which - as I understand
> > Liberty - is unique to that IdP-SP federation.  The
> > <IDPProvidedNameIdentifier> part of the pair is unique in each
> federation
> > pair.  So, on subsequent sign-ons although the IdP can see an
> authenticated
> > session, how does it know where to find the correct name
> identifier pair?
>
> In your implementation, if the federation information record in IdP holds
> the following fields :
> UserId, ProviderId(SP's ProviderId this case),
> IDPProvidedNameIdentifier,...
> (Key: UserId,ProviderId)
>
> You can obtain the ProviderId from the SP's AuthnRequest and the UserId
> from the IdP's authenticated session.
>
> So, you can search for the only IDPProvidedNameIdentifier from the
> federation information because the keys are decided.
>
> Li,Yan
>
> >
> > Or is the <IDPProvidedNameIdentifier> common across SPs?
> >
> > Wjtk Rap
> >
>
>
>
>
>
>

Partial thread listing:

09/20/2002
RE: [liberty-dev] Single sign-on and unique name identifiers(continued)
 Wojtek Rappak (09/20/2002)
 Conor P. Cahill (09/25/2002)
09/13/2002
[liberty-dev] Identity Provider enrollment?
(Wojtek Rappak)
 Conor P. Cahill (09/16/2002)
08/29/2002
[liberty-dev] Signature verification practices, (Jonathan Sergent)

LEAVE A REPLY

Please enter your comment!
Please enter your name here