RE: Name Federation Using Persistent Pseudonyms

[giorgi moniava <giorgimoniava@yahoo.com>]

Hi Conor.

Thanks for reply.

But in my SAML 2.0 deployment context, the users are OK with
the fact that throughout the usage of SAML 2.0 persistent pseudonyms
will be used. So, I think I could just use the WEB SSO profile, and
in the Authentication request elements, indicate that the identity provider should generate a pseudonym for the authenticated users, right?. The linking of users accounts with the pseudonyms is done outside the scope of SAML 2.0 I guess -- again, as I said, users are not needed to be asked whether they want to federate accounts between identity and service providers, since they are OK with it.


--- On Fri, 8/1/08, Cahill, Conor P <conor.p.cahill@intel.com> wrote:

> From: Cahill, Conor P <conor.p.cahill@intel.com>
> Subject: RE: Name Federation Using Persistent Pseudonyms
> To: giorgimoniava@yahoo.com, saml-dev@lists.oasis-open.org
> Date: Friday, August 1, 2008, 4:50 AM
> > I was trying to find a SAML 2.0 Profile, which matches
> the Name
> Federation
> > Use Case, using Persistent Pseudonyms. However, the
> only profile that
> I
> > found is the SAML 2.0 Web SSO Profile. Did I miss
> something? Or one
> has to
> > use the Web SSO Profile in order to perform the Name
> Federation Use
> Case
> > and combine it with some protocol, like Name
> Identifier Management
> > Protocol?
> 
> Today federation typically happens in one of two ways:
> 
> 	* provisioned - when the Relying Party is providing a 
> 	  service to the IdP's organization (such as a payroll
> 	  service for a corporation or an investment house running
> 	  a company's retirement plan) the IdP will typically
> 	  push over federation information via some provisioning
> 	  protocol to establish user accounts and federation
> identifiers
> 	  at the relying party (so, when a user is hired, the HR 
> 	  system at the company would send over the payroll
> information
> 	  to the payroll provider to establish the user's
> account in
> 	  the payroll system).
> 
> 	* on-the-fly - federation information is provided upon 
> 	  initial SSO.   This is the normal mode of operation for
> the
> 	  traditional consumer SSO transaction (typically the user
> has
> 	  and controls accounts at the IdP and the RP and not the
> IdP)
> 	  and it may be used in some enterprise situations that
> don't 
> 	  depend upon the enterprise defining the connection to
> the
> 	  particular user account at the RP.
> 
> 	  When the SSO request comes to the IdP for an RP that has
> not
> 	  been federated with the user, the IdP would typically
> request
> 	  consent from the user to establish the federation
> handle, 
> 	  create a new identifier and send it to the RP.   
> 
> 	  The RP, upon receiving an identifier that it has not
> seen 
> 	  before, will ask the user if they are creating a new
> account
> 	  or did they want to connect this new federation to an
> existing
> 	  account (in which case the user would have to
> authenticate to
> 	  the existing account).
> 
> In both cases, the NameIdentifier management protocols can
> be used to 
> subsequently manage the federation handles.
> 
> Conor