CA SiteMinder Admins Guide to ForgeRock OpenAM: Part 1- Infrastructure Architecture

Recently I joined ForgeRock as a senior consultant. After almost 15 years in the ops and integration world, working with SiteMinder, a bunch of peers have been asking me how SiteMinder compares to OpenAM and how they differ. So, now as a fully biased ForgeRock employee, I am documenting the process of translating that SiteMinder suite knowledge into OpenAM.

In a series of blogs I will describe OpenAM from the viewpoint of a SiteMinder Admin, mainly myself, learning the similarities and differences as one with such background wishes to quickly come up to speed with ForgeRock’s OpenAM platform. The scope will not be to compare point by point every single feature of SiteMinder and OpenAM, but will be an introduction to OpenAM by deployment and integration of a sample app. 

The Basics - Infrastructure Overview and differences

SiteMinder: SiteMinder requires a JDK for installation and an ldap instance to configure as the policy store. In addition, a separate install of an app server (like tomcat) and deployment of the SiteMinder UI is needed. It is then configured against the SiteMinder Policy server in order to manage the environment.

OpenAM: OpenAM requires a Java Application server, like tomcat, to deploy the openAM.war file. In addition, an ldap instance is used as a configuration policy store. 

One key difference of the OpenAM platform will be the amount of built-in services that are available. Not, integrated, but core service capabilities of the OpenAM product. For example, if you require federation services, it is an additional installation of a servlet or app server, and a session DB or CA Directory for SiteMinder to offer the capability.

If you also require Advanced Authentication and a Risk engine with OTP features, SiteMinder requires the addition of the CA Strong Authentication (Arcot) components. This requires 3 installations, StrongAuth, RiskAuth, and a customized adapter deployed on a java app server. An Oracle or MS SQL DB is also required for user registration and profile information. 

Finally, if you need to expose these services via a REST interface, none of the components offer this natively. CA Strong Auth exposes its services via WSDLs. In order to abstract all these services through a REST interface, you can deploy a CA Layer7 soft appliance. It is an API gateway that allows you to expose SiteMinder authentication via an embedded agent on the gateway. You can also translate the Strong Auth WSDLs as REST endpoints.  Layer7 can be deployed as a hardware or soft appliance as well as built on your own platform. It is made up of a web app deployed on tomcat with a MYSQL embedded DB.

This diagram illustrates the problem with acquisition architecture. Your infrastructure sprawl get big quickly. With no redundancy, you are already looking at a sizable footprint of VMs, DBs, and App Servers; not to mention the firewall rules and VIPs you will need as part of the inter-component communications. I deployed this in my previous position. You quickly get into scalability and APM issues.

By comparison, OpenAM is a single deployed war file that contains all of these services and all accessible via RESTful interface. 

Try it for yourself. Download the software at https://forgerock.org/downloads/ and discover the differences and simplicity of the ForgeRock platform.