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: Message
this will work and makes perfectly sense to me.
I didn't realized the NameId had a similar construct of the NameIDPolicy.
Intact I was right that kind of info should attached to the subject which in truth is already.
Thanks again.
-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: 27 October 2005 14:16
To: Sarno, Giuseppe [MOP:GM15:EXCH]
Cc: saml-dev@lists.oasis-open.org
Subject: Re: [saml-dev] SAML2.0 SSO & identity management

Giuseppe Sarno wrote on 10/27/2005, 8:57 AM:

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

SPNameQualifier would be used for defining the "namespace" of the identifier returned.

...:persistent is one of the settings for "Format" in the request

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.

This isn't exactly the case.   In SAML, the SP can say what it would like, but it is ultimately up to the IdP to determine if the SP gets what it wants -- the IdP is the control point for user consent and permissions (so, for example,  a "good" IdP may allow a user to configure that a particular SP always gets a "transient" identifier). 

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 ?

Based upon internal settings.  Note that this is also the case when the SP does not specify the NameIDPolicy on the request (which, in many cases, it will not as it is an optional field and the SP would leave the decision to the user/IdP).

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

The fields within the NameIdPolicy are attached to the NameID in the Subject of the response (e.g. the NameID has a <Format> element as well as an <SPNameQualifier> element).  So the IdP can place this information into the Subject in the assertion issued in response to the request.


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