Organizations in verticals such as Higher Education have requirements around multi-affiliation and multi-valued identity data. In this blog post we will look at how you can configure identity data in Oracle Identity Manager to meet the needs of Higher Education (or any organization with multi-affiliation and multi-valued identity data) without the need to make data structure changes to the product, while maintaining configurations in a central repository. 

As an example, Higher Education organizations, for the most part, have multiple authoritative sources of identity data (Faculty, Students, Staff, Contractors, etc) that may include individuals having multiple affiliations (similar identity data in more than one system) and multiple values of an attribute sourced from the different authoritative systems (a good example of a multi-valued attributes are Roles sourced from multiple systems). 

There are three important pieces to this that require leveraging the OIM Java API and extensibility of User (Identity) and Role objects in OIM along with an automated deployment process. First, the development of pre and post-process handlers is used to include the logic required to populate the multivalued attribute into a single field in the User object. Second is the extension of the Role object in OIM to hold a custom rule field and a corresponding handler (the rule engine) that uses this field to evaluate substrings of the multi-valued field. And last, leveraging the automated deployment approach (mentioned in the Automated OIM Configuration Deployments post) to maintain all configurations such as User Defined Fields, Roles and Access Policies in a central source code repository and to make the deployment consistent since the storing of multi-valued data in the user table in a delimited format often requires a number of user fields to be added and maintained. All this work effort can be made manageable using an automated deployment process. 

OIM provides a great method to inject implementation specific business rules and processes (the operations) at various points in the identity lifecycle (the orchestration) by leveraging Event Handlers. During the Pre-Process stage the identity data is received by OIM through some reconciliation process. A pre-process handler can be developed that evaluates the newly received data and processes any multi-valued field into an expected format. Also, during this process, if the orchestration event is related to a modification of a current identity, this handler can compare the current data with the newly received data. 

The Role object in OIM is extensible, therefore a defined field can be created that can hold a Membership Rule. This Membership Rule can be nothing more than a SQL Where clause that searches for a particular substring on a User defined field in the identity record. During the Post-Process stage, the identity data has been processed and the identity record populated with multi-valued data in a single field with a predefined separator. A Post-process Event Handler should include the logic required to evaluate the identity record, leverage the previously defined membership rule (the SQL Where clause), evaluate the multi-valued field for substrings (as stated in the where clause) and add a user (the identity) to the OIM Role that was evaluated. An Access Policy attached to the OIM Role will be executed and the identity provisioned to the systems and entitlements the policy defines. 

As mentioned in the previous blog post (Automated OIM Configuration Deployments), some organizations require the deployment of OIM configurations to be automated. The configurations being mentioned in this post may also be included in an automated deployment. Event handlers can be deployed by leveraging OIM Java APIs and creating custom processes for deployment of any event handler. Event handler deployments have common configurations and this can be automated by setting annotations in the classes developed for the event handlers. Those annotations can be used by an ANT (http://ant.apache.org) task to package the Event handlers and deploy them to the correct location where OIM expects. OIM Roles, their corresponding defined fields (used to create a SQL Where clause rule) and corresponding access policies can read from a flat file configuration during a deployment. These can be deployed to OIM using an ANT script that leverages the OIM API and creates all artifacts based on the flat file configuration. The approach of storing the multi-valued data in the Identity record in a delimited format often requires a number of user fields to be added and maintained. These User Defined Fields for the Identity record can also be stored in a flat file configuration. In essence, all of these configurations can be stored in a source code repository and the deployment work effort can be made manageable using the automated deployment process.