CA SiteMinder Admins Guide to ForgeRock OpenAM: Part 2- Policy 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. 

Part 1 - Infrastructure Architecture

Part 2 - The Basics - Policy Overview and differences

In essence, all access policies are defined with some of following components:

A Tenant boundary,

A target user data source,

A defined enforcement point (or agent),

A protected resource

An authentication mechanism

A Response post authentication

A Policy access rules

Biggest learning curve for SiteMinder Admins to understand OpenAM is the the differences in how you create policies. The steps might be similar but it comes down to the flow and terminology of what you are used to in SiteMinder versus OpenAM. 

For reference, this is how the dependancies of the SiteMinder objects can be mapped out. 

When integrating a new application into SiteMinder, there is a usual process I follow. It based on the dependancies tower. Each step in the configuration will need a previous step as a prerequisite. These are the minimal logical access policy requirements. 

For SiteMinder, a typical process follows as:

1) create Agent Object

2) create ACO which references the Agent object

3) install and configure agent on web server

4) create User Directory (UD) configuration object 

5) create domain object (Tenant boundary) which references UD object

6) create realm under the domain object and associate with Agent and define a resource filter and authentication scheme. 

7) create rules for the realm (such as get/put, On authentication, authorization, or rejection actions)

8) create responses

9) create policies that tie the UD and rules and responses

While not encompassing of all capabilities and possible integration scenarios, these are typical steps requires to integrate with a basic application. 

For reference, this is how the dependancies of the OpenAM objects can be mapped out. 

When integrating a new application into OpenAM, there is a usual process as well. These are the minimal logical access policy requirements. 

For OpenAM, a typical process follows as:

1) create realm (Tenant boundary)

2) configure DataStore

3) configure Authentication chaining

4) Create a Policy (target resource, actions, subjects which reference the datastore, env conditions and response attributes)

5) create a web agent profile

6) install and configure agent on web server

Next Steps - doing a basic install and configuration. 

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