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

["Nick Ragouzis" <nickr@enosis.com>]

Should IDP Proxying be added to the list of things that
might change to support the third-party AuthnRequest use case?

I don't know the impetus for the current text's transition
from ID-FF1.2's focus on the principal**, but now the license 
for an IDP to issue a proxy AuthnRequest is only granted if an 
IDP receives an AuthnRequest from a _presenter_ that it hasn't 
already authenticated or can't do so directly.

In SSO Profiles, the presenter is the principal, and the current
IDP Proxy rules create a more secure context. But the third-party
case breaks that correspondence.

Or perhaps IDP Proxy just isn't available in this case ... the 
third-party AuthnRequest request would just entail the SP (as 
initial presenter) trying all candidate IDPs to find one that 
actually can, directly, authenticate the principal?

(** The shift is nearly complete in Core, with the lone flash
back being the explanation for StatusCode ProxyCountExceeded,
which still refers to authenticating the principal (not
presenter) directly.)

--Nick

> -----Original Message-----
> From: Greg Whitehead [mailto:grw@trustgenix.com] 
> Sent: Tuesday, June 07, 2005 11:03 AM
> To: SAML WG''
> Subject: [security-services] Third-party AuthnRequest use case
> 
> 
> 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.
> 
> This sort of works with the existing AuthnRequest, but I'm 
> not sure it 
> was intended and there are a few issues:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -Greg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>