It’s been quite a while since I’ve had the time to write a new post here, but that’s not because there is nothing interesting to discuss. On the contrary, the absence of any new posts was actually a reflection of how busy I have been over the summer. For at least the last 4 or 5 months, I’ve been pretty much “heads down,” working on some interesting security challenges for our Pivotal Cloud Foundry customers. The good news for all my loyal readers is that, in that time, I’ve built up quite a backlog of interesting stuff to write about. And now that fall is in the air, I’ve finally gotten to the point where I’ll have some time to share what I’ve been up to. I promise that it will have been worth the wait.
My Most Recent PoC Effort
I’ve recently completed an interesting project in which I’ve successfully migrated a secure enterprise Java Web application into Cloud Foundry. This was a Proof-of-Concept effort, but it was by no means a “Hello, World!” exercise. The application was non-trivial, and had a number of interesting security requirements. The overall goal was to demonstrate to a customer how an existing Java Web application (one that already followed all the current best practices for securing enterprise deployments) could be successfully migrated into the Cloud Foundry environment. And now that it’s happily running in Cloud Foundry, the application benefits from all the additional capabilities of the PaaS, while still maintaining all the same enterprise security features as before.
In order to respect the privacy of the customer, I won’t be able to discuss the actual customer application, which is proprietary. Instead, I’ve decided to describe this effort in terms of another, equivalent, secure Java Web application — one that has the benefit of being available in open source, and has the same basic security properties as the real customer application. The sample application we’ll be using is the FortressDemo2 application, written by my colleague Shawn McKinney. As noted, this code is available in open source (with good license terms 🙂 ) and it is an excellent example of how to properly implement a secure Java Web application.
The Target Application Requirements
The FortressDemo2 application uses an RDBS for storing customer data, and depends on OpenLDAP as it’s policy and identity store. The application uses JEE container-based security (e.g. a custom Tomcat Realm) for authentication and coarse-grained authorization. Internally, the application leverages Spring Security to implement its page-level policy enforcement points. All interprocess communications are secured via SSL/TLS. Thus, the user’s browser connection, and the connections made from the application to the database, and the application to the OpenLDAP server are all secured using SSL/TLS. Finally, the certificates used for these SSL/TLS connections have all been issued by the enterprise security operations team, and so have been signed by a Certificate Authority that is maintained internally to the enterprise. As noted, this application is a perfect proxy for the real thing, and so if we can show how to run this application in Cloud Foundry, then we can successfully run a real customer application.
So, to summarize, the requirements we face are as follows. Deploy a secure Java Web application to Cloud Foundry, including:
- Use of SSL/TLS for all inter-process communication, with locally issued certificates.
- Secure provisioning of SQL database credentials for access to production database.
- Configuration of a customized JSSE trust store.
- Configuration of a custom Tomcat Realm provider for JEE container-based security.
In the next few posts, I’ll be describing what you need to know to achieve these security requirements, and successfully migrate your own secure enterprise Java application into Cloud Foundry.