ACSURL not honored by SimpleSAMLphp IdP?

[René FT]

Hi,

We're a SP authenticating to an IdP running SimpleSAMLphp. The authentication process itself is working great, but we have the problem that when the IdP authenticates the user and sends the user back to us (the SP), the IdP sends the users to a URL that is close, but not quite the ACSURL.

Here's our SAMLRequest that is we're passing to the IdP:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN<stringremoved>" Version="2.0" IssueInstant="2015-03-05T02:24:24Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://instance.server.com/index.php?module=somemodule&action=Authenticate&param1=1&param2=base"> <saml:Issuer>php-saml</saml:Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"></samlp:NameIDPolicy> <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest>

The key part in the ACSURL are the two parameters, which control what kind of page the users is sent back to. That changes based on where the user starts.

However, the IdP is sending the users back to the same URL, regardless of where they start or what the last two parameters are set to: ""https://instance.server.com/index.php?module=somemodule&action=Authenticate"

Any idea how simpleSAMLphp could be configured to generate this kind of behavior? Note that we do not have control over the IdP, and are trying to help them connect to our service.

Thanks!

[Peter Schober]

* René FT <rene...@gmail.com> [2015-03-26 05:17]:
> *AssertionConsumerServiceURL*="
> *https://instance.server.com/index.php?module=somemodule&action=Authenticate&param1=1&param2=base*
> <https://sanminaqa.sugarondemand.com/index.php?module=Users&action=Authenticate&dataOnly=1&platform=base>">

Hard to say what you meant to write here, as there are two different URLs.

> The key part in the ACSURL are the two parameters, which control
> what kind of page the users is sent back to. That changes based on
> where the user starts.

There's your issue: SimpleSAMLphp (like other SAML implementations)
uses locally existing metadata to verify endpoints, to make sure an
authentication request cannot request information to be sent just
/anywhere/.

Now if a SSP IDP doesn't find an exact match between the requested ACS
URL and the "pre-authorized" ACS URL it has on record for that SP
(metadata), it will use the first ACS URL for that entityID that will
match the requested binding.
(Other SAML implementations chose to fail right there with an error
message and abort the transaction.)

So that behaviour is probably masking the error that the requested ACS
URL isn't in the metadata the IDP has on record for that SP.

You seem to want somewhat dynamic ACS URLs, when that's not really
common with SAML at all (as metadata -- or static configuration on
some GUI -- is commonly used to pre-authorize endpoints).

One way to do those securely is to sign the authn request and have the
IDP rely on the signature of the authn request instead. There have
been patches contributed to do that very recently, but of course that
will only help if the SP in question signs its requests.

If the number of ACS URLs are limited the cheaper alternative is for
the IDP to enumerate them all, i.e., have more than one ACS URL
element for that binding, one for each possible ACS URL.
Obviously that doesn't scale if the ACS URL really needs to be
dynamic. But then most SAML implementations wouldn't be able to
interop with an SP that required support for dynamic ACS URLs, I'd
say.

> Any idea how simpleSAMLphp could be configured to generate this kind
> of behavior? Note that we do not have control over the IdP, and are
> trying to help them connect to our service.

If my observations are correct above, it's all your own fault,
essentially: Stop overlaying the ACS URL with some internal state from
your own system. Why should the URL where you want SAML protocol
messages sent to vary slightly (and only in request parameters) for
the same SP, or in your own world, for the same customer?
You can track the needed (additional) state in some parameter you add
to the RelayState instead.
Fix that and you're making live much easier for all your customers, no
matter the SAML implementation they're using.
-peter

[Shoaib Ali]

Correct me if I am wrong, but shouldn't you be using RelayState? That is exactly what that is for. If you specify a RelayState it should respect it and forward the user accordingly. 

See here for more RelayState configuration of the SP https://simplesamlphp.org/docs/1.6/simplesamlphp-idp#section_11

--
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]

* Shoaib Ali <sho...@catalyst.net.nz> [2015-03-26 13:01]:

> Correct me if I am wrong, but shouldn't you be using RelayState? That is
> exactly what that is for. If you specify a RelayState it should respect it
> and forward the user accordingly.
>
> See here for more RelayState configuration of the SP
> https://simplesamlphp.org/docs/1.6/simplesamlphp-idp#section_11

The message you are replying to here (and quoting below; trimmed here)
explicitly mentiones that the SAML SP could track any needed state in
its RelayState (which can be opaque to the IDP), instead of burdening
IDPs with it by having movable parts in the SP's ACS URL.

Also, the SP here is sending a SAML authentication request (i.e.,
SP-initiated SSO), so pointing to the SimpleSAMLphp documentation on
how to do IDP-initiated SSO is pointless.

Finally you're quoting hopelessly obsolete documentation (1.6, current
is 1.13), commonly the unfortunate result of blindly taking what
$searchengine returned first.
-peter

[Shoaib Ali]

Regardless of SP or IdP initiated, from the original message I could not make out if René is using SimpleSAMLphp for their SP. I assumed not.

However, RelayState is a SAML standard can be used for this scenario in both cases. 

Yeah the link to that documentation is useless.

-peter

[Rene FT]

Hi Folks,

Thanks for all your insight. Peter, the two URLs were the result of my failed attempt at server obfuscation. I think both the notion that not using a dynamic ACSURL or to use RelayState instead are going to bear the most fruit. 

I might have a follow-up question later on, but for now, I've got a few things to track down. Thank you!

[Sergei Morozov]

Does SimpleSAMLphp IdP support RelayState in both IdP-first and SP-first scenarios? The documentation mentions only the former, when the RelayState is static and stored in the IdP configuration.

I tried passing RelayState alongside with the SAMLRequest to our internal instance of  SimpleSAMLphp, and I was getting only SAMLResponse back. Does the IdP require any additional configuration in order to start respecting RelayState parameter? The same scenario worked fine with OneLogin (I got the value of RelayState back alongside with SAMLResponse).

[Peter Schober]

Please don't reply to just any existing, unrelated thread. Doing that
messes up archiving and threading. Instead compose a new message to
the list/group.

* Sergei Morozov <moro...@gmail.com> [2015-04-24 13:21]:

> Does SimpleSAMLphp IdP support RelayState in both IdP-first and
> SP-first scenarios?

It does. The SAML spec requires the IDP to send back a recieved
RelayState value verbatim.

> The documentation
> <https://simplesamlphp.org/docs/1.6/simplesamlphp-idp#section_11>

> mentions only the former, when the RelayState is static and stored
> in the IdP configuration.

As the warning on that page indictes, 1.6 is obsolte. So always look
at the documentation for the version of the software you're using.
Other than that there's simply nothing to do in the normal case of the
SP sending the RelayState (the IDP will return it unmolested).

> I tried passing RelayState alongside with the SAMLRequest to our
> internal instance of SimpleSAMLphp, and I was getting only
> SAMLResponse back.

Is that SP-initiated or IDP-initiated? Note that there will always be
a request to the IDP, the question is just whether it'a SAML 2.0
authentication request, or a proprietary substitute for that
(SimpleSAMLphp request parameters for IDP-inititated logins).
So there simply is no reason to use IDP-initiated SSO, esp if the
SP is SimpleSAMLphp (or something else that's not broken).

> Does the IdP require any additional configuration in order to start
> respecting RelayState parameter?

No, it should Just Work.
-peter

[Сергей Морозов]

Is that SP-initiated or IDP-initiated?

The authentication is SP-initiated.

[…] the question is just whether it'a SAML 2.0 authentication request, or a proprietary substitute for that (SimpleSAMLphp request parameters for IDP-inititated logins)

It's a SAML 2.0 authentication request issued by onelogin/php-saml v2.1.0.1. We don't try to simulate an IdP-initiated login.

No, it should Just Work.

Thank you. Looks like the problem is caused by some customization or other changes made to the IdP instance.

--
You received this message because you are subscribed to a topic in the Google Groups "simpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/0D8N9j9Ny3o/unsubscribe.
To unsubscribe from this group and all its topics, 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.

--

С уважением,
Сергей Морозов