gluu behind reverse proxy

By: Stefan Sels user 22 Nov 2016 at 8:54 a.m. CST

21 Responses
Stefan Sels gravatar
do you have any best practices or configuration examples to use a gluu server behind an reverse proxy? I found some general remarks on that and images describing such setup but would be interested if gluu has documentation on that. Like we would like to use https://example.site.com/sso -> https://glu.server.com/ with apache ProxyPass / ProxyPassReverse (or nginx).
Rhel72
closed

Answers

By Mohib Zico staff 22 Nov 2016 at 9:03 a.m. CST

Copy
Mohib Zico gravatar
>> Like we would like to use https://example.site.com/sso -> https://glu.server.com/ with apache ProxyPass / ProxyPassReverse (or nginx). You mean.. the main SSO page of Gluu Server? i.e. User will hit 'https://example.site.com/sso' and it will redirect to 'https://gluu.server.com' for authentication?

By Stefan Sels user 22 Nov 2016 at 9:08 a.m. CST

Copy
Stefan Sels gravatar
No it would never redirect to different server (but to itself). The Server (example.site.com) would proxy all requests below /sso to the gluu server (https://gluu.server.com/) so that it would integrate avoiding redirects out of example.site.com. Links and redirects would be rewritten from the example.site.com proxy. for example: ``` SSLProxyEngine On RequestHeader set Front-End-Https "On" ProxyPass /sso/ https://gluu.server/ ProxyPassReverse /sso/ https://gluu.server/ ProxyHTMLEnable On ProxyHTMLURLMap https://gluu.server/ /sso/ ```

By Mohib Zico staff 22 Nov 2016 at 9:19 a.m. CST

Copy
Mohib Zico gravatar
Ok. No, we don't have any doc as none of our customers are using such setup and I doubt it will work because of apps will be connected with hostname and even SAML cert or OP key are tightly coupled with hostname. But.. .we can try to reproduce your scenario locally and see how it goes; so please allow us to ask few questions... >> The Server (example.site.com) What is this server? What is the app name? How app will be connected with 'example.site.com' and 'gluu.server'? How authentication flow might go back to app through example.site.com?

By Stefan Sels user 22 Nov 2016 at 9:25 a.m. CST

Copy
Stefan Sels gravatar
example.site.com would be an software (apache,nginx) or hardware loadbalancer (bigip). Regarding the appname/hostname. The IdP/gluu Server would never notice the external name as it is rewritten by the proxy. Like the User/Browser would get a "real" SSL Certificate, the proxy terminates the SSL session and build another session to the gluu server. If needed the proxy rewrites responses (headers, cookies) to match the external certificate (like we have an wildcard *.domain.com certificate). From the gluu server perspective, all calls would be made to its hostname/cn it is configured on from the proxy.

By Mohib Zico staff 22 Nov 2016 at 9:34 a.m. CST

Copy
Mohib Zico gravatar
Thanks a bunch for clarification, Stefan. Couple of points ... >> example.site.com would be an software (apache,nginx) or hardware loadbalancer (bigip). I would highly suggest you not to change the LB hostname. LB and it's associated Gluu Server nodes should follow same hostname ( yes, your internal hostname of VM might be different but Gluu Server installation must have to follow the hostname which you will use for your LB ). >> the proxy terminates the SSL session and build another session to the gluu server. Don't terminal SSL session from LB, it won't work. SSL is everywhere inside Gluu Server. Now.. if you want how to configure a BigIP LB, we can share some info with you which might help you.

By Stefan Sels user 22 Nov 2016 at 9:38 a.m. CST

Copy
Stefan Sels gravatar
We already have BigIP loadbalacing in front of a gluu server (with its own name as within its certificate). We now are working on a PoC and one idea is to check if it is possible to hide such server behind a revsere proxy.

By Stefan Sels user 22 Nov 2016 at 10:34 a.m. CST

Copy
Stefan Sels gravatar
found a setup that works pretty nice: ``` <Virtualhost *:443> ServerName <your-ip-or-name> DocumentRoot /var/www/documentroot SSLProxyEngine On RequestHeader set Front-End-Https "On" ProxyPass /identity/ https://gluuserver/identity/ ProxyPassReverse /identity/ https://gluuserver/identity/ ProxyPass /oxauth/ https://gluuserver/oxauth/ ProxyPassReverse /oxauth/ https://gluuserver/oxauth/ ProxyHTMLEnable On ProxyHTMLURLMap https://gluuserver/identity /identity/ ProxyHTMLURLMap https://gluuserver/oxauth /oxauth/ ProxyPassReverseCookiePath /identity /idenity ProxyPassReverseCookiePath /oxauth /oxauth SSLCertificateFile /etc/apache2/ssl/apache.pem SSLCertificateKeyFile /etc/apache2/ssl/apache.key </Virtualhost> ```

By Stefan Sels user 22 Nov 2016 at 10:35 a.m. CST

Copy
Stefan Sels gravatar
not sure if ProxyPassReverseCookiePath is still needed as it is from testing a prev. setup.

By Mohib Zico staff 22 Nov 2016 at 12:20 p.m. CST

Copy
Mohib Zico gravatar
>> found a setup that works pretty nice: What does that script do? Change apache configuration? Inside LB or Gluu Server?

By Stefan Sels user 23 Nov 2016 at 2:58 a.m. CST

Copy
Stefan Sels gravatar
thats an apache vhost definition for example.site.com with embeded proxy to a gluu instance. for everything /identity and /oxauth it behaves like glue, the rest of it could be the normal application/website

By Stefan Sels user 23 Nov 2016 at 3 a.m. CST

Copy
Stefan Sels gravatar
I will add some rewrite rules to prevent redirect loops but it works nicely at the moment.

By Mohib Zico staff 23 Nov 2016 at 4:10 a.m. CST

Copy
Mohib Zico gravatar
Thanks; please let us know how it works. This will be really interesting subject.

By Stefan Sels user 23 Nov 2016 at 4:17 a.m. CST

Copy
Stefan Sels gravatar
it works. I am now playing around with https://github.com/pingidentity/mod_auth_openidc/ and https://github.com/jumbojett/OpenID-Connect-PHP to validate users. another glitch I need to address is to rewrite the urls within oxauth/.well-known/openid-configuration to match the reverseproxy. But that could be done with mod_substitute or even a static file with the loadbalancer configuration/URIs.

By Mohib Zico staff 23 Nov 2016 at 4:32 a.m. CST

Copy
Mohib Zico gravatar
>> it works. German Engineering... best of the best in the world!!

By Yi Sheng Yap user 25 Nov 2016 at 4:41 a.m. CST

Copy
Yi Sheng Yap gravatar
Hi Stefen, I'm trying to do similar things and this thread helped. :) I've managed to get the proxy running and have it display the login and submit the login. But I've hit a redirect loop back to https://{proxy_host}/identity/authentication/authcode#session_state={session}&scope=user_name+email+openid+profile&state&code={code}&id_token={token} with token changing. Do you have this too?

By Stefan Sels user 25 Nov 2016 at 6:45 a.m. CST

Copy
Stefan Sels gravatar
Hi Yi, i guessed it was a good idea to set it as public ticket ;) yeah I had that redirect loop, too, did not write an rewrite rule preventing that yet. Maybe a rule that focused on the Cooke state that is also sent, or the combination of fields. Do you use an redirect URL? For me this problem happens only if a user goes back to the login form if he is already authenticated. Another Problem I could only solve by deleting all the JSESSIOND and state cookie was to properly logout a user. going to /identity/authentication/finishlogout did not work (@gluu, would that have been the right link?) As dirty fix you should create a logout.php (or javascript, jsp, whatever) that deletes the relevant cookies. As they are served and saved to the same domain, it would force a logout. Greetings, Stefan

By Yi Sheng Yap user 27 Nov 2016 at 11:21 p.m. CST

Copy
Yi Sheng Yap gravatar
Thanks Stefan, I'm new to Gluu so I need to find out what and where these settings you've mentioned is. Redirect URL, maybe some other settings to fix the redirection. I've created a repository to try/test too. https://github.com/o20ne/httpd-reverse-proxy Cheers and Regards, Yisheng

By Stefan Sels user 28 Nov 2016 at 1:43 a.m. CST

Copy
Stefan Sels gravatar
Redirect URL/URI is Openconnect. You can add one (or more) to your clientid, and then give it as a parameter to your request. oxauth/seam/resource/restv1/oxauth/authorize?client_id=@<yourclientid>&redirect_uri=https://somewhere&response_type=code you need to enable response_type code for that client, too. (will follow you as @tronicum at your github project)

By Yi Sheng Yap user 28 Nov 2016 at 2:37 a.m. CST

Copy
Yi Sheng Yap gravatar
Thanks again Stefan for guiding. I've just tried adding these to **oxTrust Admin GUI** under https://gluu-server.host.com/identity/client/inventory?searchPattern=&cid=45 - https://localhost:8443/identity/scim/auth - https://localhost:8443/identity/authentication/authcode - https://localhost:8443/idp/auth-code.jsp - https://localhost:8443/cas/login It doesn't work or I've missed something. Instead of update, adding a new client needs a secret. Being a proxy, I should use the same secret? How do I get the secret of existing client? @gluu - Please let me know if I should create a new ticket?

By Stefan Sels user 28 Nov 2016 at 3:11 a.m. CST

Copy
Stefan Sels gravatar
yeah we might move this to another ticket. use "openid connect" -> clients, empty search, click on your client, change password to change secret. i guess you cant see it once added. the redirect url should be your application, like www.myapp.com/sso/myscript.php/jsp/.js. then you would point your user to redirect there and validate the tokens/state.

By Stefan Sels user 29 Nov 2016 at 8:10 a.m. CST

Copy
Stefan Sels gravatar
whoever might try to use an reverse proxy: The certificate/domain of the IDP needs to match the domain of the reverse proxy (e.g. example.site.com=gluu setup.py domain)

Post an answer