Strawman proposal on third-party AuthnRequest

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

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