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

[Greg Whitehead <grw@trustgenix.com>]

Just to clarify, the typical portal scenario that we see is where the 
portal is directing users authenticated by an IdP in its own 
organization to SPs in other organizations. In this case, I wouldn't 
expect the portal to be authorized to sign AuthnRequests on behalf of 
those SPs.

-Greg

On Jun 7, 2005, at 9:33 PM, Scott Cantor wrote:

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