Tuesday, August 6, 2013

Taking reverse proxy functionality into account within your software architecture

Within the Java project I am currently working on we had to deal with lots of security related questions and challenges.

The project itself is a Java project created with the following stack:
- Spring MVC (Controller)
- Apache Wicket (frontend)
- Spring / Spring Data / Apache CXF (Business & Service Layer)
- Hibernate (Model)

The application itself is deployed within a high-available environment.

One of a list of system architectural decisions we made was to handle all of our SSL trafic not within the application servers itself (using apache mod_ssl), but instead move it to the load balancer which is placed within the DMZ and actual acting as a reverse proxy.

This design has several advantages, both technical and from a maintenance point of view:

  • The SSL certificates and private keys are centralized on the reverse proxy service which simplifies key management. Not every application server within your application server cluster has to be polluted with SSL code and logic. In this way the responsibility and maintenance of this PKI management stuff can most of the times also move from project to hosting provider of your application.
  • The proxy server can terminate the SSL handshake and traffic from the proxy server to the application server cluster can be done using plain HTTP. This will lead to an improved performance of your application logic.
  • Upgrades of application servers can be done more easily. Switching to a new application server only requires reconfiguring the reverse proxy server to point to the new application server.
  • Improved security of your total application landscape when using a reverse proxy within a DMZ.
The message what I want to address is that you have to look further than only your software architecture environment, and also take the total system architecture including DMZ into account!!!!