RE: [saml-dev] Seeking clarification of Name ID Management Profile

["Palmer, Mark" <Mark.Palmer@ca.com>]

Thanks for the reply.

I have a few other questions/comments I've inserted below in our
previous exchange.

I've also thought of the following question.

When SPProvidedID is being returned in an Assertion as part of the
NameID, I would imagine that the SP needs to use this value rather than
the value of the NameID itself when attempting to locate the user (since
it requested this mapping).

Isn't it possible that an Assertion might be passed on to a different SP
through a mechanism other than Web SSO (say Assertion Query/Request
Profile)?  In this case, how would the SP processing the Assertion know
which NameID value to use?

I had thought that, perhaps, the SPNameQualifier could be included so
that the SP would know if the SPProvidedID should be used, but
SPNameQualifier states that it can only be provided for certain NameID
Formats.

Did I miss something?

-Mark

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, June 20, 2006 10:14 AM
> To: Palmer, Mark; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] Seeking clarification of Name ID Management
> Profile
> 
> > 1.	Is the Name Identifier Management profile meant to
> > support all Name ID Formats (barring transient, which is
> > forbidden due to its one time use definition)?  I suspect
> > that this is true, but is difficult to confirm based on the
> > following inconsistencies:
> 
> Yes, it doesn't matter what the format is, apart from the outlier.
> 
> > 	a.	Section 4.5 of saml-profiles-2.0-os.pdf states
> > ".an identity provider has exchanged some form of persistent
> > identifier for a principal.".  Initially I took this to mean
> > "a Name Identifier with a
> 
> Poor choice of words, but nobody could agree to just use the word
> "federated" for the format name, so we got stuck with a word that also
is
> the only good adjective to use in profiles. We should change profiles
to
> something more awkward but non-colliding, like "long term".
> 
> > This was partially corroborated by the definition of the
> > persistent identifier in section 8.3.7 of
> > saml-core-2.0-os.pdf, which states one line 3333:  "The
> > element's SPProvidedID attribute MUST contain the alternative
> > identifier of the principal most recently set by the service
> > provider or affiliation, if any.  If no such identifier has
> > been established, then the attribute MUST be omitted."  The
> > other Name Identifier Format definitions do not state this,
> > so it would seem this was the only supported Format.
> 
> That's also probably a mistake. The SPProvidedID feature really has
> nothing
> to do with the persistent format, it can apply to any long term
format.
> 
> > 3.	Does SPProvidedID specify an alias for "this principal"
> > or "this NameID"?
> 
> NameID. The other interpretation is too broad for the spec, since it
> implies
> knowledge at the IdP of all the possible ways to refer to a principal.
> 
> > I'm trying to determine if there is any
> > impact if the Name ID happens to be common to a group (and is
> > therefore used by multiple users - similar to an
> > Affiliation), and the user is moved from one group to
> > another.  Is the Name ID supposed to follow the user?  I'll
> > admit this is may be a somewhat remote use case.
> 
> It definitely wouldn't follow, but that's not really what I was
getting
> at...I mean it doesn't apply to each of the formats I might be able to
go
> by
> as a user (email, Kerberos, persisten, DN). It just attaches to the
> particular representation in use.
> 
> >
> > 	a.	I saw an item on the security-services mail
> > list that stated that "this NameID" was the original intent,
> > but the text in the specifications still says "this
> > principal".
> 
> I thought we had an errata there, but I'm not finding it.
> 
> > I see the impact of this as being truly
> > different.  If a SPProvidedID maps to the user, and the user
> > is part of a group or affiliation, and then the user switches
> > groups, what would the behavior be?
> 
> You're out of scope, there are no such thing in SAML. Affiliations are
not
> what you're talking about.

I believe you answered this above with "it definitely wouldn't follow."
The use case is where the same NameID is used for a group of users (not
an affiliation).  NIM is used to map the ID for a specific user in the
group (defined on the IdP).  After the mapping exists, the user is moved
to a different group, and therefore the NameID is different and the
mapping is invalid.  I would guess that a NIM request would need to
indicate the change and the SP would need to redefine the alias again
using NIM.

> 
> > 4.	Is support for SPProvidedID really a MUST?  Some state
> > for this must be maintained?
> 
> It's a MUST for conformance. Beyond that, it's only required that you
do
> what the messages ask or return an error.

I thought I had seen an email posting that stated that something like
95% of SP's would not be using this feature, but when I was looking for
it later I couldn't find it.


> >
> > 	a.	This could require additional per-SP
> > persistence per NameID and/or per principal (depending on the
> > answer to #3) on the IdP for maintaining state.
> 
> Supporting it for one format already does, and since all the formats
are
> MTI, it doesn't really matter from a conformance point of view.
> 
> > 	b.	The wording in the specifications (and the
> > errata) in regards to Termination reads something along the
> > lines of "If the provider is maintaining state.", which could
> > be interpreted as either "in the case with SPProvidedID was
> > used in a <ManageNameIDRequest> from the SP" or "if support
> > was implemented".
> 
> That's a conformance issue. If you choose not to be conformant, than
> you're
> off the hook. But you also need to be looking at the errata here,
because
> I
> know that wording was adjusted a bit when the AllowCreate issues came
up.
> There isn't much in errata pertaining to your questions, but always
look
> there first. I wish there was a red line spec, but there's not.

I went through the errata pretty well, and it resolved a few things
before a posted (I was concerned about the changing the Format of a
NameID until I saw the errata stating it was forbidden).

> 
> -- Scott
>