Configuring separate SPs using separate IdPs on Apache+Linux?

[Peter Schober]

* sacha+shibboleth at ssl.co.uk <sacha+shibboleth at ssl.co.uk> [2021-06-22 12:15]:
> I operate a Linux server hosting websites for multiple, completely
> distinct customers. These websites are entirely different (not
> instances of the same website) but each have areas that need to be
> secured by authenticated access.

FWIW, we added Shib support to our mass webhosting platform at the
university over 1.5 decades ago where people could activate this in
self-service by simply amending their .htaccess with appropriate
settings. (That may be replaced with a completely different design,
I've since left the group that operates this.)
But maximum separation wasn't the concern -- the goal was more of the
opposite: How to make multiple servers with hundreds or thousands of
accounts as managable as possible (i.e., make them appear as one or as
as few entities as possible).
Also these local system accounts couldn't add custom IDP metadata, all
they had was what the federation (here: a curated list of academic
IDPs in the country) offered/contained.

But the Shib SP certainly wasn't /designed/ for the "many separate
logical SPs at scale" use-case and judging from the number of people
requesting this that hasn't been an issue so far, AFAIK.

> In shib config terms, these are two applications with separate
> entityIDs and would ideally share nothing in their
> ApplicationDefaults.

You might consider coming at this differently (than wanting full
separation), e.g. vhost-based separation works just fine and will
likely be sufficient for your use-case, which does not require
any Overrides at all.

Also it may not be necessary to isolate the IDP metadata for each
"customer": Just have the SP load all the (union of) IDPs any of them
need -- access control needs to (and fully can) happen based on
attributes within each vhost and does not require keeping the IDP
metadata separate.

> * use RequestMapper to assign an ID to my second application

FWIW, I don't think you ever need the RequestMapper on Linux/httpd.

> But otherwise I'd like to establish a template for how to do this
> configuration, ideally in such a way that:
> 
> * there is no possibility of the configuration of one site leaking into
> another (as seems a risk if the first application is at the top level of
> ApplicationDefaults and all the rest are in their separate
> ApplicationOverride block but inheriting the defaults)
> 
> * the configuration for each site is held in a separate set of files, for
> greater portability if a site moves to a new server.
> 
> * there is separate logging for each application

Scott will provide you with the defintive answers, of course.
The above is not what the Shib SP excels at but IMO it should still
allow you to functionally achieve what's needed (without providing the
desired levels of separation, though; for logging you'd use syslog and
do any separation there, though you may not have the required
information available).

Other SAML implementations might be more suited to such requirements,
I think. E.g. SimpleSAMLphp has config files that are just PHP code,
so you can do pretty much anything you want in many places of the
software, including to load/require different config snippets
dynamically (from where to load metadata, where to put log files,
etc.) depending on the HTTP/1.1 Host header or whatever.
While SimpleSAMLphp does not limit you to SAML it does limit you to
PHP, though. So for a service working with arbitrary APIs / languages
at the level of the web server -- the way the Shib SP does -- you'd
have to add another component to actually protect the content, in this
case mod_authmemcookie. That httpd module then dispatches requests to
an SSP instance for the SAML handling. The SSP docs should cover all
of that.

HTH,
-peter