Hello,
I have installed and configured a Shibboleth IdP running on an application server (hostname “application.idp.com”) located behind a Reverse Proxy (hostname “rp.idp.com”). I am using SAML 2 POST Profile.
Then, from user’s browser, the “AuthenRequest” message is posted to the URL “http://rp.idp.com/idp/profile/SAML2/SSO/POST”. The Reverse Proxy rewrites the HTTP request URL to “http://application.idp.com/idp/profile/SAML2/SSO/POST” (but the “AuthnRequest” message is not modified).
Therefore, when Shibboleth application receives this request, there is an error because the “intended destination endpoint” (read from “AuthnRequest” message, “http://rp.idp.com/idp/profile/SAML2/SSO/POST”) is different from the “recipient endpoint” (read from HTTP request, http://application.idp.com/idp/profile/SAML2/SSO/POST”).
Is there a way to configure Shibboleth IdP application to avoid this problem when located behind a Reverse Proxy?
Or should I modify the “checkEndpointURI()” code in “BaseSAMLMessageDecoder” class to solve this problem ?
Thank you in advance for your answers…
Regards,
|
Olivier CHARTREL Capgemini Division Sud - ADC Bureau V1.6 - 15, avenue du docteur Grynfogel - BP 53655 - 31036 Toulouse Cedex 1 : MSN Messenger: olivier....@hotmail.fr
|
P Please consider the environment and do not print this email unless absolutely necessary. Capgemini encourages environmental awareness
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Configure it with the correct (public) host name?
You will also need to virtualize the ports, since you're doing SSL
offloading as well. If you're using Apache httpd and connecting to
Apache Tomcat via AJP you need to set this on Tomcat's AJP connector
(since httpd's ServerName is not carried forward through AJP, it
seems).
-peter
* Peter Schober <peter....@univie.ac.at> [2009-09-15 16:42]:
> Configure it with the correct (public) host name?
Sorry, sent to fast.
Actually I think the proxy mustn't rewrite the request.
-peter
In fact, one of the purposes of our Reverse Proxy is to "hide" (to Internet users) hostnames of application servers in our DMZ, so we cannot avoid URL rewriting...
Is there a way to disable the security rule that compares the "Destination" URL from "AuthnRequest" message to the URL used in HTTP request received by Shibboleth?
-----Message d'origine-----
De : Peter Schober [mailto:peter....@univie.ac.at]
Envoyé : mardi 15 septembre 2009 16:58
À : shibbole...@internet2.edu
Objet : Re: [Shib-Users] Shibboleth IdP behind Reverse Proxy
Sure. That's what our load balancing and SSL-offloading appliance
does. The Shib IdPs (and httpd fronting them) are configured with the
publicly visible service host name and port (never mind the actual
hostnames are different), the appliance passes though all requests
mostly unmolested.
-peter
Chartrel, Olivier wrote:
> Is there a way to disable the security rule that compares the "Destination" URL from "AuthnRequest" message to the URL used in HTTP request received by Shibboleth?
>
>
No, there isn't currently any way to do this. As I think you saw, that
logic is not actually in a security policy rule (which could be
disabled), but rather is implemented in the binding decoder classes.
One open TODO issue for OpenSAML is to move that logic into a security
policy rule, but it requires some internal rearchitecting of the code,
so hasn't happened yet.
Check the archives, but one solution that I believe has been implemented
by others - for cases where the servlet container doesn't provide a way
to handle this explicitly like for example Apache httpd does - is to use
a servlet filter that provides wrapped versions of the
HttpServletRequest and overrides the appropriate methods to supply
request values that are consistent with the externally facing reverse
proxy, rather than the proxied container behind it.
You could also of course use customized versions of the binding
decoders, but that requires touching more bits in the IdP to make it work.
--Brent
Olivier seems to want the IdP to think its name is <external name> for
all generated protocol messages, but also wants it to think its name
is <internal name> so it will happily accept rewritten messages from
the proxy. So this servlet filter would then have to undo exactly the
rewriting that the proxy had done?
-peter