OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Name Federation Using Persistent Pseudonyms



> 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

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]