SAML2 LogoutRequest/Response should send & verify Destination attribute when signed

[Ruud Righarts]

Hi,

After some SLO troubles with SimpleSAMLPHP 1.12.0 and OpenAM (trunk/revision 9402) I found that both SimpleSAMLPHP and OpenAM are not following the SAML2 protocol specifications.

When sending a signed LogoutResponse the LogoutResponse MUST send the Destination attribute. The attribute is optional in the protocol specification (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, page 38) but is mandatory when using the protocol bindings HTTP-REDIRECT, HTTP-POST & HTTP-Artifact with signing (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf, page 19).

Note that SSP is using HTTP-REDIRECT&POST as protocol bindings.

As it turns out SimpleSAMLPHP does not send the Destination attribute and OpenAM does verify the attribute (and fails with a InvalidException) which is entirely within the protocol specifications.

After I fixed this in SSP OpenAM does not fail anymore and the SLO works as it should. 

Some more SAML2 assertion checking later I found, to my own surprise, that OpenAM does not send the Destination attribute as well as you can see below:

<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                      ID="s864ea489ee3dd41f984737cd4a7568d73e14f00b"

                      Version="2.0"

                      IssueInstant="2014-06-27T14:27:48Z"

                      InResponseTo="_0be5e5703926c13a8dd8e7280fc9f84760091fcdc6"

                      >

    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://proxyidp.test.local:8443/openam</saml:Issuer>

    <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

        <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                          Value="urn:oasis:names:tc:SAML:2.0:status:Success"

                          />

        <samlp:StatusMessage xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

Request is done successfully

</samlp:StatusMessage>

    </samlp:Status>

</samlp:LogoutResponse>

Because SimpleSAMLPHP does not even check the Destination attribute the SLO finishes without error. Now, you could argue that it's not a big deal because its just a final logoutresponse signalling that the SLO is done. 

But if SSP does check on it users would get a nice HTTP error page 

IMHO this is a bug in both the OpenAM and SSP code and for the SSP part it would be wise to fix this. I attached my own source code fix on modules/saml/sp/saml2-logout.php to address the missing Destination attribute in the LogoutResponse.

I also added some code to validate the Destination when receiving a LogoutResponse but since I can not check if that works (since OpenAM does not send it) it is commented out. Your mileage may vary....

Email has also be sent to the OpenAM userlist, see https://lists.forgerock.org/pipermail/openam/2014-June/017647.html

greetz,

Ruud

[Jaime Pérez Crespo]

Hi Ruud,

On 27 Jun 2014, at 17:30 pm, Ruud Righarts <ruud.r...@gmail.com> wrote:
> Hi,
>
> After some SLO troubles with SimpleSAMLPHP 1.12.0 and OpenAM (trunk/revision 9402) I found that both SimpleSAMLPHP and OpenAM are not following the SAML2 protocol specifications.
>
> When sending a signed LogoutResponse the LogoutResponse MUST send the Destination attribute. The attribute is optional in the protocol specification (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, page 38) but is mandatory when using the protocol bindings HTTP-REDIRECT, HTTP-POST & HTTP-Artifact with signing (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf, page 19).

After reviewing both the bindings document and the core one, together with the approved errata, I don’t think the Destination attribute is really mandatory. I agree that the wording in the bindings document might be a bit ambiguous, but I can’t find any place in the specifications that explicitly says that the Destination attribute is mandatory in such case. If they meant it to be, it should be said explicitly in the document, apart from the statement that tells what it must contain.

> Note that SSP is using HTTP-REDIRECT&POST as protocol bindings.
>
> As it turns out SimpleSAMLPHP does not send the Destination attribute and OpenAM does verify the attribute (and fails with a InvalidException) which is entirely within the protocol specifications.
> After I fixed this in SSP OpenAM does not fail anymore and the SLO works as it should.

I would say it’s the other way around actually. OpenAM should only verify the value of the attribute if the attribute is present, which it doesn’t need to be, IMO.

> Some more SAML2 assertion checking later I found, to my own surprise, that OpenAM does not send the Destination attribute as well as you can see below:

Which is exactly what I would expect. To me it looks like the incoherence in OpenAM’s behaviour is due to a bug in the message validation code.

> <samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> ID="s864ea489ee3dd41f984737cd4a7568d73e14f00b"
> Version="2.0"
> IssueInstant="2014-06-27T14:27:48Z"
> InResponseTo="_0be5e5703926c13a8dd8e7280fc9f84760091fcdc6"
> >
> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://proxyidp.test.local:8443/openam</saml:Issuer>
> <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
> <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> Value="urn:oasis:names:tc:SAML:2.0:status:Success"
> />
> <samlp:StatusMessage xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
> Request is done successfully
> </samlp:StatusMessage>
> </samlp:Status>
> </samlp:LogoutResponse>
>
> Because SimpleSAMLPHP does not even check the Destination attribute the SLO finishes without error. Now, you could argue that it's not a big deal because its just a final logoutresponse signalling that the SLO is done.

SimpleSAMLphp should definitely check the attribute if it’s present, and verify that its contents match the current URL, which it does from version 1.7, at least for logout requests. Can’t tell right now if it behaves in the same way with other messages.

> But if SSP does check on it users would get a nice HTTP error page
>
> IMHO this is a bug in both the OpenAM and SSP code and for the SSP part it would be wise to fix this. I attached my own source code fix on modules/saml/sp/saml2-logout.php to address the missing Destination attribute in the LogoutResponse.
> I also added some code to validate the Destination when receiving a LogoutResponse but since I can not check if that works (since OpenAM does not send it) it is commented out. Your mileage may vary....
>
> Email has also be sent to the OpenAM userlist, see https://lists.forgerock.org/pipermail/openam/2014-June/017647.html

Any feedback on why OpenAM seems to require the attribute to be present?

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

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

[Ruud Righarts]

Hi Jaime,

I agree that the errata isn't really clear on it. The way I see it, if it's not explicity mentioned in the errata the original spec apply.

But that's just how I see it. 

Had the same sort of answer on the OpenAM side about the errata. But then again, if its not mandatory why do they validate it when signed logoutrequest/response is configured?

The code in OpenAM only checks when the message received is signed.

And I have no explanation for it since the actual message is not signed. It looks to me like OpenAM just follows the configuration setup where logout has been configured to be signed but it doesn't actually check if the message is signed (as can be seen from the example where the signing stuff is not there....)

So, the 100000 dollar question is:  is it a implementation issue (and if so, in SSP or OpenAM or both), is it a protocol specification thing or something else. 

I don't know, but what I do know is that I opted for a fix on the SSP side by sending the Destination attribute 

greetz,

Ruud

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Peter Schober]

* Ruud Righarts <ruud.r...@gmail.com> [2014-06-30 11:39]:

> I agree that the errata isn't really clear on it. The way I see it,
> if it's not explicity mentioned in the errata the original spec
> apply.

While there are non-normative "errata composite" documents available
at https://wiki.oasis-open.org/security which might help with this
(and which may or may not include all previously approved errata) the
best way to get clarification on any part of the SAML spec is to ask
the OASIS security TC directly, at <saml...@lists.oasis-open.org>.
-peter

[Jaime Pérez Crespo]

Hi Ruud,

I’ve been taking a closer look into this. As far as I’ve seen, people involved directly with OpenSAML or the SAML standard understands the ambiguous paragraph as the destination attribute being mandatory in case the message is signed. I assume therefore that’s the way the Shibboleth software would implement this. That given, and considering that we always unconditionally add the destination attribute in the SAML messages generated by SimpleSAMLphp except in this specific case, I will just consider this a bug, which should be fixed now in commit ff17745. Could you please check it out?

Thanks!

[Ruud Righarts]

Hi Jaime,

I tested the commit in my lab setup, SLO is working fine now!

Thanks

Ruud