[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
I'll follow up this thread for my action item since I captured some of the issues here anyway. I know it's a little long, but I really think we're close here, so please read. > - we might want to strengthen the proviso in the NIM protocol about > transient identifiers not "generally" being used with it I don't know what exactly my point was for saying "typically not" in the spec. It simply makes no sense. So I'm going to argue that it should be strengthened to MUST NOT so implementers don't have to guess. [SAMLCore] Line 2419-2420 Change to: "This protocol MUST NOT be used in conjunction with the urn:oasis:names:tc:SAML:2.0:nameidformat:transient <NameID> Format." I'll deal with AllowCreate subsequently. > - we definitely should clarify whether the SPProvidedID feature in NIM > attaches the alias to "this principal" (the current text) or "this NameID" > (my intent, not precluding or requiring the IdP from attaching it to other > applicable NameIDs for the same principal) Some general NIM notes... Brian correctly notes that even if you start with a global database of X.500 names, supporting IdP or IdP Extended mode means you support NIM. That means your implementation MUST accommodate the SPProvidedID construct regardless of format (excluding transient, as noted above). That of course means per-SP state, no argument from me. That's why the light modes were adopted, in which NIM is not supported. I note that the language of NIM (I'm picturing talking mice here, free SAML mousepad to anybody that gets the reference) is really in terms such that my question above isn't exactly relevant. If an IdP is planning to switch from one format to another, the point of NIM is to tell the SP that by sending it a message to that effect, and of course in that case, sure, the SPProvidedID is going to be preserved across formats because it's really "changing" one NameID into the other, not so much using both at the same time. So I think it's an implementation decision how one would handle multiple identifiers for one principal (used with a single SP). That use case wasn't really captured, but it's probably reasonable to assume that such an IdP would want to attach the alias to all of them. I think this pushes well into implementation guidelines though, and an SP that's making use of this feature is probably only going to handle one NameID at a time anyway. Finally, let me add a note about termination (SP initiated in particular). I just can't see a reading of this that forces the IdP to do anything, and this is not a change from ID-FF. In fact the text is almost exactly the same (and I don't think I wrote that text, even though I edited part of 1.2). Nothing in ID-FF says anything normative about the IdP doing anything, so I left it the same. The problem is, how does that make any sense if AllowCreate is to matter? I think it could be argued (I guess Greg did) that we need to strengthen that text in such a way that it is more directly peered with the use of AllowCreate. Not so much in the sense of requring they be used in tandem, but describing the conditions under which they both apply (and by implication when they don't). So, consider this expansion of lines 2475-2479 based on a concept I'll call sender-imposed state. --- "If the <Terminate> element is included in the request, the requesting provider is indicating that (in the case of a service provider) it will no longer accept assertions from the identity provider or (in the case of an identity provider) it will no longer issue assertions to the service provider about the principal." "If the receiving provider is maintaining sender-imposed state associated with the name identifier, such as the value of the identifier itself (in the case of a pair-wise identifier), an SPProvidedID value, the sender's consent to the identifier's creation/use, etc., then the receiver can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated." "Any subsequent operations performed by the receiver on behalf of the sender regarding the principal (for example, a subsequent <AuthnRequest>) SHOULD be carried out in a manner consistent with the absence of any previous sender-imposed state." --- Now, cynics should note that this re-assigns the problem to the definition of "sender-imposed state". And that the spec imposes some (SPProvidedID), assumes some that could be addressed in a manner not requiring actual state (a pair-wise value), and leaves the rest to implementations (consent-oriented value-add). Is this better? I don't know. > - reaffirming that AllowCreate false was definitely not intended to > preclude use of pre-provisioned identifiers as in many current use cases Let me try some alternative text and carve out transient in the process, also based on the new text for termination, obviously. [SAMLCore] Replace definition of AllowCreate, lines 2123-2129: "A Boolean value used to indicate whether the requester grants to the identity provider, in the course of fulfilling the request, permission to create a new identifier or to associate an existing identifier representing the principal with the relying party. Defaults to "false" ir not present or the entire element is omitted." Replace lines 2143-2147 and insert new text at line 2130 (beginning of the explanatory text): --- "The AllowCreate attribute is used to control the creation of state maintained by the identity provider pertaining to the use of a name identifier or (or any other persistent, uniquely identifying attributes) by a particular relying party, for purposes such as dynamic identifier or attribute creation, tracking of consent, subsequent use of the Name Identifier Management protocol (see section XX), or other related purposes." "When "false", the requester constrains the identity provider to only issue an assertion if such state has already been established or is not deemed applicable to the identifier. Thus, this does not prevent the identity provider from assuming such information exists outside the context of this specific request (for example, establishing it in advance for a large number of principals). A value of "true" permits the identity provider to take any related actions it wishes to fulfill the request, subject to any other constraints imposed by the request (the IsPassive attribute, for example)." "The use of the AllowCreate attribute MUST NOT be used and SHOULD be ignored in conjunction with requests for or assertions issued with name identifiers of the urn:oasis:names:tc:SAML:2.0:nameid-format:transient Format (they preclude any such state in and of themselves)." --- Related changes could be made to the profiles doc where the old AllowCreate text is simply repeated, but I'd just as soon pull it from that profile or refer to core. I think this is more explicit, certainly, but I hope it does a better job of suggesting what the "trigger" is for looking at AllowCreate, the creation of local state. If your implementation provides for no such state in the mere issuance of assertions (dynamic creation of IDs, tracking consent, ...), then you're not going to have to impose that constraint. I also think if that's not sufficient to get the interop people want, another profile around getting and tracking principal consent (which will directly trigger all those "ifs and buts" I wrote in above) is needed and is better than baking it into the lowest level of the spec or the SSO profile. Sigh. Thoughts? -- Scott