Cloud Security for PAAS and SAAS Use Cases

One of the really interesting things about working in the security area, is that you get to learn about a lot of different technologies. In order to work to integrate/diagnose/optimize security into some container, you have to get a pretty good understanding of that container works. This has created good opportunities for me to learn about a ton of different technologies over the years. But recently, I have to admit, I became a little uneasy when I started preparing for a meeting on securing their cloud.

I know that people use SOA and Cloud and PaaS (Platform as a Service), IaaS (Infrastructure as a Service) and SaaS (Software as a Service) in some what overlapping ways, and I am in no way an expert on "the cloud" and all of the different layers, but there have been two recent use cases, that I'm bundling in this post as "Cloud Security Use Cases".

PaaS Secured By Oracle Identity Management

So, in this case, the Platform is WLS. Imagine adding WLS instances on-demand, and having them pre-configured with applications, or just environment suitable for a certain class of applications. When the domain is configured, what should the security be? In this use case, lets assume that its impractical to have each domain be totally isolated. Isolation in this sense means that all of the security infrastructure is also contained inside of the Node (droplet?) in the Platform cloud. The WebLogic platform needs to make use of a shared Identity Management infrastructure - Web SSO, User Authentication, Audit.

The core security configuration in WebLogic Server for a domain in a realm. Configuring a realm to accept tokens from the Web SSO infrastructure is pretty straight forward - though typically there may be some Web SSO specific configuration like the creation of trust between the PEP and the PDP. Authentication is straight forward as well - all instances point to a common LDAP configuration. The audit configuration is simple as well - either local file audit or configured to point to a centralized service.

Authorization becomes a little more interesting. I think the type of authorization that needs to be configured depends of the requirements of the application(s) running on the domain. If you need basic JEE authorization, contained in the deployment descriptors of the application, you can use the default XACML provider. If you wanted centralized authorization, you'll need to deploy the realm with Custom Roles and Policies, and configured Authorization and Roles providers that support centralized management - like Oracle Entitlements Server (OES). OES administration is performed centrally from the OES admin server, but the policy enforcement can be done either inside of the container (WLS-SM) or from a central service (WebService/RMI-SM). The WLS-SM makes the decisions with lower latency, so its best for applications which require low-latency decisions. The WebService and RMI SM use the same engine and are just as fast, but once you add in the latency of SOAP or RMI, the latency goes up and through-put goes down. Essentialy, from a cloud perspective, you have a few different flavors of platform (JEE Security, Centralized Admin/Centralized Enforcement, Centralized Administration/Local Enforcement)

Obviously, in this model with applications running in the cloud, it would make sense to have the supporting Identity Management technologies running in a cloud as well, but that is a post for another day ;)

More details on using WebLogic and PAAS can be found here

Multi-tenant SaaS Secured By Oracle Identity Management

In this model, the Identity Management pieces are running as part of the application node. Basically, each domain of WebLogic Server uses its own Authenication and Authroization services. This is because each domain represents a unique customer of a service, and in this example, lets assume that there are rules prohibiting the sharing of data across customers. Cloud makes sense here, since its easy to isolate the customers from each other. But, what if a use case arises where their needs to be sharing of information across customers, for example if two customers merge or if several customers work in some sort of partnership.

The answer is to create a new domain for the merged company/partnership and then virtualize the information of each individual partner behind the new entity. This actually can be a pretty elegant solution to what is basically an edge case. 99% of the scenarios in multi-tenancy have customers isolated, but these use cases can add a lot of complexity - example: pushing down the tenant_id filter to the databaase or complexity with LDAP schema design. The preferred alternative here is to try to address these use cases with the cloud directly. In specific, use Oracle Virtual Directory (OVD) to build a unified view of all of the users and ODSI Suite to virtualize the data across the data of each individual partner.

Fortunately, WebLogic Server supports multiple realms, so you can configure a domain with one realm for each type of model you'll need in the cloud, and then you can simply switch the active realm for the domain. This means that once deployed, to change the way that the domain interacts with the Identity Management system can be changed very easily, which is the whole point of putting things in the "cloud" in the first place.

Conclusion

These use csaes are the first that I've seen with actual customers, but I suspect, given all of the excitement around the cloud, that there are more out there. I encourage people to share them on this blog, so that we can have a "grounded" discussion about this topic.

Happy Thanksgiving