[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Strawman proposal on third-party AuthnRequest
I was hoping to have something formal this week, but I'm tied up finishing another draft. Wanted to at least float this for quick discussion. Reviewing briefly, the use case is to enable a SAML entity on the network such as a portal that the client is in contact with to initiate SSO to an SP other than itself. The trick to this is that the protocol does not currently provide an explicit means for a requester/issuer to separate itself from the role of relying party. What we want is for the request to result in an unsolicited response to the actual relying party (no InResponseTo) and for the various AuthnRequest fields such as AssertionConsumerServiceIndex to be interpreted in that context, not in the context of the issuer/signer. There are two immediately obvious ways to do this in browser SSO: - Extensions element - Audience I prefer the former, but for selfish reasons, I have existing work that is going to be based on the use of the Audience element in an AuthnRequest and would prefer not to overload it. Seems less clean that way anyway. Using an extension is only problematic because all extensions in SAML have optional semantics (there's no mustUnderstand). In the case where the binding is SOAP between the client and IdP, a SOAP header becomes another possibility, and that can be labeled mustUnderstand. So, roughly, I'm suggesting an Extensions element like so: <AuthnRequest> <Issuer>portal</Issuer> <ds:Signature>signed by portal</ds:Signature> <Extensions> <samlpext:RespondTo>serviceprovider</samlpext:RespondTo> </Extensions> ... </AuthnRequest> The semantics are simply "if this extension is used and understood, then the responder (if it responds at all) MUST create an unsolicited response to the entity identified by the extension, and any request information pertaining to the delivery of the response or its content MUST be evaluated in terms of that entity, not the issuer of the request". Further, the extension schema would define a boolean attribute: samlpext:supportsRespondTo to be placed in the <SingleSignOnService> element of an endpoint that supports the extension. A third party that supports SAML metadata MUST NOT place this extension in a request unless it is sent to an endpoint that indicates support for this extension. In the context of a SOAP-based binding, I would suggest that the extension here could be sent as a SOAP header with mustUnderstand="true" instead of in the request. This would potentially allow for a portal to initiate ECP by targeting the header at the final recipient. Haven't fully thought through this use case yet. Finally, a brief word about WS-Addressing. I have no idea if it's an alternative we could use for this. Probably so. If it is, some assistance in crafting that alternative proposal would be welcome. I guess if WS-A isn't final yet, we could wait for that as well. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]