[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? Yes. > Web SSO specifically discusses them (SAML Profiles, section 4.1.5), > but ECP profile does not mention it aside from a single > sentence in 4.2.3.7. 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]