Why is HTTP-POST binding support not claimed by default by idP?

[huwi...@champlain.edu]

I eventually discovered that in order to claim support for HTTP-POST, I had to specify that via SingleSignOnServiceBinding, but I'm wondering why is it that by default HTTP-POST support is not automatically claimed?  I'm trying to understand this because the lack of this causes delays while integrating with a third party SP.  Their developers noticed lack of HTTP-POST support claimed and flagged it as a bug.

Technically, is HTTP-POST support nowadays considered implicit?

Supporting only HTTP-REDIRECT and not HTTP-POST as the metadata seems to indicate wouldn't even technically work on our server because SAML assertions sent for response and SLO are too long and our web server crops them off after a certain length.

Thanks in advance for any insight into this matter.

Matt

[Tom Scavo]

On Fri, Jul 14, 2017 at 10:37 AM, <huwi...@champlain.edu> wrote:
>
> I'm wondering why is it
> that by default HTTP-POST support is not automatically claimed? I'm trying
> to understand this because the lack of this causes delays while integrating
> with a third party SP. Their developers noticed lack of HTTP-POST support
> claimed and flagged it as a bug.
>
> Technically, is HTTP-POST support nowadays considered implicit?
>
> Supporting only HTTP-REDIRECT and not HTTP-POST as the metadata seems to
> indicate wouldn't even technically work on our server because SAML
> assertions sent for response and SLO are too long and our web server crops
> them off after a certain length.

You're confusing inbound binding support with outbound binding
support. There are no strict requirements inbound at the IdP. It's a
judgment call.

Tom

[Peter Schober]

* huwi...@champlain.edu <huwi...@champlain.edu> [2017-07-14 16:37]:

> Supporting only HTTP-REDIRECT and not HTTP-POST as the metadata seems to
> indicate wouldn't even technically work on our server because SAML
> assertions sent for response and SLO are too long and our web server crops
> them off after a certain length.

That's why with Web Browser SSO your choice of Protocol Binding for
the response is HTTP-POST or HTTP-Artifact -- *not* HTTP-Redirect
(cf. SAML 2.0 Profiles).

I.e., whatever you're doing won't work in many cases, isn't
interoperable and likely isn't even legal as per the spec.

And you yet claim that this software a bug. A classic!
-peter

[Tom Scavo]

On Fri, Jul 14, 2017 at 11:20 AM, Peter Schober
<peter....@univie.ac.at> wrote:
>
> And you yet claim that this software a bug. A classic!

I might have misunderstood but I thought the OP was asking for
out-of-the-box support both HTTP-Redirect and HTTP-POST inbound at the
IdP. If so, I support that request :-)

Tom

[huwi...@champlain.edu]

Yes, I was wondering why HTTP-POST is not claimed in the idP metadata out-of-the-box.  One of the vendors we are integrating with (i.e., their SP is being configured to authenticate to our idP) flagged this lack of claimed support as a bug and said they required our idP to support HTTP-POST binding.  I assumed that perhaps there was a good reason for not claiming support for HTTP-POST -- maybe that this binding is required and therefore does not have to be explicitly claimed.

Peter, just to be clear: I'm not claiming there is a bug in this software.  This is just a (hopefully) simple question.

Thanks for your responses!

Matt

[Tom Scavo]

On Fri, Jul 14, 2017 at 11:41 AM, <huwi...@champlain.edu> wrote:
>
> One of the vendors we are integrating with (i.e., their SP
> is being configured to authenticate to our idP) flagged this lack of claimed
> support as a bug and said they required our idP to support HTTP-POST
> binding.

Their claim is much too strong. It is true that most IdPs in the world
support HTTP-POST inbound but AFAIK there is no profile that mandates
this support.

Tom

[Peter Schober]

* Tom Scavo <trs...@gmail.com> [2017-07-14 17:46]:

> Their claim is much too strong. It is true that most IdPs in the world
> support HTTP-POST inbound but AFAIK there is no profile that mandates
> this support.

Also saml2int mandates the opposite (MUST use HTTP-Redirect for
AuthnRequests).

-peter

[huwi...@champlain.edu]

> saml2int mandates the opposite (MUST use HTTP-Redirect for AuthnRequests)

Interesting.  So just to be clear, our metadata looked like this:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="..." entityID="...">

    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        ...

        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="..."/>

    </md:IDPSSODescriptor>

</md:EntityDescriptor>

My understanding is that this line claims that our idP only supports inbound HTTP-Redirect bindings.  I see that AuthnRequests must use HTTP-Redirect according to https://saml2int.org/profile/current/#section81, but what about logout requests from the SP that contain signatures?  These are too large for some web servers to handle when encoded into the URL.

Thanks again for your responses.

Matt  

[Jaime Perez Crespo]

Hi Matt,

As Tom and Peter have already described, there’s no bug here, just a misunderstanding coming from the people running the SP. The IdP claims *inbound* bindings, but the *outbound* must be specified by the SP in its metadata.

On 14 Jul 2017, at 18:24 PM, huwi...@champlain.edu wrote:
>> > saml2int mandates the opposite (MUST use HTTP-Redirect for AuthnRequests)
>
> Interesting. So just to be clear, our metadata looked like this:
>
> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="..." entityID="...">
> <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
> ...
> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="..."/>
> </md:IDPSSODescriptor>
> </md:EntityDescriptor>

Yes, and that’s perfectly fine.

> My understanding is that this line claims that our idP only supports inbound HTTP-Redirect bindings. I see that AuthnRequests must use HTTP-Redirect according to https://saml2int.org/profile/current/#section81,

The reason why the SAML2 interoperability profile chooses to mandate HTTP-Redirect for AuthnRequests is the same reason why SSP doesn’t claim HTTP-POST support for the SSO endpoint: HTTP-POST is “fragile”, as it depends on the use of javascript, and is much less seamless than HTTP-Redirect, which is completely transparent and guaranteed to work flawlessly. Therefore, HTTP-Redirect is always preferred, as long as the message being transferred is short enough.

> but what about logout requests from the SP that contain signatures?

Logout requests from the SP must be sent to the SingleLogoutService endpoint, not to the SSO endpoint. That endpoint will also claim HTTP-Redirect support only, as a default.

> These are too large for some web servers to handle when encoded into the URL.

No, that’s not true. The HTTP-Redirect binding mandates that signatures are *not* in the form of XML signatures, but attached as URL parameters. SAMLRequest messages can also be signed and there’s no issue at all with sending them over an HTTP-Redirect binding. The same works for LogoutRequest messages, because those are equally small. Note that there are no assertions inside LogoutRequest (or LogoutResponse, for that matter) messages, contrary to what you were saying in your first mail.

In any case, the behaviour of SimpleSAMLphp here is normal and optimal. If an SP has a problem with the metadata generated by SSP, they are either misunderstanding something in the metadata, or doing something wrong.

Hope that helps.

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Tom Scavo]

On Tue, Jul 18, 2017 at 3:22 AM, Jaime Perez Crespo
<jaime...@uninett.no> wrote:
>
> On 14 Jul 2017, at 18:24 PM, huwi...@champlain.edu wrote:
>
>> I see that AuthnRequests must use HTTP-Redirect according to https://saml2int.org/profile/current/#section81,
>
> The reason why the SAML2 interoperability profile chooses to mandate HTTP-Redirect for AuthnRequests is the same reason why SSP doesn’t claim HTTP-POST support for the SSO endpoint: HTTP-POST is “fragile”, as it depends on the use of javascript, and is much less seamless than HTTP-Redirect, which is completely transparent and guaranteed to work flawlessly.

In practice, I believe HTTP-POST works just fine. A well-designed page
will contain a <noscript> element in those cases where JavaScript is
disabled, which forces the user to press a submit button. Anyone who
disables JavaScript will expect that to happen.

> Therefore, HTTP-Redirect is always preferred, as long as the message being transferred is short enough.

Well, that implies that HTTP-Redirect is *not* always preferred. For
example, if the request is signed, it's probably best to use
HTTP-POST. Granted that is not a typical scenario but I don't see the
point of holding back...why not enable both HTTP-Redirect and
HTTP-POST out of the box and be done with it?

>> but what about logout requests from the SP that contain signatures?
>
> Logout requests from the SP must be sent to the SingleLogoutService endpoint, not to the SSO endpoint. That endpoint will also claim HTTP-Redirect support only, as a default.

There are other considerations for SLO. Unless the IdP uses the SAML2
Transient NameID, the LogoutRequest will contain PII. In that case,
the use of HTTP-Redirect is a privacy concern since the NameID will be
written to the web log. For that reason, HTTP-POST is generally
preferred for SLO.

Tom

[Jaime Perez Crespo]

Hi Tom,

On 18 Jul 2017, at 19:49 PM, Tom Scavo <trs...@gmail.com> wrote:
> On Tue, Jul 18, 2017 at 3:22 AM, Jaime Perez Crespo <jaime...@uninett.no> wrote:
>>
>> On 14 Jul 2017, at 18:24 PM, huwi...@champlain.edu wrote:
>>
>>> I see that AuthnRequests must use HTTP-Redirect according to https://saml2int.org/profile/current/#section81,
>>
>> The reason why the SAML2 interoperability profile chooses to mandate HTTP-Redirect for AuthnRequests is the same reason why SSP doesn’t claim HTTP-POST support for the SSO endpoint: HTTP-POST is “fragile”, as it depends on the use of javascript, and is much less seamless than HTTP-Redirect, which is completely transparent and guaranteed to work flawlessly.
>
> In practice, I believe HTTP-POST works just fine. A well-designed page
> will contain a <noscript> element in those cases where JavaScript is
> disabled, which forces the user to press a submit button. Anyone who
> disables JavaScript will expect that to happen.

Not sure I agree. The problem here is not only for someone who consciously disables Javascript. Some people is unaware of Javascript being disabled, or can’t enable it (shared or public computers), or uses old or mobile browsers where Javascript doesn’t work properly. Most people don’t even know what Javascript is (and they shouldn’t know). In any case:

- Having a form displayed to the user so that they can continue manually implies an overhead, compared to a simple HTTP redirection.

- If you need to display the form, you have two options: display a very basic form, without style, just a white page with a button and a brief message (which feels clumsy but at least reduces the overhead —this is what we do in SSP); or display a nice looking form, with the same look&feel as the rest of the pages, at the expense of introducing even more overload and making the experience worse for users who do have Javascript enabled (it could be much slower, up to the point that they notice the form).

- It might create trouble with certain implementations of Single Logout.

>> Therefore, HTTP-Redirect is always preferred, as long as the message being transferred is short enough.
>
> Well, that implies that HTTP-Redirect is *not* always preferred.

Well, that’s what I said. Depending on the type of message, *if* it is possible to send it using the HTTP-Redirect binding, then that’s *always* preferred. If it’s *not possible* or the message could be lost/truncated, then HTTP-POST is preferred. Remove the comma between “preferred” and “as” in my previous sentence, if that makes it more clear.

> For example, if the request is signed, it's probably best to use
> HTTP-POST.

I don’t see why? In those cases, the signature was detached from the XML for a reason. Other than that, the messages are deflated, so an AuthnRequest or a logout message will almost always fit perfectly inside the URL. In practice, I don’t recall a single case where a SAML message was truncated due to its size and the use of the HTTP-Redirect binding. All the “truncation” issues I recall now were always due to other factors (but of course my memory is kind of fragile, so that doesn’t prove anything).

In any case, let me recall that the SAML2int profile mandates (with a “MUST") using the HTTP-Redirect binding for authentication requests, regardless of whether they are signed or not.

> Granted that is not a typical scenario but I don't see the
> point of holding back...why not enable both HTTP-Redirect and
> HTTP-POST out of the box and be done with it?

Both *are* enabled. Even if support for HTTP-POST is not claimed in the metadata, "it will just work"™ if used. However, claiming that support usually leads others to use it even when it’s not really necessary. Given that HTTP-Redirect is preferred, claiming exclusive support for it is a way to avoid others having the temptation of using HTTP-POST unnecessarily.

>>> but what about logout requests from the SP that contain signatures?
>>
>> Logout requests from the SP must be sent to the SingleLogoutService endpoint, not to the SSO endpoint. That endpoint will also claim HTTP-Redirect support only, as a default.
>
> There are other considerations for SLO. Unless the IdP uses the SAML2
> Transient NameID, the LogoutRequest will contain PII. In that case,
> the use of HTTP-Redirect is a privacy concern since the NameID will be
> written to the web log. For that reason, HTTP-POST is generally
> preferred for SLO.

I’d say HTTP-POST should be preferred for SLO, *only* under the following circumstances:

- It is verified to work fine, at least for most users.
- A non-transient NameID with PII is used.
- No logs are kept by SSP that could identify the user.

However, SimpleSAMLphp uses transient NameIDs by default. Therefore, there’s no such privacy concern when using SSP’s default configuration, and as such, there’s no point in using HTTP-POST (and analogously to the previous case, not claiming support for it is a good way to avoid people using it, as that binding has its own downsides). If someone wants to use any other kind of NameIDs, and they are concerned about this privacy issue, they can always add that binding to the metadata via configuration. They’ll need to configure SSP to use other kinds of NameIDs, anyway.

Finally, even if they claim HTTP-POST support for SLO in the metadata and make sure to use it with every SP, it’s likely that the user is traceable anyway via the SimpleSAMLphp logs (not personally, but as an anonymous user). Keep in mind that SSP uses “track IDs” precisely to keep track in the logs of the entire user’s session, and that includes any logout messages exchanged. If you see that as a concern, maybe we can discuss about operating IdPs where you need to be able to see what happened when someone says they were logged into someone else’s account, or when a security incident happened, etc, but I’d say that should be an entirely separate discussion :-)

In any case, weighting pros and cons, I don’t see the benefit of claiming HTTP-POST support by default (actually, I just see the problems that implies), and up until now it hasn’t been a problem at all (except when someone confuses inbound and outbound bindings or when someone is trying to do something terribly wrong), so unless there’s a very good reason for it that I’m missing, I don’t think we’ll change that.