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:]
Sent: 27 October 2005
14:34
To: Sarno, Giuseppe [MOP:GM15:EXCH];
Subject: RE: [saml-dev] SAML2.0 SSO
& identity management
From:
Giuseppe Sarno [mailto:]
Sent: Thursday, October 27, 2005 8:58
AM
To:
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.
