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