A majority of organizations implementing Oracle Identity Manager (OIM) struggle with migration and deployment procedures. Migrating a newly developed connector often involves many manual steps, and can result in problems such as a missed deployment steps, importing wrong versions, etc. One solution to those problems is automation, where everything is stored and controlled in a code repository – not just the binaries, but also the configuration files to import, and any setup scripts. In this blog post we will look at the different options available to fully automate a deployment and how to maintain configurations and customizations in a central repository.
Oracle Identity Manager includes a set of tools that allow for the import and export of configurations made in one environment to another. OIM Administrators can use the System Administration interface to achieve this by keeping an inventory of the connectors and the corresponding artifacts such as approvals policies, access policies, lookups, etc. In addition to the deployment manager being available in the web user interface, the deployment manager can also be invoked programmatically to both export configuration from a source environment, and import that configuration into another environment. An organization can write sets of tools to both generate configuration exports (ensuring that no artifacts are missed in the export), and also a set of tools to automate the import of those configuration files. Building custom tools like this allow for a programmatic, repeatable deployment process. An additional benefit of these automated tools is that administrators who are not as familiar with OIM, such as an operations team, can perform deployments.
Readers familiar with OIM’s deployment manager probably know that not everything can be managed using that tool. For example, the deployment manager cannot set parameters within an IT resource, or add members to an OIM role, such as an approver role. However, OIM does make a rich Java API available, which can be used to implement custom tools to handle the import and export of this data.
One way to orchestrate the overall process of exporting and importing the deployment of OIM connectors, corresponding artifacts and OIM configurations is to leverage ANT (http://ant.apache.org). ANT is typically used to manage build process for Java code, however ANT can be easily extended to execute custom tasks, such as ones that call OIM API’s to import a configuration file. An ANT build file will orchestrate the whole process, for example importing a configuration file, then setting up IT resource settings, and possibly running a scheduled task to bring in some initial configuration data. This build file can effectively replace a manual deployment guide with many steps with a single file to run.
Another benefit of an automated approach such as this is that the entire solution can be stored within a code repository such as Subversion or Git. This includes the source code for the connectors and other customizations, the source code for the deployment tools, the configurations files to implement, and the ANT build files used to control the deployment process. This configuration can be treated just like any software development project, and processes such as code review, searching for differences, and migration can be done. Ultimately, a full Software Development Lifecycle (SDLC) process can be implemented around the management of an OIM implementation. Because this deployment process is automated, many if not all of the problems with manually-performed deployments are eliminated.
An automated deployment approach also gives an organization the tools required to make sure their environments are the same. The benefits can be found in small organizations with a lower level and production environments because of the speed of the deployments, to large organizations with multiple lower environments, testing environments and parallel production environments for high availability. Additionally, items deployed via an automated process can easily be replicated to a new environment by simply running the same deployment process. Organizations that have fully automated the deployment process can very easily create a brand new OIM environment.
If you are an organization running into these requirements and the thought of automating these process maybe daunting, work with your implementations partner and ask for any help in implementing such tools. This will allow your staff to spend less time deploying connectors and configurations and reduce the risk of errors that are sometimes found in manual importing and exporting of connectors and configurations. Some implementation partners may have already built such tools, and be able to offer them to you to help jumpstart your efforts. For example, we at Identity Works LLC (http://www.identityworksllc.com) have developed deployment tools that can be used for such implementations.