Architecture when deploying Gluu

By: Jesús JM user 24 May 2019 at 3:15 a.m. CDT

2 Responses
Jesús JM gravatar
Hello guys, I'm trying to figure out what is the optimal solution the network's topology where I am deploying Gluu. I'm certainly new to IAM servers, so I hope you can clarify my doubts. The architecture for my network was designed to have the following entities (I'm obviating those which are not relevant for this question): - Several web services - A reverse proxy that would redirect the traffic to the services above. It is implemented with an Apache server with version 2.4.18. - Gluu as IAM server I've read several support tickets related to reverse proxy (e.g. [gluu behind reverse proxy](https://support.gluu.org/customization/3493/gluu-behind-reverse-proxy/)). My intention was to deploy Gluu behind the reverse proxy, and make it accessible from outside the network through it. I've tried to write the rules needed for forwarding the Gluu traffic, but I can't really made it work. With no results, I've changed the approach and edited the Apache http file from Gluu directly to make Gluu act as reverse proxy, instead of having an standalone server in front of it. This approach worked for me, but I think it's not how the things should be done. I've seen other people having issues to deploy Gluu behind a reverse proxy, so my question is: does it make sense to have Gluu behind a reverse proxy, or is it mandatory to be facing to the Internet? What is the appropriate architecture for this use case? Looking forward for your feedback. Thank you!
Ubuntu 18.04
closed

Answers

By Michael Schwartz Account Admin 24 May 2019 at 4:11 a.m. CDT

Copy
Michael Schwartz gravatar
oxAuth (OAuth) / Shibboleth (SAML) are, by definition, Internet facing. oxTrust (admin UI) should not be Internet facing. And of course, LDAP should not be Internet facing (it listens on localhost by default in the Gluu Server). Some customers do use a proxy layer in front of Gluu as an additional layer of security, but it's not necessary. You can either continue to use the Apache HTTPD server or proxy directly to Jetty. But in general, I don't think it's problematic from a security perspective to have oxauth/shibboleth be internet facing. The worst that can happen is that the there is an SSL bug which exposes the SSL keys. But this can happen with any TLS web server. The apache server itself does not have access to the JVM, so your private keys for federation are protected. Net-net, I would say keep it simple. More complexity frequently leads to less security anyway.

By Jesús JM user 27 May 2019 at 6:16 a.m. CDT

Copy
Jesús JM gravatar
Hello Michael, Thank you for your reply! I understand that from security point of view it is not mandatory to have Gluu behind a reverse proxy, but I'm also interested from the point of view of infrastructure. Let's suppose we have a small business network with the following restrictions: - One ISP line - Several web services that need to be served through HTTPS 443 port - IAM server ![network-infrastructure](http://i64.tinypic.com/ing9kl.png) If I understood it right, since Gluu should not be behind a reverse proxy, we need to take a decision between the following: - Serve Gluu in a non-default HTTPS port - Deploy Gluu as IAM server and reverse proxy simultaneously - Serve Gluu in a third-party cloud-hosted service - Add a second ISP line (i.e. static IP) for Gluu I know this question is related to network topics and is out of the scope of your support, but I think it can help other people that are new to IAM technologies as me. Since it is not quite obvious why an IAM server should not be behind a reverse proxy, I think it can be a good start point for new people. Again, thank you very much for your support!

Post an answer