Must AssertionConsumerServiceURL always equal the current URL?

[Gavin P]

I'm new to SAML so please forgive any obvious errors.

I'm running an SP, that connects to a remote SAML2.0 IdP.

However on my end, the domain the user logs into often changes, as it could be a number of different applications/services using the same SP:

http://sso.com/simplesaml/

http://example.com/protected-area

http://test.org/protected-area

etc

I'm including the 'simplesaml' files where needed into the applications above. However I then find, the SAMLRequest we send to the IdP has updated the 'AssertionConsumerServiceURL' to match the current domain, rather than the

http://sso.com/simplesaml/simplesaml/module.php/saml/sp/saml2-acs.php/mysp

that I'd expect to see, I'm seeing:

http://example.com/simplesaml/module.php/saml/sp/saml2-acs.php/mysp

The IdP then errors, as the domain isn't a valid AssertionConsumerService setup on their end, as the URLs don't match what they have.

Is it possible to use a fixed domain, rather than the current domain in the AssertionConsumerService? Or am I going about this all the wrong way? Is there something different I should be doing to share an SP between multiple sites/URLs ...

Many, many thanks in advance for any help.

Gavin

[Eddie Beuerlein]

I could be wrong but I am pretty sure based on the docs that you have to have an SP per domain name because each one has their own config files for the area they protect.

Eddie

--
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/groups/opt_out.

[Peter Schober]

* Gavin P <ga...@gavinpearce.com> [2014-02-21 23:36]:

> However on my end, the domain the user logs into often changes, as
> it could be a number of different applications/services using the
> same SP:
> http://sso.com/simplesaml/
> http://example.com/protected-area
> http://test.org/protected-area
> etc

According to the SAML spec the IDP must ensure that the destination
for the response is authentic. Matching the ACS URL from the SP's
authentication request to the ACS URL the IDP has in metadata for the
SP is one way to do that. That doesn't align well with vhosting, of
course.
A common way to work around that is by adding additional ACS URLs to
the metadata (that the IDP uses), one for each vhost.
(With the caveat being that SAML SLO won't work with those vhosts.)

Depending on whether the IDP supported that, an alternative would be
having the SP sign its authentication requests and have the IDP verify
that, skipping the metadata check for ACS URLs iff a valid signature
is present. (E.g. recent Shibboleth IDPs can be made to behave that way.)

> Is it possible to use a fixed domain, rather than the current domain
> in the AssertionConsumerService? Or am I going about this all the
> wrong way? Is there something different I should be doing to share
> an SP between multiple sites/URLs ...

Even if your SimpleSAMLphp SP would set a fixed ACS URL in all its
authnRequests (and consequently handle all responses from the IDP for
all vhosts in that one single vhost) I'm not sure how SSP would be
able to then set HTTP Cookies (after establishing a session) scoped to
all those other vhosts where you wanted to establish a session (as a
web browser should only accept those from the correct FQDN itself).
Might be possible with some trickery.
-peter

[Jaime Pérez Crespo]

Hi,

On 22 Feb 2014, at 03:54 am, Eddie Beuerlein <eddie.b...@gmail.com> wrote:
> I could be wrong but I am pretty sure based on the docs that you have to have an SP per domain name because each one has their own config files for the area they protect.

Well, that’s not really true. One single service provider could perfectly serve many different applications in different domain names. The apps must then use the programming interface provided to ask for authentication / attributes, but the apps doesn’t need to care about the domain used by the SP. Same applies to the IdP. If the IdP doesn’t care about the applications using authentication behind the SP, then that’s perfectly fine.

The right way to go is set ‘baseurlpath’ to the absolute URL of the base installation of simpleSAMLphp. Of course that base URL must be set to something correctly configured (as in SSP can be reached through that URL).

I wonder which version of simpleSAMLphp you are using, since this is pretty well documented in the config file itself:

—8<—
* Valid format for baseurlpath is:
* [(http|https)://(hostname|fqdn)[:port]]/[path/to/simplesaml/]
* (note that it must end with a '/')
*
* The full url format is useful if your simpleSAMLphp setup is hosted behind
* a reverse proxy. In that case you can specify the external url here.
*
* Please note that simpleSAMLphp will then redirect all queries to the
* external url, no matter where you come from (direct access or via the
* reverse proxy).
*/
'baseurlpath' => 'simplesaml/',
—>8—

Regards,

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

[Eddie Beuerlein]

Okay that makes sense.  So how would the metadata be set? For example would the ACS would be set to the baseurlpath of the base installation for each of the examples given by Gavin?

Eddie

On Sunday, February 23, 2014, Jaime Pérez Crespo <jaime...@uninett.no> wrote:

Hi,

On 22 Feb 2014, at 03:54 am, Eddie Beuerlein <eddie.b...@gmail.com> wrote:
> I could be wrong but I am pretty sure based on the docs that you have to have an SP per domain name because each one has their own config files for the area they protect.

Well, that's not really true. One single service provider could perfectly serve many different applications in different domain names. The apps must then use the programming interface provided to ask for authentication / attributes, but the apps doesn't need to care about the domain used by the SP. Same applies to the IdP. If the IdP doesn't care about the applications using authentication behind the SP, then that's perfectly fine.

The right way to go is set 'baseurlpath' to the absolute URL of the base installation of simpleSAMLphp. Of course that base URL must be set to something correctly configured (as in SSP can be reached through that URL).

I wonder which version of simpleSAMLphp you are using, since this is pretty well documented in the config file itself:

--8<--

     * Valid format for baseurlpath is:
     * [(http|https)://(hostname|fqdn)[:port]]/[path/to/simplesaml/]
     * (note that it must end with a '/')
     *
     * The full url format is useful if your simpleSAMLphp setup is hosted behind
     * a reverse proxy. In that case you can specify the external url here.
     *
     * Please note that simpleSAMLphp will then redirect all queries to the
     * external url, no matter where you come from (direct access or via the
     * reverse proxy).
     */
    'baseurlpath'           => 'simplesaml/',

-->8--

[Jaime Pérez Crespo]

Hi,

On 23 Feb 2014, at 22:00 pm, Eddie Beuerlein <eddie.b...@gmail.com> wrote:
> Okay that makes sense. So how would the metadata be set? For example would the ACS would be set to the baseurlpath of the base installation for each of the examples given by Gavin?

That really depends on each case. If the IdP is happy that you have many applications authenticating through the same SP (in which case the IdP can’t change its own policies depending on the application, because all it sees is the very same SP), then it’s enough to configure SSP with the baseurlpath fixed to the URL of the SP, and you are done. If the IdP wants more control, then you might need to have many SPs, which do not necessarily be different instances of SSP. You can leverage the fact that the configuration is written in PHP, and configure baseurlpath dynamically, depending on the app invoking authentication. That’s a little trickier, of course.

What you cannot do out-of-the-box is to configure many different ACS with many different domains. So there’s no way to publish a metadata containing all the domains that Gavin was mentioning as examples. Each ‘domain’ would have its own virtual SP.

[Gavin P]

Hi all,

Thanks for your help here - so I've gone ahead and set the baseurlpath and given this a go, however am seeing the following error:

"State information lost, and no way to restart the request

SimpleSAML_Error_NoState: NOSTATE"

This makes sense to me, as we end up on a different domain from where we started and so it can't load the session cookies.

As I'm obviously missing something, this is the 'flow' so to speak:

baseurlpath => 'https://our-sp.com/simplesaml/'

1) User visits a protected area: http://application1.com/private

This area loads the simplesaml classes: require_once('../simplesamlphp/lib/_autoload.php');
and is protected with:  $as->requireAuth(array());   //Array containts a ReturnTo item of:  http://application1.com/private

2) POST request is issued to the IdP (the IdP needs us to use HTTP-Post bindings), however we're still on the http://application1.com/private URL at this point.

3) The IdP process is run (register/login etc), and we get returned back to the SP our end, (before the RelayState/ReturnURL magic happens)

User is now at: http://our-sp.com/simplesaml/module.php/saml/sp/saml2-acs.php/our-sp-name

And obviously, as the domain is different from that at the start, we get the State error as it can't load the session info.

I'm guessing at the start, the user needs to be on the https://our-sp.com/ domain, before we issue the POST SAMLRequest to the IdP, but I'm not sure the best way to achieve this?

Many thanks once again!

Gavin

[Jaime Pérez Crespo]

Hi Gavin,

On 24 Feb 2014, at 21:03 pm, Gavin P <ga...@gavinpearce.com> wrote:
> Hi all,
>
> Thanks for your help here - so I've gone ahead and set the baseurlpath and given this a go, however am seeing the following error:
> "State information lost, and no way to restart the request
> SimpleSAML_Error_NoState: NOSTATE"
>
> This makes sense to me, as we end up on a different domain from where we started and so it can't load the session cookies.
>
> As I'm obviously missing something, this is the 'flow' so to speak:
>
> baseurlpath => 'https://our-sp.com/simplesaml/'
>
> 1) User visits a protected area: http://application1.com/private
> This area loads the simplesaml classes: require_once('../simplesamlphp/lib/_autoload.php');
> and is protected with: $as->requireAuth(array()); //Array containts a ReturnTo item of: http://application1.com/private
>
> 2) POST request is issued to the IdP (the IdP needs us to use HTTP-Post bindings), however we're still on the http://application1.com/private URL at this point.
>
> 3) The IdP process is run (register/login etc), and we get returned back to the SP our end, (before the RelayState/ReturnURL magic happens)
> User is now at: http://our-sp.com/simplesaml/module.php/saml/sp/saml2-acs.php/our-sp-name
>
> And obviously, as the domain is different from that at the start, we get the State error as it can't load the session info.

I’m guessing that you say “different”, because the URL where the SAML assertion is posted belongs to the SP, not to the application (application1.com). That shouldn’t be a problem. The SP and the application don’t necessarily have to be in the same domain (as long as you control both domains and both are virtual hosts in the same machine, where you can use SSP’s API, of course).

In this example, your SP should be issuing a SAML request according to its configuration (which refers to our-sp.com as set in your 'baseurlpath’), configure the session on that domain, and get back a SAML response in the same domain, where it should be able to load the session correctly, mark the user as authenticated, and then return to the original URL where authentication started (by calling requireAuth()). I don’t see any reason why that shouldn’t work.

> I'm guessing at the start, the user needs to be on the https://our-sp.com/ domain, before we issue the POST SAMLRequest to the IdP, but I'm not sure the best way to achieve this?

No, not really, as I already said. My advice is to take a look at the logs (both SSP’s and web server’s) and try to trace the error properly. You can increment the amount of messages you get in the log by setting the log level in the configuration. I would also recommend you to take a look into the actual SAML exchange, and verify that everything is fine (both the SAML documents involved and the rest of the parameters part of the WebSSO profile). There you might spot if something is wrong in the configuration. You can do that by installing the SAML tracer extension in firefox, for instance.

> Many thanks once again!

You are welcome!

[Jaime Pérez Crespo]

Hi again,

On 26 Feb 2014, at 09:02 am, Jaime Pérez Crespo <jaime...@uninett.no> wrote:
> In this example, your SP should be issuing a SAML request according to its configuration (which refers to our-sp.com as set in your 'baseurlpath'), configure the session on that domain, and get back a SAML response in the same domain, where it should be able to load the session correctly, mark the user as authenticated, and then return to the original URL where authentication started (by calling requireAuth()). I don't see any reason why that shouldn't work.

Well, I guess I’ll have to correct myself, as requireAuth() won’t return if you have to do a HTTP redirect, and if you need the redirect, that’s because you don’t have the SP's cookie in the app domain. So basically, that won’t work. You will need to dynamically configure ‘baseurlpath’ in order to share the SP instance. But if you want the SP in a different domain, additional logic must be in place.

And now I see a reason to avoid answering mails when you are still asleep :-)

Sorry for the confusion.