The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
SPForwardProxy
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 asmainsite.example.org
; - The Shibboleth installation on the proxy also intercepts the request and generates a redirect with a
SHIRE
value ofhttps://mainsite.example.org/Shibboleth.sso/SAML/POST
and target value ofhttps://mainsite.example.org/secure
(with the appropriateproviderId
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.