[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"?
> 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