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: [saml-dev] SAML2.0 SSO & identity management

Title: SAML2.0 SSO & identity management

From: Giuseppe Sarno [mailto:gsarno@nortel.com]
Sent: Thursday, October 27, 2005 8:58 AM
To: saml-dev@lists.oasis-open.org
Subject: [saml-dev] SAML2.0 SSO & identity management


I'm looking at the identity federation model proposed in the SAML 2.0 specs of which
an example is provided in the Technical overview and I have the following question:

SSO SP initiated:

During a Authentication Request the SP could include the NameIDPolicy with SPNameQualifier = persistent, which means that the

[RSP] Actually, it would be the “Format” attribute of the NameIDPolicy element that indicates a persistent name identifier is being “requested”, not SPNameQualifier.

SP is asking for a persistent (well known and agreed identifier shared between SP and IDP) identifier for the subject.

This in few words means that in the SAML model the SP drives this. I mean is up to the SP to decide whether the identifier required is persistent or transient.

[RSP] Well, not really.  Lines 2130-2132 in the core spec are relevant here. The IDP determines whether the request is “acceptable” and can either return an existing persistent identifier, can create a new one for use with the SP (see the “AllowCreate” attribute), OR return an error. Local IDP policy could be set to indicate that persistent identifiers aren’t supported with that IDP or that they aren’t permitted to be used with that SP, etc. 

Now though the problem is in the case of IDP initiated requests,
since the model is based on the IDP returning an AuthResponse without having received a previous Auth request.
How can the IDP decide which Policy to apply ?

[RSP] Again, the IDP needs to have local policies defined to deal with this. 

The IDP can also compare it’s local policies with an SP’s metadata.  The SPSSODescriptor is based on the abstract element SSODescriptorType.  That element contains optional <NameIDFormat> element(s) where an SP can indicate what formats it supports.  But note that not all implementations will necessarily include this element even if they support metadata.  If metadata isn’t used, then out-of-band agreements are usually required.

It feels right to me that this data NameIdpolicy should somehow be attached to the Subject also in the Response.   

[RSP] Why?

any idea of how this works ?



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