Deploy the Shibboleth SP on a Forward Web Proxy

Many web hosting environments rely on proxies to manage information on multiple websites that sit behind a central service. Authentication and authorization for systems that are difficult to Shibboleth-enable can sometimes be kludged in this manner. Shibboleth is installed on the proxy itself, but not on the end machines. The flow looks similar to the following:

Browser attempts to access https://mainsite.example.org/secure;
Proxy at proxy.example.org intercepts the request and acts as mainsite.example.org;
The Shibboleth installation on the proxy also intercepts the request and generates a redirect with a SHIRE value of https://mainsite.example.org/Shibboleth.sso/SAML/POST and target value of https://mainsite.example.org/secure (with the appropriate providerId per configuration);
Browser user authenticates and bounces back to https://mainsite.example.org/Shibboleth.sso/SAML/POST with an authentication assertion;
Proxy intercepts the request for mainsite.example.org.
Proxy queries for attributes.
Proxy redirects the browser to https://mainsite.example.org/secure and applies auth/z logic.
Proxy generates and returns the page per usual.

All information in the Shibboleth configuration should regard the proxy itself, since the browser believes it's interacting directly with the proxy.

Multiple Applications Behind One Forward Proxy

One forward proxy may protect a large number of backend systems which could include a variety of trust and attribute requirements. If there is a requirement to establish a distinction between these resources, a separate <Application> element should be defined with special behavior based for each special case.

Just like in situations where a single SP is protecting multiple applications on a single machine, it's most straightforward to assign one providerId per proxied service if the IdP needs to be aware of the distinctions between them. If the IdP doesn't need to know and/or the SP wishes to apply additional filtering, <saml:AttributeDesignator> elements may be specified in the <Application> element to limit the attributes released to this application in the case attributes are being passed along from the proxy to the proxied service.