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

["Scott Cantor" <cantor.2@osu.edu>]

> 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.

Allow doesn't mean require. If we agreed on what was required, there
wouldn't be a debate. AFAICT, there is nothing that precludes a light
implementation from honoring AllowCreate, unless the identifier in question
cannot be presumed to exist already. And everybody seems to agree that there
is no way to know that "in the spec".

So, I claim it is a *deployment* question whether AllowCreate can be
ignored, in light mode or anything else. And some implementations might or
might not be advanced enough to cover all possible deployment scenarios.

To add to that, a light implementation is able to support the persistent
format if it chooses to. It might need to do so in a sub-optimal way (i.e.
by deriving the pair-wise values by hashing over the IdP, SP, principal
name, and salt). That has lots of drawbacks, but it is not "wrong" or
somehow invalid.

(NIM of course is not supported in light, since that's the definition.)

It is perfectly reasonable, IMHO, for such an implementation to say that
AllowCreate means nothing. It's also reasonable for such an implementation
to say the opposite, or make it a deployment choice, because it depends on
the implementation and the deployment whether a "relationship" is being
"created" or not.

I saw it as knobs on each end that, when turned in a compatible way,
supported a certain set of behaviors. Turned in other ways, they might have
no effect, or cancel each other out.

As it stands today, I have no argument with Brian's point that there's not
enough required behavior to ensure that a given pair will all support the
behaviors in a manner allowing them to act in concert. That doesn't mean SSO
will break, but it means any assumptions about what's happening behind the
scenes after the user is sent to the IdP are not justified.

> 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.

I don't see how you can on the one hand allow for pre-provisioned
identifiers and on the other presume that AllowCreate=true (or Terminate)
requires state change. NameID changes, OTOH, is one case I can see where
there's just no doubt, yes, it's stateful, but since it happens *after*
AllowCreate would apply, it doesn't help.

I guess that's where I'm pushing back the most against the idea that there's
a simple fix. If this is the fix, then there's no problem to begin with
because you're saying AllowCreate's interpretation at the IdP "depends on
how the identifier is being managed". And that's what I'm saying.

-- Scott