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

["John Hughes" <John.Hughes@PACONSULTING.COM>]

If we can sort out the details in a timely fashion then perhaps I could add this into the Federation use-cases section of the Tech Overview.

Scott and I had an exchange of emails as to the use cases to have in the Tech Overview - this type of use case was a candidate.  However Scott persuaded me not to include it because of having to sort out details like this.


John

> -----Original Message-----
> From: Greg Whitehead [mailto:grw@trustgenix.com]
> Sent: 07 June 2005 19:03
> 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