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