Import users
As part of the application on-boarding process, we should import existing users from the target application. This is needed to enable:
- Creating an accurate view of a user's current access
- Support access certification and other requirements related to access review
Users and their current entitlement memberships can be imported in several ways. For applications where a connector exists or can be developed, we can use the connectors. For others, we can use the a CSV file.
The section below describes how to import existing users using a connector. T
Applications with connectors
To import users using a connector, you need to follow the steps listed below:
- Ensure that you have established a connection to your application as in the Connection details
- Configure a synchronization task as described below to import the entitlements
Configure synchronization process
If a sample synchronization configuration already exists, then leverage that configuration; especially if you are new to OpenIAM. Alternatively, use the steps described below to create your own configuration.
The configuration here is based on OpenLDAP. Check the connector documentation for details about configuring these processes for your specific application.
From the Webconsole:
- Go to
Provisioning->Synchronization - Go to
Create Synchronizationfrom the side menu
Complete the form as described below. Replace the Ldap specific details with the details needed for your application
| Field name | Description | Example Value |
|---|---|---|
| Name | Descriptive value to identify this configuration. | OpenLDAP Synch for Users |
| Number of Threads | Set this value to 1, which is the default. This controls how many threads will be created to process data coming from the connector or CSV file. This is a performance optimization for processing large datasets. However, creating too many threads can take away resources from other operations and thereby have a negative impact. | 1 |
| Is active? | Flag which determines if the synchronization configuration can be executed. Making a configuration In-active is a way to disable the task. | True |
| Detect orphan | Orphan management is used to detect records in a target system which are not in the source. Since we are importing users, and source system has not been loaded, there are no orphans to detect | False |
| Provision to target systems | This flag enables down stream provisioning to target system. Once you have configured your synchronization and managed systems, you MUST enable this checkbox to allow for downstream provisioning. Since we are importing users, there is nothing provision. | False |
| Synchronization source | This is the source of your data. In this case, if we are using LDAP, then our source should be the connector. | Connector (since 4.2.1.2) |
| Managed System | Name of the managed system configuration which will be used by the connector | Test - OpenLDAP |
| Synchronization object | Defines the type of object that will be imported. In this case, its Users that we are importing. | User |
| Synch type | Allows you to define if this should be an incremental or complete synch. Since we are loading data, it should be a complete synch. | Complete |
| Synch Frequency | Describes how often the synchronization process should run. If you are in an implementation mode, then you can leave this feel blank. In production, if there is a need to actively synch from the selected application, then you can define a cron expression to control the frequency: Example, if you want it to running automatically. The frequency is expressed as a CRON expression. | |
| Example Cron expressions: Every day at 23:00 | 0 0 23 * * | |
| Example Cron expressions: Every 1 hour: | 0 * * * * | |
| Example Cron expressions: Every 15 minutes: | /15 * * * | |
| Pre-processor script | Pre-processor script runs before synchronization starts. | Leave blank |
| Post-processor script | Post-processor script runs after synchronization has been completed. | Leave blank |
| Validation Rule | Groovy script to validate the incoming data from the file. | /sync/user/ldap/Ldapvalidation.groovy -- Example script |
| Transformation Implementation | This can be either based on a policy map or a transformation scripts (aka. Groovy script). | Select Transformation Scripts |
| Transformation rule | Select the Groovy script which will be responsible for mapping data from your source (ldap) to objects which OpenIAM understands. A bulk of the work that is performed during synchronization originates in this script. | /sync/user/ldap/LdapUserTransformation.groovy -- Example script |
| OpenIAM Field Name | Field which uniquely identifies a user in OpenIAM. Select from one of the following: PRINCIPAL NAME, EMPLOYEE ID, IDM USER ID (internal guid), PRIMARY EMAIL ADDRESS If these do not apply, then select CUSTOM ATTRIBUTE and enter the attribute name. | PRINCIPAL NAME |
| Source Attribute Name | Attribute name form your source (LDAP) which uniquely identifies a user. OpenIAM will try to link users from the source with the value in OpenIAM using the source attribute name and the OpenIAM field name. | uid |
| Custom Rule for Matching | In cases where its not possible to match on a single field, you can create a Custom match rule, using Groovy script, which will allow for more complex matching algorithms. | Leave blank |
| Attribute names lookup | When getting data from Connectors, the Attribute name lookup is a simple script which define the list of attributes from the source system which should be made available to the Transformation script. For example, if you are working with LDAP, you will only be able to map attributes in the transformation script which have first been defined in the Attribute names lookup script. | /sync/user/ldap/LdapUserSynchAttributes.groovy -- Example script |
After synchronizing users, you should be able to find the newly created users in the webconsole. You can also find details about the synchronization process in the Log viewer at (Webconsole -> Administration -> Log Viewer )
