Shibboleth

Adds support for running a Shibboleth Service Provider.

This is done by installing the Shibboleth SP software and running an apache with mod_shib.

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.

The Shibboleth metadata is also generated by this puppet work and is served by Nginx.
It's available at the typical endpoint at /Shibboleth.sso/Metadata.
Usually, it's the Shibboleth SP that outputs this metadata, but the data it outputs
does not work well in a multi-tenant environment.

There are 2 new modules included that are required to support this work:
 * puppetlabs/apache
 * puppetlabs/concat (The apache module requires it)