HTTP-POST and ACS URL from SP
964 views
Skip to first unread message
Chris Babyak
Sep 29, 2015, 10:57:10 AM9/29/15
to SimpleSAMLphp
Seeking some assistance with setting up a remote SP provider who utilizes only HTTP-POST for talking to IDPs.
We've setup a binding for HTTP-POST in our config and we can successfully post an assertion back to the SP. The SP then sends an AuthResponse containing a varying AssertionConsumerServiceURL which from section 3.4.1 of the SAML spec is listed as optional. SimpleSAMLphp is processing the request but sending the browser back to the binding URL as listed in the metadata that we exchanged from them (their metadata only has one binding). Once that happens, the SPs system sends a "Verb not permitted" response because we're then posting back to the wrong endpoint.
From discussions with the SP, they use this varying ACS URL to deal with system maintenance, business continuity, etc. We have numerous SPs which we have had great success with across the board, but none of them utilize HTTP-POST and I'm curious if this is a special situation SimpleSAMLphp has a hard time dealing with (or if we just have an error in setup).
We're using SimpleSAMLphp 1.13 in a linux environment as an IDP. The endpoint on the SP is an IIS environment.
<snip from saml20-idp-hosted.php>
'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
// Add Extra Binding for HTTP-POST
'SingleSignOnServiceBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'SingleLogoutServiceBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
</end snip>
<snip from saml20-sp-remote.php>
'AssertionConsumerService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'https://demo.sp.com/SP/SAML2/POST',
'index' => 0,
'isDefault' => true,
),
),
</end snip>
Appreciate any guidance on this!
Tom Scavo
Sep 29, 2015, 11:15:36 AM9/29/15
to simpleSAMLphp
On Tue, Sep 29, 2015 at 10:57 AM, Chris Babyak <cbaby...@gmail.com> wrote:
> Seeking some assistance with setting up a remote SP provider who utilizes
> only HTTP-POST for talking to IDPs.
This is typical.
> Seeking some assistance with setting up a remote SP provider who utilizes
> only HTTP-POST for talking to IDPs.
> We've setup a binding for HTTP-POST in our config and we can successfully
> post an assertion back to the SP. The SP then sends an AuthResponse
> containing a varying AssertionConsumerServiceURL which from section 3.4.1 of
> the SAML spec is listed as optional.
such a URL. It's a MUST.
> SimpleSAMLphp is processing the
> request but sending the browser back to the binding URL as listed in the
> metadata that we exchanged from them (their metadata only has one binding).
> Once that happens, the SPs system sends a "Verb not permitted" response
> because we're then posting back to the wrong endpoint.
IdP didn't follow standard behavior.
> From discussions with the SP, they use this varying ACS URL to deal with
> system maintenance, business continuity, etc. We have numerous SPs which we
> have had great success with across the board, but none of them utilize
> HTTP-POST and I'm curious if this is a special situation SimpleSAMLphp has a
> hard time dealing with (or if we just have an error in setup).
configured incorrectly or it's behaving in a non-standard manner. Not
sure which is the case, maybe someone else can say.
Tom
Peter Schober
Sep 29, 2015, 12:09:07 PM9/29/15
to simpleSAMLphp
* Tom Scavo <trs...@gmail.com> [2015-09-29 17:16]:
with existing SAML Metadata, it will terminate processing.
The SimpleSAMLphp, OTOH, in that case will send the response to the
first ACS URL of matching Binding from the SAML Metadata.
In both cases it is ensured that the response is only sent to
verified/authenticated endpoints. In the Shib case it's clear an error
condition occured and the subject is stranded at the IDP. In the SSP
case the subject will be sent on to a different (than requested) ACS
URL.
One could argue that SSP's behaviour at least has a chance of working.
From my own experience I must say that this behaviour masks Metadata
errors and confuses the hell out of anyone stumbling on such a case.
But "bug in the software" is too strong for that, IMO.
Questionable choice, maybe.
To the OP: Indeed us of the HTTP-POST protocol binding has nothing to
do with any of that.
No matter how the request was sent to the IDP, the IDP has to make
sure the response is only sent to validated endpoints. Verifying the
ACS URL from the request against SAML Metadata on record at the IDP is
one way (and the default way for both SimpleSAMLphp and Shibboleth).
Having the SP sign the request, and the IDP forgo Metadata ACS URL
checks iff the signature validates (and is from a trusted key), is
another.
-peter
> > SimpleSAMLphp is processing the request but sending the browser
> > back to the binding URL as listed in the metadata that we
> > exchanged from them (their metadata only has one binding).
>
> If so, that would seem to be a bug in the software.
FWIW, if the Shibboleth IDP cannot authenticate the requested ACS URL
> > back to the binding URL as listed in the metadata that we
> > exchanged from them (their metadata only has one binding).
>
> If so, that would seem to be a bug in the software.
with existing SAML Metadata, it will terminate processing.
The SimpleSAMLphp, OTOH, in that case will send the response to the
first ACS URL of matching Binding from the SAML Metadata.
In both cases it is ensured that the response is only sent to
verified/authenticated endpoints. In the Shib case it's clear an error
condition occured and the subject is stranded at the IDP. In the SSP
case the subject will be sent on to a different (than requested) ACS
URL.
One could argue that SSP's behaviour at least has a chance of working.
From my own experience I must say that this behaviour masks Metadata
errors and confuses the hell out of anyone stumbling on such a case.
But "bug in the software" is too strong for that, IMO.
Questionable choice, maybe.
To the OP: Indeed us of the HTTP-POST protocol binding has nothing to
do with any of that.
No matter how the request was sent to the IDP, the IDP has to make
sure the response is only sent to validated endpoints. Verifying the
ACS URL from the request against SAML Metadata on record at the IDP is
one way (and the default way for both SimpleSAMLphp and Shibboleth).
Having the SP sign the request, and the IDP forgo Metadata ACS URL
checks iff the signature validates (and is from a trusted key), is
another.
-peter
Chris Babyak
Oct 1, 2015, 2:13:18 PM10/1/15
to SimpleSAMLphp, peter....@univie.ac.at
I want to thank everyone for the replies.
As it would turn out, due to the verification against the metadata (which is in everyone's best interest anyway) the SP initiated HTTP-POST method for this SP will not work out.
We've moved to IDP initiated and are now able to post successfully back to this SP.
Thanks!
Peter Schober
Oct 1, 2015, 3:26:55 PM10/1/15
to SimpleSAMLphp
* Chris Babyak <cbaby...@gmail.com> [2015-10-01 20:13]:
As has been said, the reason those requests failed has nothing to do
with the protocol binding (HTTP-POST vs. HTTP-Redirect) with which the
authentication request was sent to the IDP -- but with the request
asking for the reponse to be delivered to an unknown (to the IDP)
destination -- and that the request was not cryptographicslly signed
(which would be an acceptable alternative for the IDP to verify the
authenticity of the request, and therefore use the unknown endpoint
for the reponse).
Replacing SAML-defined requests ("SP-initiated") with proprietary,
implementation-specific requests ("IDP-initiated") shouldn't account
for changed behaviour in that regard, I would think:
The IDP shouldn't send responses to unverified endpoints (based on
unauthenticated requests), ever, IMO.
Also, I don't see how you could get the IDP to send the response to an
endpoint that's NOT known to the IDP via metadata using
SimpleSAMLphp's IDP-initiated protocol requests?
I don't know the code or all possible parameters, but from the
documentation here I can't see how you would provide the desired ACS
URL (and Binding) to the IDP that way:
https://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_11
-peter
> As it would turn out, due to the verification against the metadata (which
> is in everyone's best interest anyway) the SP initiated HTTP-POST method
> for this SP will not work out.
>
> We've moved to IDP initiated and are now able to post successfully back to
> this SP.
Sorry, none of that makes any sense to me:
> is in everyone's best interest anyway) the SP initiated HTTP-POST method
> for this SP will not work out.
>
> We've moved to IDP initiated and are now able to post successfully back to
> this SP.
As has been said, the reason those requests failed has nothing to do
with the protocol binding (HTTP-POST vs. HTTP-Redirect) with which the
authentication request was sent to the IDP -- but with the request
asking for the reponse to be delivered to an unknown (to the IDP)
destination -- and that the request was not cryptographicslly signed
(which would be an acceptable alternative for the IDP to verify the
authenticity of the request, and therefore use the unknown endpoint
for the reponse).
Replacing SAML-defined requests ("SP-initiated") with proprietary,
implementation-specific requests ("IDP-initiated") shouldn't account
for changed behaviour in that regard, I would think:
The IDP shouldn't send responses to unverified endpoints (based on
unauthenticated requests), ever, IMO.
Also, I don't see how you could get the IDP to send the response to an
endpoint that's NOT known to the IDP via metadata using
SimpleSAMLphp's IDP-initiated protocol requests?
I don't know the code or all possible parameters, but from the
documentation here I can't see how you would provide the desired ACS
URL (and Binding) to the IDP that way:
https://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_11
-peter
Reply all
Reply to author
Forward
0 new messages