current recommended practice, proxy in front of several protected sites

[Peter Schober]

Steven,

* Steven Carmody <steven_carmody at brown.edu> [2018-02-09 18:02]:
> One of our depts has decided to move to using the central campus Shib-SSO
> service to control access to many of their web sites. They would prefer to
> avoid installing a SHib SP on all of those servers (yes, I know, "google
> puppet" ;-) ). They would prefer standing up a proxy, and sending all
> traffic thru the proxy in order to access the various protected resources on
> other servers. I assume they want the SAML attribute values sent thru to the
> backend servers, for use in access control decisions.
> 
> What's the current "recommended practice, and software" for doing this ?
> People used to use simplesamlphp to do this; there's now SATOSA; there are
> probably other options, too.

>From your description above they want an HTTP Reverse Proxy (i.e., web
browser connects only to the proxy, the proxy then passes HTTP Request
Headers with attributes to the proxied resource servers; only the
proxy connects to the resource servers via HTTP/S, not the subject's
web browser), *not* a SAML proxy (where the resource servers themselfs
would have to be SAML SPs, the very thing you say they want to avoid).

So no, not SimpleSAMLphp or SATOSA. Just httpd, Shib SP + mod_proxy.
(Or nginx, if you want to complie that from source in order to use the
Shib SP via FastCGI.)

> And, are there pages that can be shared with this dept describing
> how this works, how to organize it, etc ?

My advise would be to not do this and to learn how to SAML-enable
those applications (instead of learning how to Reverse Proxy-enable
those applicatons): Since most of the work will be with application
integration (and not installing and pushing out Shib SP configuration
files, as you mentioned) that leads to more bang for the buck.

With multiple resources acting as /multiple/ SAML SPs the IDP could
treat each one differently, could be showing the subject appropriate
data about the service before even accessing the SP (e.g. its name,
description, privacy policy, attributes to send, et.) and by sending
each SP only the attributes it wants/needs.
Also not all resources will have to be protected with the Shibboleth
SP, some might already support SAML out of the box (or with add-ons).

With the proxy in place and everying being one SP the IDP could only
send the union of all attributes all proxied resource servers
need. Unless you'd want to virtual multiplex SPs on the proxy (would
probably require a vhost for each proxied app, as proxying based on
the path/REQUEST_URI might not work with some/many applications.)

Both SAML and TLS terminate at the HTTP Reverse Proxy in the scenario
asked about. All the user data is in the clear at the proxy. Unless
the proxy rewraps everything in (another) TLS tunnel all the user data
will also be in the clear from the proxy to the resource servers.

Not all applications will be able to rely solely on HTTP Request
Headers. Not all applications will be able to be reverse-proxied since
that requires generating self-referencing URLs with the host name and
schema/port of the proxy (plus the path/REQUEST_URI the resource is
mapped to at the proxy) not of the actual resource server's name, etc.

Finally HTTP Request Headers come from the HTTP user agent (in this
case the HTTP Reverse Proxy, in the non-pathological case) and
therefore can easily be spoofed by any other HTTP user agent able to
connect to the proxied resource. So the proxied resource servers will
need to take some precautions against that. Shibboleth or TLS can't
protect from that (since Shib/SAML terminated at the proxy and TLS
can't guarantee authenticity of the payload).

Other than that there's the documentation:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPOneMany
HTH,

-peter