[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] When does an IdP know that a user hassuccessfully federated with an SP?
> SAML 2.0 includes a number of different components that convey identifiers > from IdP to SP, or, from SP to IdP. The goal here is more than > informational; the interest lies in synchronizing state --- one party is > informing another --- change your internal tables with this > new information. AFAIC, there's only one message that has anything to say about state management of identifiers, ManageNameIdentifierRequest. I would have preferred that nothing in AuthnRequest said anything about it, but at Conor's request I added in a flag that explicitly grants the IdP the permission to create a new one, but that's just state internal to the IdP, not between the entities. > For this to be of value, there must be a way for initiators > to understand when this type of state change has succeeded (or failed) at > the destination. But this part seems to me very unclear or at least > extremely underspecified in the current flows. ManageNameIdentifier is a request/response protocol. > Consider, for example, the AuthNRequest/Response pair. A user visits an SP > and is re-directed to an IdP with <NameIDPolicy> set to AllowCreate. A new > identifier is created and is returned with the Assertion to the SP. > However, there is a failure at this point and the SP does not consume this > identifier. Why does the IdP care? What he did was create an identifier and store it. I don't see that much significance to me as an IdP what the SP chose to do with it. I'm supposed to assume he might store it, and at my discretion, I may need to inform the SP if it changes. That was true in SAML 1.x, we just didn't have any message to do it. It definitely is independent of the "type" of persistent identifier (privacy is orthogonal to this). > The IdP has no knowledge of this failure. From its point of > view, it would presumably allow the user to defederate from the SP in the > very next step. Yes, because "defederation" just means "get rid of this identifier". That's a reasonable thing to require at the IdP no matter what the SP did or didn't do with it. > When such a step is attempted, and the user does arrive at the SP with a > completely unknown identifier, the potential for administrative confusion > seems quite large. Another possibility is that the IdP will may use one of > the Name Identifier update methods to rollover the (non-existent) > identifier at the SP. In either case, the spec says you return a response with a failure status (possibly UnknownPrincipal, but that's up to the SP). No harm done. If he tries a change and gets back an error, the IdP could choose to just dump the identifier altogether, or he could just change it and blissfully ignore the situation. -- Scott