Wandering Thoughts archives

Using reverse proxies to unify web sites

At least around here, it's common for a department to have a number of different administrative groups inside of it, all of them providing services (whether internal or external). Generally this produces a profusion of group websites, partly because each group has different needs and partly so that no single group is stuck with the job of being responsible for a web server that contains everything, including peculiar applications that they don't understand and can't touch.

It's recently struck me that one of the things you can do with reverse proxies is stitch together all of these websites and web services under one 'public' namespace and website. This gives users a single place to go to and, more importantly, a single place to remember, especially if you create some sort of top level index to all of the services (which you should have anyways).

(It also makes it easier to change who is responsible for services, because their URLs don't have to change if they move between groups or the like.)

The one drawback to this rosy picture is that the authentication for everyone's services is now going through a central place, because all of the HTTP traffic has to pass through the reverse proxy machine. Since a compromise of that machine puts the passwords for each group's services at risk, all of the groups have to have a decent degree of trust in the central website and the people who run it.

Note that each group can keep on doing its own authentication for the services it provides; you don't have to try to build a single sign on system for this apparently unified website. (Your users will probably thank you if you do, though. And if you do it right, groups will find it much more attractive to use your authentication instead of building and managing their own.)