Shibboleth

I've refactored the Shibboleth authentication strategy in favour of using the standard Shibboleth Service Provider software.

This does mean we will have to run Apache + mod_shib in order to do proper authentication. However, this also means we can gain access to federations much easier. We can also start supporting built-in SAML
functionality such as WAYF and/or discovery.

When a user wants to authenticate with Shibboleth the following auth flow takes place:
1. The user browse to /api/auth/shibboleth
2. He is redirected to /Shibboleth.sso/Login?entityID=https://id.of.idp&return=https://hostname.of.tenant/api/auth/shibboleth/callback
3. This request is proxied by nginx to apache at localhost:8080 (and preserves the host header)
4. The request is passed on to mod_shib which starts the Shibboleth authentication flow and will redirect the user towards the IdP
5. When the user authenticates with the IdP, he will return to /Shibboleth.sso/SAML2/POST where the request is validated.
   This is again proxied to apache and mod_shib
6. If the request is valid, mod_shib will initiate a session and set a cookie for that user.
   Finally, the user is redirect /api/auth/shibboleth/callback.
7. This is again proxied to apache and mod_shib, where the cookie is checked against the sessionstore. If it's a valid session cookie, apache will proxy the
   request to the appserver (/api/auth/shibboleth/callback) and add the necessary headers in the request.
   These headers can be used by the OAE app server to getOrCreate a user account.
There should be no changes needed in the UI (for the authentication bit). That said, it would be good if there was some client validation that we cannot create a tenant with the same `config.servers.shibbolethSPHost`. That might be a bit overkill for now though.