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:
https://mainsite.example.org/secure
;proxy.example.org
intercepts the request and acts as mainsite.example.org
;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);https://mainsite.example.org/Shibboleth.sso/SAML/POST
with an authentication assertion;mainsite.example.org
.https://mainsite.example.org/secure
and applies auth/z logic.All information in the Shibboleth configuration should regard the proxy itself, since the browser believes it's interacting directly with the 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.