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

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

> The portal "push" use case is one example where it would be useful to 
> have a third-party, the portal, create an AuthnRequest that can be 
> delivered to the IdP and ultimately deliver the authenticated user to 
> an SP.

The variant on this that I meant I had "intended to work" is the Shib WAYF,
which is a component that the SP directs its request to with instructions to
"get it to the right IdP". That is actually a simpler case, because the SP
is given the chance to form the request, so there isn't a problem that I can
see as long as its possible for the WAYF to relay the message intact without
corrupting the signature, and I think it can but need to work on proving it
in each case. (Without signing, of course it works trivially.)

The WAYF is not intended to be a visible participant to the IdP (Conor
mentioned something about this briefly, so I wanted to make that point).

This use case without the SP involved is harder, but shouldn't be a big deal
*unless* the requester and the SP are intended to both be represented. This
is maybe possible in an AuthnRequest, but only with additional protocol
features used and profiled, or I think even more likely to work, just using
the proxying IdP model. Maybe it's some extra work, but all the machinery is
already there to do this and constrain it.

So personally, I think the initial concern should be framed as seeing
how/whether undetectable entities can manufacture the AuthnRequest for an
SP. Even signing isn't impossible here, since an implementation could
authorize those silent entities (a trusted portal?) to sign requests on
behalf of an SP. It would be trivial to do this in our SAML trust
implementation, let's put it that way.

> 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.

I don't think it's a lie, if a key is authorized to sign messages on behalf
of another entity. Issuer does not mean signer, as we took great pains to
ensure. Perfect example of why right here.

> 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.

This is the big one because correlation checking is more typically a binding
consideration, so this needs to be looked at across the spec, which is what
I'm willing to look at.

> 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.

As I said to Greg offlist, since RelayState is limited to 80 characters,
it's not this simple any more anyway. Unsolicited responses can use
RelayState, but it's undefined how (defined OOB in other words). I think
this is the same in this use case, but the point about not interpreting
RelayState that way only in conjunction with InResponseTo being empty is a
good one.

-- Scott