[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 Format of > urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". 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. > 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. > > 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. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]