[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"?
Sorry for taking so long to respond to this. Comments are inline below. Apologies for the thoughts being a bit disorganized. > "This protocol MUST NOT be used in conjunction with the > urn:oasis:names:tc:SAML:2.0:nameidformat:transient <NameID> Format." That certainly clarifies that particular issue. > 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 can sort of see where this is going but the implications are not clear. Some questions jump to mind: Does being an IDP basic or extended imply that you must keep per-SP state about the IDP side of the identifiers too (in order to honor AllowCreate)? Maybe keeping state is too strong as there way be ways to honor AllowCreate w/out actual state but I think I gravitate to describing it as keeping state because that that's what the external behavior of the IDP looks like. Does being a light IDP mean that you must ignore AllowCreate? Can a light IDP issue identifiers with the 'persistent' format? If so, is AllowCreate meaningful in this situation? Scott discusses the concept of "sender-imposed state" below. Is the IDPs support of sender-imposed state dependant on its operational mode? If so, is operational mode inferred from the available endpoints in metadata? If not, what is it based on and how is an SP to know how the IDP will treat AllowCreate an NIM? > 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. A little off topic here but I don't see how NIM can be used to change the format of an identifier - the <NewID> element in a <ManageNameIDRequest> is of type string. Seems like all you can do is change the value. > 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." It sounds like it is still at the IDPs discretion as to if they want to maintain such sender-imposed state. It seems a bit of a contradiction that there are situations where a sender can impose state but cannot know if the receiver is in fact honoring that state. Maybe I'm missing something here - I don't know. > --- > > 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. The wording feels better on first read but I'm not sure it doesn't just push the problem to a different level. > 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. Who decides if it is not deemed applicable to the identifier? If this decision isn't normative, then different implementations will have different interpretations and that can lead to interop problems. > 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. If the rules are the same, I think it'd be much better to just pull it and refer back 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. To me, what is important is what behavior the SP can impose on the IDP with the attribute. How is the SP to know if the IDP implementation provides such state in the mere issuance of assertions? Is it completely arbitrary and at the discretion of the IDP? Is it a function of name identifier used? Is it a function of the operational mode (light or basic/extended)? Or is it something else? All of the ID-FF implementations I've seen used the Liberty equivalent of the AllowCreate attribute quite explicitly on the SP side. The SP would only tell the IDP to allow creation of an identifier if the principal had authenticated locally at the SP and had not previously federated his/her identity with that IDP - so the SP knew it was linking accounts as a result of the SSO. As far as I could tell it wasn't about user consent it was about having a little control over the state of linked user accounts. > 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. The spec is about identity so I do think it is appropriate for clear normative rules about how identity is represented and managed to be at the lowest levels of the spec. -Brian