I have some questions about a few inconsistencies this profile.
- 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:
- 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 Format of
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent”. 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.
- Line 2435 in saml-core-2.0-os.pdf states that the
SPProvidedID attribute MUST be provided in all communications with the SP
if the NewID came from the SP (essentially providing an alias for the
NameID), but there is no restriction on Name ID Format stated (except for
transient, mentioned elsewhere).
- Some of the security-services mail list messages have
stated “only supported for persistent identifiers”. I’ve
seen other message which stated that SPProvidedID is there to avoid the
need to index based on a NameID which was generated or provided by an
IdP. Both of these imply a Name ID Format of
“persistent”. However, I do believe I also saw messages
which stated that “persistent” sometimes meant “an ID
which is persisted in some kind of storage”, rather than the
persistent Name ID Format.
- The Name Identifier Management profile may apply to all
Name ID Formats (depending on the outcome of #1), but does the SPProvidedID
apply to all Name ID Formats or only to the “persistent”
format? That is, can an SP create an alias *only* if the Name ID has a Format of “persistent”?
- We have item 1. b. above, which seems to keep it open
for Name ID Management.
- We have item 1. a. above, in which this is only
mentioned in the definition of the “persistent” Name ID
Format.
- We have item 1. c. above, specifically “generated
or provided by an IdP”, which may imply a Name ID Format of
persistent.
- Does SPProvidedID specify an alias for “this
principal” or “this NameID”? 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.
- 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 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? It seems like “this NameID” has less of an impact,
but a moved user would require another change in their alias.
- Is support for SPProvidedID really a MUST? Some
state for this must be maintained?
- 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.
- 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”.
Thanks in advance.
-Mark
|