RE: [saml-dev] SAML2.0 SSO & identity management

["Giuseppe Sarno" <gsarno@nortel.com>]

Title: Message

Hi thanks,

 

The other thing strange (to me anyway) (also looking at 2136)

is that the NameIDPolicy format has persistent/transient/encrypted and etc..

This means I can either have a persistent ID or an encrypted ID in the resulting Assertions, which I think one shouldn't preclude the other.

 

In theory the SP might want to ask for a persistent ID and being encrypted.

Now I assume this can be achieved in different other ways (may by MetaData as you mentioned below) though it is probably not the right place (Format) to put together this information.

 

I mean Persistence (has nothing to do with the Format - and that's probably the confusion with Qualifier) is a concept encryption is another.

 

Sorry this is not probably the right place for this discussion  but wouldn't you agree on this ?

 

Giuseppe.

 

-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: 27 October 2005 14:34
To: Sarno, Giuseppe [MOP:GM15:EXCH]; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] 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

 

Hi,
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 ?

Giuseppe.