Conversion of Access Policies from OAM to OpenAM

This post introduces a tool we recently developed to aid the  transition from Oracle Access Manager (OAM) to OpenAM, an access management solution by ForgeRock. Specifically, the tool converts access policies from an OAM instance and translates it to XACML, a standard based policy language supported by OpenAM.


Abstract

As Oracle’s support for some of the older versions of Oracle  Access Manager (OAM) approaches an end, many of the organizations who  are currently on OAM are considering migrating to OpenAM, an open source  access management solution provided by ForgeRock. Despite the growing  demand, there is a lack of tools aimed at facilitating  a seamless  transition between these products. One of the important parts of this  transition is the transfer of access policies from the source product to  the target product. A manual  process of transferring the policies can  be very time intensive and error prone.  We have  developed a tool to  automate the process. The tool is able to interpret access policies from  an OAM instance and translate it to XACML, a standard based policy  language supported by OpenAM.


Introduction

One of the core functionalities of an Identity and Access Management  (IAM) solution is to provide centralized authentication and  authorization to enable secure access across enterprise resources such  as web and J2EE resources. Typically, such access is governed by a set  of access control rules that specify which user can access the resource  and how they can access it. The rules are used to determine the  eligibility of a user to perform certain operation with the resources  under certain circumstances.


Two of the widely used IAM products capable of providing the above  mentioned functionalities are Oracle Access Manager (OAM) and OpenAM.  OAM is part of the Oracle Fusion Middleware, a family of application  infrastructure products developed by Oracle Corporation. OAM is deployed  at many of the largest companies in the Global 1000, and powers many of  the most heavily trafficked portals in the world. OpenAM is an open  source access management, entitlements and federation server platform  developed by ForgeRock. Although, not as widely deployed as OAM, OpenAM  is rapidly gaining approvals among organizations primarily due to its  flexible architecture and very small footprint. Although these two  products have some differences in their features and capabilities,  they share more similarities than differences so clients often view them  as competing products.


With the 11g release of OAM, Oracle is completing the acquisition  process of Oblix COREid (then OAM 10g) through a redraft of the  functional specification and a complete Java based re-write. The 10g and  11g labels make it sound like an upgrade. In fact, particularly due to  the functional re-specification, it is a sea-change.


The older versions of OAM (10g) are approaching the end of their  support lifecycle. With the 11g release of OAM,  Oracle is completing  the acquisition process of Oblix COREid(then OAM 10g) through a redraft  of the functional specification and a complete re-write. So, although  the 10g and 11g labels make it sound like an upgrade, in fact, due to  the functional re-specification, it resulted in a very different  product. Due to this, many organizations are considering switching from  OAM to OpenAM.  However, despite the demand, there are not many tools  available to facilitate that migration. One important part of the  migration is the transfer of access policies from one product to  another. Since OAM and OpenAM differ in terms of storing and expressing  the policies, mechanisms are needed to convert the policies from one  format to another. We have developed a tool that can achieve this.


Design Decisions

In order to make the tool extensible to support different products and product versions, a number of design decisions were made:


  • Using an intermediate format: While converting policies from one  format to another, policies are expressed in an intermediate form. We  have used a predefined YAML template to which the OAM policies are  populated to. The primary reason for choosing YAML over XML or JSON is  YAML’s lightweight syntax and comparatively easier editability.
  • Incoming and outgoing adapters: Version specific adapters were used  to convert the source policies to the intermediate form (YAML) and from  the YAML format to the destination OpenAM version. OAM versions differ  in terms of storing and organizing the policies. For instance, the 10g  versions of OAM store the policies in an LDAP server whereas the post  11g versions moved away from LDAP and use an internal database to store  policies. Also, for 11g versions, the WebLogic Scripting Tool (WLST) can  be used to export the policies (in XML) from the DB. For 10g, no such  export mechanism exist. So, the conversion logic differs greatly for  different OAM versions which emphasizes the need for adapters designated  for specific OAM versions. As OpenAM is consistent in it’s use of XACML  to express the policies, the outgoing adapters that convert the  policies from YAML format to OpenAM’s XACML do not differ significantly.  However, some syntactical differences in XACML expressions between  OpenAM versions signify the need for having version specific adapters.


Conversion Process

The above diagram shows the steps carried out during the conversion  process. Initially, the policies need to be extracted from OAM. For  different OAM versions, the process will differ depending on the  availability of an exporting tool for that version. Once the policies  are exported, the version specific adapter will parse the policies from  their native format and convert them to the YAML format. After that, the  tool will parse the YAML specification and convert them to a set of  Java classes. The Java classes will then be taken by version  specific outgoing adapter which will populate the policies in XACML  format pertained to the specific OpenAM version. The generated policy  needs to be imported to the target OpenAM instance.


Current Status of the Work

Currently the tool supports end-to-end policy conversion for the  following source-target combinations (with the limitations/exceptions  noted later):

  • OAM 11gR1 -> OpenAM 12.x.x.x
  • OAM 11gR1 -> OpenAM 13.x.x.x
  • OAM 11gR2 -> OpenAM 12.x.x.x
  • OAM 11gR2 -> OpenAM 13.x.x.x

Work is underway to make it work for the 10g versions. One challenge  in this, is the lack of tool to export the policies from the LDAP server  into a format that is parsable by an existing tool.


Limitations/Exceptions

The current version of the tool has a number of limitations. We are actively working to resolve the issues:


  • The tool is not able to translate IP based or Temporal policies  defined for OAM 11gR1. However, it is able to do it for the 11gR2  version.
  • In addition to the existing 3 environment conditions (Identity, IP,  Temporal), OAM 11gR2 supports an additional one to enforce the  evaluation of request context, user session state and user’s LDAP  attributes. The conversion tool currently does not handle this type of  condition

Disclaimer

It is to be noted that, not all the policy specifications from OAM  can be translated to XACML. For OAM, a number of configuration details  are included in the policy specification. Examples of such details  include the authentication modules being used, the data store details  etc. Such details are not considered as ‘policy’ in OpenAM realm and  hence not included in the policy specification. Also, some of the  environment conditions that can be specified on an access policy for  OAM, do not have any equivalent attribute on OpenAM and hence can not be  translated. Examples of such condition attribute are:

  • Session creation time
  • Session expiry time
  • Maximum number of sessions by a user
  • Matched domain
  • Name of the agent
  • Matched policy

The goal behind this work is to aid the process of transferring  policy. It locates the common policy elements between these two products  and converts them from one form to another. It is acknowledged that the  tool does not completely eradicate the need of manual intervention  during policy transfer, but has the potential to reduce it  significantly.  


The code for the tool is available at GitHub. Please use the following link.