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.
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.
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.
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.
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.
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
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.