Page Comparison

...

1. The client attempts to access https://proxy.example.org/secure
2. The reverse proxy at proxy.example.org internally forwards the request to http://resource.example.org/secure
3. The location /secure on the resource is protected by a Shibboleth SP
4. The Shibboleth SP intercepts the request and generates a SAML2 AuthnRequest with an AssertionConsumerServiceURL of https://proxy.example.org/Shibboleth.sso/SAML2/POST (assuming default locations and a properly configured web environment on proxy.example.org. If proxy.example.org hasn't been configured correctly's web server configuration is not correct, a variety of wrong URL's may be generated here.)
5. Also the relayState for the requested URL is set (e.g in a HTTP cookie).
   • Note that the path (/secure) to the requested resource is set by the Shibboleth SP and hence is specific to the protected resource on the web server. This mandates that the proxy either proxies the resource with the exact same path (/secure to /secure), or that the proxy is able to rewrite HTTP resonse headers (e.g. the ones containing the relayState) before returning results to the client.
6. The client authenticates at an IdP and bounces back to https://proxy.example.org/Shibboleth.sso/SAML/POST with an authentication (and probably also an attribute) assertion.
7. The resource gets the request forwarded from proxy.example.org
8. If there's no attribute assertion the Shiboleth SP at the resource may also query the IdP for attributes (Note that queries from the Shibboleth SP will not go though the proxy described in this document). The SP redirects to the resource specified in the relayState, applies any authorization logic and returns the page (to the proxy, and the proxy to the client).

...