RE: [security-services] Third-party AuthnRequest use case

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

Having reviewed the specs, I'd suggest these errata to clean up
interoperability for this use case. This assumes no significant protocol or
schema changes, as was discussed on the list.

> 1) The AuthnRequest issuer is expected to be the SP to send the 
> Response to. This means that a third-party issuer has to lie about who 
> it is, precluding the use of request authentication (signing). Note 
> that if the SP advertises that it signs AuthnRequests, IdPs are 
> justified in rejecting unsigned requests.

Signing is obviously only possible in this use case if you lie about who the
request issuer is. In this case, "lie" means that an IdP has to be able to
authorize the portal (or whomever the issuer actually is) to sign on behalf
of the SP.

This doesn't require any spec changes (we say nothing about how you decide
whether a signing key is valid for some entity), but implementation guidance
is probably warranted at some point. I doubt you'd want to authorize the
portal to sign any other messages on behalf of the SP, so a blanket
authorization via, say, metadata, is probably overkill.

Otherwise, we simply have to forgo signing or we have to change the schema.

> 2) The Response's inResponseTo won't make sense to the SP. I believe we 
> have text that talks about receiving a Response without an inResponseTo 
> (an unsolicited response), but we don't discuss the possibility of 
> receiving a Response with an inResponseTo that refers to an 
> AuthnRequest that the SP didn't generate.

The most significant issue and affects multiple parts of the spec. This
actually bothers me more than the signing, because of the subject
confirmation data, which is where InResponseTo actually gets used in this
profile. Unfortunately, there's no real answer except to note that SPs may
need to disregard this. I don't think that's a good solution, but it's all
there is.

In core, the protocol language is lines 1542-1547, which define
InResponseTo. That language should mostly be able to stay the same, because
it's just there to tell the IdP what to insert in the field. And it has no
real choice but to do that. The other language in core is at 729-732 and is
also vague enough that it should stay.

Bindings actually has nothing about InResponseTo. Maybe it should, to note
that the HTTP bindings have this potential issue, but as of now, nothing
would change there.

Profiles has several spots in the profile that mention InResponseTo, but
most of them would probably stay as is, because they're just instructions to
the IdP about what to put there.

I would guess that the cleanest way would be to attach this use case to the
existing language around unsolicited responses. Maybe something like adding
to lines 580-582:

"Verify that the InResponseTo attribute in the bearer
<SubjectConfirmationData> equals the ID of its original <AuthnRequest>
message, unless the response is unsolicited (see Section 4.1.5), in which
case the attribute MUST NOT be present. The service provider MAY ignore this
attribute if it wishes to permit third parties to manufacture an
AuthnRequest on its behalf without its intervention (also see Section
4.1.5)."

And then replace section 4.1.5 (lines 605-616) with:

"4.1.5 Unsolicited Responses and Third-Party Requests

An identity provider MAY initiate this profile by delivering an unsolicited
<Response> message to a service provider. A third-party, such as a portal,
MAY initiate this profile by creating and issuing an <AuthnRequest> message
on behalf of (and claiming to be issued by) a service provider.

An unsolicited <Response> MUST NOT contain an InResponseTo attribute, nor
should any bearer <SubjectConfirmationData> elements contain one. If
metadata as specified in [SAMLMeta] is used, the <Response> or artifact
SHOULD be delivered to the <md:AssertionConsumerService> endpoint of the
service provider designated as the default.

A third-party request is not distinguishable from an ordinary request, and
so the identity provider will process the request as defined by this
profile. However, service providers wishing to support this use case would
need to disregard normal processing rules around the InResponseTo protocol
and subject confirmation data attributes, and SHOULD have policies regarding
which identity providers from whom they will accept such responses.

Of special mention is that the identity provider or third party MAY include
a binding-specific "RelayState" parameter that indicates, based on mutual
agreement with the service provider, how to handle subsequent interactions
with the user agent. This MAY be the URL of a resource at the service
provider, although this is constrained by the maximum length of the
"RelayState" value. The service provider SHOULD be prepared to handle
unsolicited or third-party-initiated responses by designating a default
location to send the user agent subsequent to processing a response
successfully."

> 3) Handling RelayState. I'm not sure where we stand on using RelayState 
> in unsolicited responses to convey TARGET information, but I think the 
> current language is weak enough that it really can't be expected to 
> work... it certainly won't work if SP's are keying on an empty 
> inResponseTo to decide that RelayState might contain a TARGET.

I think the language above addresses this, but in general my feeling is that
TARGET won't fit in RelayState anyway. The SP should be prepared for any
response to come in without any further information about what to do with
the user. A simple example of why that's needed anyway is that many SPs
probably use cookies to remember what to do without using RelayState at all,
and if that cookie disappears, well...same story.

-- Scott