RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?

[prateek mishra <pmishra@principalidentity.com>]

Re: AllowCreate, I would propose a discussion of whether an AuthNRequest with AllowCreate value set to TRUE be a no-op in the IdP Lite operational mode.

 

The main idea in the lite modes is that this type of stateful behavior ("writing to an enterprise database") is excluded and therefore the lite modes can easily be added to directories, enforcement points etc. without worrying about additional enterprise IT plumbing. It seems to me that AllowCreate=True does require non-local or enterprise-wide state change and falls into the same category as NIM.

 

If there is support for this position, I can try to figure out some text for the conformance document that characterizes this aspect of IdP Lite

 

- prateek.

Scott Cantor <cantor.2@osu.edu> 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 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 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 ) 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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php