Secure Multiple Sites With a Single ACS Endpoint

[Tony Plovich]

Hello,

I'm currently assisting with the installation of a multi-site Drupal
instance that's secured with simpleSAMLphp.  I was wondering if it's
possible to secure all of the sites, which are hosted under different
vhosts, using a single SP such that new sites wouldn't require updates
to the IDP's metadata.  I believe the authn flow would look like this:

www.example1.com/secured_content --(Authn Request)--> login.anl.gov
(IDP) --(Authn Response)--> www.example1.com/ACS --(Relay State
Redirect)--> www.example1.com/secured_content

www.example2.com/secured_content --(Authn Request)--> login.anl.gov
(IDP) --(Authn Response)--> www.example1.com/ACS --(Relay State
Redirect)--> www.example2.com/secured_content

...

Looking through the docs and mailing list, the closest thing I've seen
to this would be a single configuration of simpleSAMLphp that's
generalized to automatically accept authn responses on whichever vhost
it exists under.  Unfortunately, this means I'd have to add ACS
endpoints for each new site on the IDP.

Thanks,

--
Tony Plovich (aplo...@anl.gov)

[Peter Schober]

* Tony Plovich <aplo...@anl.gov> [2017-10-23 18:53]:

> I'm currently assisting with the installation of a multi-site Drupal
> instance that's secured with simpleSAMLphp.  I was wondering if it's
> possible to secure all of the sites, which are hosted under different
> vhosts, using a single SP such that new sites wouldn't require updates to
> the IDP's metadata.

How many IDPs are there involved and how much control do you have over
them? E.g. the Shibboleth IDP (dont know about SSP, sorry) can be
configured to rely in signed authentication requests instead of
metadata to establish the authenticity and integrity of the ACS URL
requested by the SP.
I.e., you wouldn't need to have additional ACS endpoints in metadata
at all.
Obviously with many/diverse IDPs this won't scale, though.

> www.example2.com/secured_content --(Authn Request)--> login.anl.gov (IDP)
> --(Authn Response)--> www.example1.com/ACS --(Relay State Redirect)-->
> www.example2.com/secured_content

Well, with HTTP Cookies scoped to the FQDN of the accessed server the
browser would lose its session between POST'ing the SAML to the ACS
endpoint at www.example1.com/ACS and being sent on to the RelayState
at www.example2.com/secured_content -- unless the two resoures shared
a common DNS domain and HTTP Cookies were scoped to the domain, I
guess.

But multiple frequently changing ACS endpoints may not be an issue, it
depends a lot on your metadata management/exchange. E.g. at one site I
generated that metadata programmatically from an SQL database, with
thousands of vhosts in it. (Signing the request wasn't an alternative
back then.)

-peter

[Tony Plovich]

Hello Peter,

Thanks for the input, there's only one IDP we need to use, and we run
it, so this is exactly what we were looking for.

Tony Plovich (aplo...@anl.gov)

[Peter Schober]

* Tony Plovich <aplo...@anl.gov> [2017-10-25 17:28]:

> Thanks for the input, there's only one IDP we need to use, and we
> run it, so this is exactly what we were looking for.

Impossible for me to know for sure from only 2 examples both sharing
the same IDP, so glad this will work out for you, as that would mean
no changes to the applications or SP-side SAML implementation or even
metadata.

If you're using SSP on the IDP side, too, I'd like to see how you
achieved this. (Patches always welcome!) ;)

Best regards,
-peter