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] ECP client redirects


On 10/8/15, 10:41 AM, "John Dennis" <jdennis@redhat.com> wrote:

>I'm trying to clarify the following 2 questions (1 & 2):
>
>1) Is an ECP client required to be able to handle redirect responses 
>from an IdP after posting an AuthnRequest to the IdP SOAP binding endpoint?

Not from the IdP, but as a practical matter my SP is designed around use of cookies and redirects and my use of ECP in Shibboleth assumes redirect support on that end. That's all out of scope because of the steps after the final Response to the SP are out of scope.

>It would help to have context for the question. We have an IdP
>implementation whose architecture relies on redirecting to it's own 
>endpoints while it is processing an AuthnRequest, the redirect is not 
>internal, it relies on the browser to follow the redirect. This was 
>never an issue for Web SSO using the HTTP-Redirect or HTTP-Post bindings 
>because browsers happily followed the redirect.

That's not exactly "illegal" in ECP either simply because the authentication step in ECP is not defined. So if you want to take the strict view, there's nothing in the spec that says that authenticaton interaction couldn't be redirect-based. In practice, it's something to avoid doing if you're the IdP.

Fundamentally, ECP has non-interoperable aspects to it that have to be profiled to be 100% interoperable. Like a lot of fat client approaches, that's a reason it's problematic.

>However an ECP client is supposed to be a much less capable HTTP client 
>and ECP unlike Web SSO does not inherently have the concept of redirects 
>(with the exclusion of the final SP response).

I would say that an ECP client is a *more* capable HTTP client, it just isn't obligated to render HTML.

>One way of interpreting the IsPassive flag is the IdP is supposed to
>immediately respond with a SAMLResponse, if this is the case then 
>performing redirects before responding with a SAMLResponse would appear 
>to violate that.

No, IsPassive has nothing to say about redirects unless they cause user interaction. IsPassive and ForceAuthn are both impossible to express in terms of HTTP requirements.

-- Scott



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