[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"?
Wasn't there an animated movie with talking mice called The Secret of NIMH? For us, I guess it would be the Secret of Name Identifier Management and, uh, Hacking... In your suggested <Terminate> wording, the various kinds of sender-imposed state are mentioned in illustrative fashion, which injects a little implementation realism into the normative text without overwhelming it or making everyone do pairwise IDs. That part doesn't seem too squishy. The AllowCreate wording seems quite a bit squishier (but maybe that's because it would benefit from a bit of editorial tightening-up). It certainly gets us a little farther down the path of discussing the desired normative strength rather than wrangling over the meanings of all the terms. Eve Scott Cantor wrote: > 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 -- Eve Maler eve.maler @ sun.com Sun Microsystems - Business Alliances x40976 / +1 425 947 4522
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]