OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] Questions about ECP Profile

> 1.	Are unsolicited responses supported for ECP?


> Web SSO specifically discusses them (SAML Profiles, section 4.1.5), 
> but ECP profile does not mention it aside from a single 
> sentence in

ECP is an adaptation of the earlier profile, and references it, rather than
repeating it.

> It is also unclear whether both HTTP 
> GET and POST requests need to be supported for an unsolicited 
> response if it is in fact supported (most ECP requests must 
> be done using POST since a SOAP message is being sent, but an 
> unsolicited response could be handled with a GET - the 
> question is whether a POST also needs to be supported). 

The predicate message that results in an unsolicited response isn't defined
by SAML, it's analogous to the old SAML 1.1 presumption that SSO "just
happens by magic". The magic isn't defined.

In SAML 2.0, *usually* one would assume that you trigger an unsolicited
response by spoofing an AuthnRequest from the SP. In the case of ECP, that
probably means a SOAP-bound request.

> Can it be assumed that the ECP MUST retain a copy 
> of the HTTP request (SOAP message containing the 
> <AuthnRequest>) to be resent to the identity provider in the 
> event that an HTTP response requesting authentication has 
> been received by the ECP? There is not much definition 
> regarding the requirements and behavior of an enhanced client 
> in this area, and if the identity provider needs to redirect 
> the ECP to an authentication URL the posted SOAP message 
> cannot be included in the redirect. 

This entire step is non-interoperable in SAML 2.0. ECP was originally
designed in Liberty for cases where the IdP and EC are generally one
implementation, either in a gateway or supplied by one vendor. This wasn't
adequately fixed in SAML.

Liberty ID-WSF 2.0 includes a new ECP profile that defines the EC->IdP step
using the WSF specs so that the client can be interopable with the IdP, but
SAML 2.0 alone doesn't specify enough to make that possible, unfortunately.

Directly answering your question, though, I would say no. The IdP is
probably the one who needs to preserve state if you have a multi-exchange
dialog with the client.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]