This chapter contains the following topics:
Note:
These sections provide both conceptual and procedural information about configuring the connector. It is recommended that you read the conceptual information before you perform the procedures.
For Oracle Identity Manager hosted on a Microsoft Windows computer, if you have a previously installed connector, then you must extract the connector bundle zip file again before installing a new connector.
Note:
It is recommended that you perform the procedure described in this section to secure communication between the target system and Oracle Identity Manager.
Perform the following steps to configure secure communication between MySQL and Oracle Identity Manager:
This section discusses the JDBC URL and Connection Properties parameters. You apply the information in this section while performing the procedure described in Configuring the IT Resource for the Target System.
The following are guidelines on specifying the JDBC URL and Connection Properties parameters:
JDBC URL parameter
Enter the following component of the connection URL as the value of the JDBC URL provider:
jdbc:mysql://[SERVER_NAME][:PORT_NUMBER]/[DATABASE_NAME]
In this format:
SERVER_NAME is the IP address (not the host name) of the target system host computer.
PORT_NUMBER is the port at which the target system database is listening.
DATABASE_NAME is the name of the database we are connecting.
The following is a sample value for the Database URL parameter:
jdbc:mysql://192.168.16.76:3306/information_schema
Connection Properties parameter
Enter the following component of the connection URL as the value of the Connection Properties parameter:
[,PROPERTY=VALUE[,PROPERTY=VALUE]] . . .
In this format:
PROPERTY is the name of one or more database connection properties, such as applicationName and disableStatementPooling.
VALUE is the value of each database connection property whose name you specify by using the PROPERTY placeholder.
Note:
Semicolons must be changed to number signs (#) in the value that you specify.
The following is a sample value for the Connection Properties parameter:
databaseName=information_schema#port=3306
If you enable SSL communication between MySQL and Oracle Identity Manager, then:
Append the following value to the value in the Connection Properties parameter of the IT resource:
useSSL=true#requireSSL=true
For example, suppose the following is the existing value for the Connection Properties parameter:
databaseName=information_schema#port=3306
Now, if you enable SSL communication between MySQL and Oracle Identity Manager, then the value of the Connection Properties parameter must be as follows:
databaseName=information_schema#port=3306#useSSL=true#requireSSL=true
This section contains the following information:
During a provisioning operation, you use a lookup field on the process form to specify a single value from a set of values. For example, you use the Privileges lookup field to select a privilege to be assigned to a schema from the list of available privileges. When you deploy the connector, lookup definitions corresponding to the lookup fields on the target system are created in Oracle Identity Manager. Lookup field synchronization involves copying additions or changes made to the target system lookup fields into the lookup definitions in Oracle Identity Manager.
The connector provides predefined SQL queries for fetching values from the target system lookup fields into the lookup definitions in Oracle Identity Manager. These predefined SQL queries are stored in the LoVSearch.queries file with in the connector bundle.
After lookup definition synchronization, data is stored in the following format:
Code Key value: IT_RESOURCE_KEY~LOOKUP_FIELD_ID
In this format:
IT_RESOURCE_KEY is the numeric code assigned to each IT resource in Oracle Identity Manager.
LOOKUP_FIELD_ID is the target system code assigned to each lookup field entry.
Sample value: 1~SYS_ADM
Decode value: IT_RESOURCE_NAME~LOOKUP_FIELD_ID
In this format:
IT_RESOURCE_NAME is the name of the IT resource in Oracle Identity Manager.
LOOKUP_FIELD_ID is the target system code assigned to each lookup field entry.
Sample value: MySQL DB~SYS_ADM
While performing a provisioning operation in Oracle Identity Self Service, you select the IT resource for the target system on which you want to perform the operation. When you perform this action, the lookup definitions on the page are automatically populated with values corresponding to the IT resource (target system installation) that you select. If your environment has multiple installations of the target system, then values corresponding to all IT resources are displayed.
using-and-extending-connector-mysql.htm#GUID-8D2F4DE7-1CBF-4BE3-8F59-8DD1A2F984DF__CHDDDBFE lists column name of the table in MySQL that is synchronized with its corresponding lookup definition in Oracle Identity Manager.
Table 5-2 Lookup Definitions Synchronized with MySQL
| Lookup Definition | Target Column Name |
|---|---|
|
Lookup.DBUM.MySQL.SchemaPrivileges |
Privilege |
This section describes the configuration lookup definitions that are created in Oracle Identity Manager when you deploy the connector. These lookup definitions are either prepopulated with values or values must be manually entered in them after the connector is deployed.
This section provides information about the following lookup definitions
The Lookup.DBUM.MySQL.Configuration lookup definition holds connector configuration entries that are used during target resource reconciliation and provisioning operations.
Table 5-3 Entries in Lookup.DBUM.MySQL.Configuration
| Code Key | Decode Key | Description |
|---|---|---|
|
Bundle Name |
|
Name of the connector bundle package Do not modify this entry. |
|
Bundle Version |
1.0.1116 |
Version of the connector bundle class Do not modify this entry. |
|
Connector Name |
|
Name of the connector class Do not modify this entry. |
|
User Configuration Lookup |
Lookup.DBUM.MySQL.UM.Configuration |
Name of the lookup definition that contains user-specific configuration properties Do not modify this entry. |
The Lookup.DBUM.MySQL.UM.Configuration lookup definition holds user-specific connector configuration entries that are used during target resource reconciliation and provisioning operations.
Table 5-4 Entries in Lookup.DBUM.MySQL.UM.Configuration
| Code Key | Decode Key |
|---|---|
|
Provisioning Attribute Map |
Lookup.DBUM.MySQL.UM.ProvAttrMap |
|
Provisioning Exclusion List |
Lookup.DBUM.MySQL.UM.ExclusionList |
|
Provisioning Validation Lookup |
Lookup.DBUM.MySQL.UM.ProvValidations |
|
Recon Validation Lookup |
Lookup.DBUM.MySQL.UM.ReconValidations |
|
Recon Attribute Map |
Lookup.DBUM.MySQL.UM.ReconAttrMap |
|
Recon Exclusion List |
Lookup.DBUM.MySQL.UM.ExclusionList |
|
Recon Transformation Lookup |
Lookup.DBUM.MySQL.UM.ReconTransformations |
The Lookup.DBUM.MySQL.Configuration.Trusted lookup definition holds connector configuration entries that are used during reconciliation and provisioning operations in trusted source mode.
Table 5-5 Entries in Lookup.DBUM.MySQL.Configuration.Trusted
| Code Key | Decode Key |
|---|---|
|
Bundle Name |
|
|
Bundle Version |
1.0.1116 |
|
Connector Name |
|
|
User Configuration Lookup |
Lookup.DBUM.MySQL.UM.Configuration.Trusted |
The Lookup.DBUM.MySQL.UM.Configuration.Trusted lookup definition holds user-specific connector configuration entries that are used during reconciliation and provisioning operations in trusted source mode.
Table 5-6 Entries in Lookup.DBUM.MySQL.UM.Configuration.Trusted
| Code Key | Decode Key |
|---|---|
|
Recon Attribute Defaults |
Lookup.DBUM.MySQL.UM.ReconDefaults.Trusted |
|
Recon Attribute Map |
Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted |
|
Recon Validation Lookup |
Lookup.DBUM.MySQL.UM.ReconValidations.Trusted |
|
Recon Exclusion List |
Lookup.DBUM.MySQL.UM.ExclusionList.Trusted |
|
Recon Transformation Lookup |
Lookup.DBUM.MySQL.UM.ReconTransformations.Trusted |
This section describes the following lookup definitions:
The Lookup.DBUM.MySQL.UM.ProvAttrMap lookup definition holds user-specific mappings between process form fields (Code Key values) and target system attributes (Decode values) used during provisioning operations.
Table 5-7 Entries in Lookup.DBUM.MySQL.UM.ProvAttrMap
| Code Key | Decode Key |
|---|---|
|
Return Id |
__UID__ |
|
UD_DB_MYS_P~Privilege[LOOKUP] |
privileges~DBPrivilege~__NAME__ |
|
User Name |
__NAME__ |
|
User Password |
__PASSWORD__ |
The Lookup.DBUM.MySQL.UM.ReconAttrMap lookup definition holds user-specific mappings between reconciliation attribute names as specified in the resource object (Code Key values) and target system attributes (Decode values) used during reconciliation operations.
Table 5-8 Entries in Lookup.DBUM.MySQL.UM.ReconAttrMap
| Code Key | Decode Key |
|---|---|
|
Privilege List~Privilege Name[LOOKUP] |
privileges~DBPrivilege~__NAME__ |
|
Return ID |
__UID__ |
|
User Name |
__UID__ |
The Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted lookup definition holds user-specific mappings between reconciliation attribute names as specified in the resource object (Code Key values) and target system attributes (Decode values) used during reconciliation operations in trusted source mode.
Table 5-9 Entries in Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted
| Code Key | Decode Key |
|---|---|
|
First Name |
__NAME__ |
|
User ID |
__UID__ |
This lookup definition contains the default values for the Oracle Identity Manager user attributes. You can change these values as per your requirements.
For example, if you want the users reconciled from a trusted source to be part of the MyORG organization, then map the lookup definition entry as follows:
Code Key = Organization Name
Decode = MyORG (instead of Xellerate Users)
Table 5-10 Entries in Lookup.DBUM.MySQL.UM.ReconDefaults.Trusted
| Code Key | Decode Key |
|---|---|
|
Empl Type |
Full-Time |
|
Organization Name |
Xellerate Users |
|
Status |
Active |
|
User Type |
End-User |
This section describes the lookup definitions that hold resources for which you do not want to perform provisioning and reconciliation operations. Exclusions can be applied to any attribute in the process form or reconciliation profile. The Code Key value must be one of the Code Key values in Lookup.DBUM.MySQL.UM.ReconAttrMap or Lookup.DBUM.MySQL.UM.ProvAttrMap lookup definitions.
Depending on how the target system is configured, you can use one of the following lookups:
For target resource mode: Lookup.DBUM.MySQL.UM.ExclusionList
By default, this lookup definition has the following entry:
| Code Key | Decode |
|---|---|
|
User Name |
root |
For trusted source mode: Lookup.DBUM.MySQL.UM.ExclusionList.Trusted
By default, this lookup definition has the following entry:
| Code Key | Decode |
|---|---|
|
User ID |
root |
The following is the format of the values stored in these lookups:
| Code Key | Decode | Sample Values |
|---|---|---|
|
User Name |
User ID of a user |
Code Key: User Name Decode: User001 |
|
User Name with the [PATTERN] suffix |
A regular expression supported by the representation in the |
Code Key: User Name[PATTERN] To exclude users matching any of the user ID 's User001, User002, User088, then: Decode: User001|User002|User088 To exclude users whose user ID 's start with 00012, then: Decode: 00012* See Also: For information about the supported patterns, visit |
Configuring Resource Exclusion Lists for MySQL describes the procedure to add entries in these lookup definitions.
This section describes the lookup definitions that hold resources for which you want to enable transformation of data during reconciliation operations.
Depending on how the target system is configured, use one of the following lookup definitions:
For target resource mode: Lookup.DBUM.MySQL.UM.ReconTransformations
For trusted source mode: Lookup.DBUM.MySQL.UM.ReconTransformations.Trusted
Configuring Transformation of Data During User Reconciliation for MySQL describes the procedure to add entries in these lookup definitions.
You can use the Lookup.DBUM.MySQL.UM.ProvValidations lookup to configure validation of data during provisioning operations.
Configuring Validation of Data During Reconciliation and Provisioning for MySQL describes the procedure to add entries in this lookup definition.
When you run the Connector Installer or import the connector XML file, the scheduled jobs are automatically created in Oracle Identity Manager.
This section describes the following topics:
Lookup field synchronization involves copying additions or changes made to the target system lookup fields into the lookup definitions in Oracle Identity Manager.
The DBUM MySQL Privilege Type Lookup Reconciliation scheduled job is used for lookup field synchronization.
You must specify values for the attributes of this scheduled job. using-and-extending-connector-mysql.htm#GUID-334BDE33-5F87-4257-B416-15B6E704DF66__CIHFGJDE describes the attributes of this scheduled job. The procedure to configure scheduled job is described later in the guide.
Table 5-11 Attributes of the Scheduled Job for Lookup Field Synchronization
| Attribute | Description |
|---|---|
|
Code Key Attribute |
Enter the name of the connector or target system attribute that is used to populate the Code Key column of the lookup definition (specified as the value of the Lookup Name attribute). Sample value: Note: Do not change the value of this attribute. |
|
Decode Attribute |
Enter the name of the connector or target system attribute that is used to populate the Decode column of the lookup definition (specified as the value of the Lookup Name attribute). Sample value: |
|
IT Resource Name |
Enter the name of the IT resource for the target system installation from which you want to reconcile user records. Default value: |
|
Lookup Name |
This attribute holds the name of the lookup definition that maps each lookup definition with the data source from which values must be fetched. Default value: |
|
Object Type |
Enter the type of object whose values must be synchronized. Default value: __PRIVILEGES__ Note: Do not change the value of this attribute. |
|
Resource Object Name |
Enter the name of the resource object that is used for reconciliation. Default value: |
The following scheduled jobs are used to reconcile user data in the target resource (account management) mode of the connector:
DBUM MySQL User Target Reconciliation
DBUM MySQL Delete User Target Reconciliation
The following scheduled jobs are used to reconcile user data in the trusted source (identity management) mode of the connector:
DBUM MySQL User Trusted Reconciliation
DBUM MySQL Delete User Trusted Reconciliation
using-and-extending-connector-mysql.htm#GUID-2C65E1A3-9537-43D0-8260-2C956D7E06CF__CIHBDGFE describes the attributes of the scheduled jobs for user operations.
Table 5-12 Attributes of the Scheduled Jobs for Reconciliation
| Attribute | Description |
|---|---|
|
Batch Size |
Value for running the scheduled job in batch mode. By default, this value is empty. |
|
Filter |
Expression for filtering records that must be reconciled by the scheduled job By default, the value of this attribute is empty. Sample value: See Performing Limited Reconciliation from MySQL for the syntax of this expression. |
|
IT Resource Name |
Name of the IT resource for the target system installation from which you want to reconcile user records For DBUM MySQL User Target Reconciliation: For DBUM MySQL User Trusted Reconciliation, enter the name of the IT resource created for trusted source mode. |
|
Object Type |
Type of object you want to reconcile Default value: |
|
Resource Object Name |
Name of the resource object that is used for reconciliation For DBUM MySQL User Target Reconciliation: For DBUM MySQL User Trusted Reconciliation: |
|
Scheduled Task Name |
Name of the scheduled job Note: For the scheduled job included with this connector, you must not change the value of this attribute. However, if you create a copy of the task, then you can enter the unique name for that scheduled job as the value of this attribute. |
using-and-extending-connector-mysql.htm#GUID-2C65E1A3-9537-43D0-8260-2C956D7E06CF__CIHFFEDB describes the attributes of the scheduled jobs for delete operations.
Table 5-13 Attributes of the Scheduled Jobs for Delete Operations
| Attribute | Description |
|---|---|
|
IT Resource Name |
Name of the IT resource for the target system installation from which you want to reconcile user records For DBUM MySQL Delete User Target Reconciliation: For DBUM MySQL Delete User Trusted Reconciliation, enter the name of the IT resource created for trusted source mode. |
|
Object Type |
Type of object you want to reconcile Default value: |
|
Resource Object Name |
Name of the resource object that is used for reconciliation For DBUM MySQL Delete User Target Reconciliation: For DBUM MySQL Delete User Trusted Reconciliation: |
You can apply this procedure to configure the scheduled jobs for lookup fields synchronization and reconciliation.
See Scheduled Job for Lookup Field Synchronization for MySQL and Attributes for Scheduled Jobs for MySQL for the scheduled jobs that are part of the connector and for information about their attributes.
To configure a scheduled job:
For Oracle Identity Manager release 11.1.1.x:
Log in to the Administrative and User Console.
On the Welcome to Oracle Identity Manager Self Service page, click Advanced in the upper-right corner of the page.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the System Management region, click Search Scheduled Jobs.
If you are using Oracle Identity Manager release 11.1.2.x or later:
Log in to Oracle Identity System Administration.
In the left pane, under System Management, click Scheduler.
Search for and open the scheduled job as follows:
On the left pane, in the Search field, enter the name of the scheduled job as the search criterion. Alternatively, you can click Advanced Search and specify the search criterion.
In the search results table on the left pane, click the scheduled job in the Job Name column.
On the Job Details tab, you can modify the following parameters:
Retries: Enter an integer value in this field. This number represents the number of times the scheduler tries to start the job before assigning the Stopped status to the job.
Schedule Type: Depending on the frequency at which you want the job to run, select the appropriate schedule type.
Note:
See Creating Jobs in Oracle Fusion Middleware Administering Oracle Identity Manager for detailed information about schedule types.
In addition to modifying the job details, you can enable or disable a job.
On the Job Details tab, in the Parameters region, specify values for the attributes of the scheduled job.
Note:
Attribute values are predefined in the connector XML file that you import. Specify values only for those attributes that you want to change.
Attributes of the scheduled job are discussed in Attributes for Scheduled Jobs for MySQL.
After specifying the attributes, click Apply to save the changes.
As mentioned earlier in this guide, reconciliation involves duplicating in Oracle Identity Manager the creation of and modifications to user accounts on the target system. This section discusses the following topics related to configuring reconciliation:
The following are guidelines that you must apply while configuring reconciliation:
Before a target resource reconciliation run is performed, lookup definitions must be synchronized with the lookup fields of the target system. In other words, the scheduled job for lookup field synchronization must be run before user reconciliation runs.
After you configure batched reconciliation, if reconciliation fails during a batched reconciliation run, then rerun the scheduled job without changing the values of the task attributes.
This connector can be configured to perform either trusted source reconciliation or target resource reconciliation.
When you configure the target system as a target resource, the connector enables you to create and manage database accounts for OIM Users through provisioning. In addition, data related to newly created and modified target system accounts can be reconciled and linked with existing OIM Users and provisioned resources.
When you configure the target system as a trusted source, the connector fetches into Oracle Identity Manager, data about newly created target system accounts. This data is used to create OIM Users. See Configuring the Target System As a Trusted Source for more information.
See Also:
Reconciliation Based on the Object Being Reconciled in Oracle Fusion Middleware Administering Oracle Identity Manager for conceptual information about target resource reconciliation and trusted source reconciliation.
The following is an overview of the steps involved in reconciliation:
A SQL query or stored procedure is used to fetch target system records during reconciliation.
The scheduled job communicates to connector bundle and runs search operations over it, maps the task attributes to parameters of the reconciliation query or stored procedure, and then runs the query or stored procedure on the target system.
Target system records that meet the query or stored procedure criteria are fetched into Oracle Identity Manager.
If you have configured your target system as a trusted source, then each user record fetched from the target system is compared with existing OIM Users. The reconciliation rule is applied during the comparison process.
The next step of the process depends on the outcome of the matching operation:
If a match is found between the target system record and the OIM User, then the OIM User attributes are updated with changes made to the target system record.
If no match is found, then the target system record is used to create an OIM User.
If you have configured your target system as a target resource, then each user record fetched from the target system is compared with existing target system resources assigned to OIM Users. The reconciliation rule is applied during the comparison process.
The next step of the process depends on the outcome of the matching operation:
If a match is found between the target system record and a resource provisioned to an OIM User, then the database user resource is updated with changes made to the target system record.
If no match is found, then the target system user record is compared with existing OIM Users. The next step depends on the outcome of the matching operation:
If a match is found, then the target system record is used to provision a resource for the OIM User.
If no match is found, then the status of the reconciliation event is set to No Match Found.
Note:
Reconciliation Rules for MySQL for information about the reconciliation rule
As mentioned earlier in this guide, this connector can be configured to perform either target resource reconciliation or trusted source reconciliation. This section discusses the following topics:
The Lookup.DBUM.MySQL.UM.ReconAttrMap lookup definition holds attribute mappings for user reconciliation. This lookup definition contains mapping of Oracle Identity Manager attributes and connector attributes.
See Lookup.DBUM.MySQL.UM.ReconAttrMap for more information.
The Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted lookup definition holds attribute mappings for reconciliation in trusted mode. This lookup definition maps reconciliation profile attributes and connector attributes used in the reconciliation query. In addition, the connector attributes are associated to columns within the bundle.
See Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted for more information about this lookup definition.
Note:
Skip this section if you do not want to designate the target system as a trusted source for reconciliation.
To configure trusted source reconciliation:
If you are using Oracle Identity Manager release 11.1.1.x:
Log in to the Administrative and User Console.
On the Welcome page, click Advanced in the upper-right corner of the page.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the Configuration region, click Create IT Resource.
If you are using Oracle Identity Manager release 11.1.2.x or later:s
Log in to Oracle Identity System Administration.
In the left pane, under Configuration, click IT Resource.
In the Manage IT Resource page, click Create IT Resource.
On the Step 1: Provide IT Resource Information page, enter the following information:
IT Resource Name: Enter a name for the IT resource. For example, MySQL DB Trusted.
IT Resource Type: Select the MySQL DB IT resource type for the IT resource.
Click Continue.
On the Step 2: Specify IT Resource Parameter Values page, specify values for the parameters of the IT resource.
Configuration Lookup: Name of the lookup definition in which you store the connector configuration information for the target system.
Sample Value: Lookup.DBUM.MySQL.Configuration.Trusted
Provide values for the other IT resource parameters.
Click Continue.
In the following steps, provide permissions on the IT resource that you are creating as per your requirements.
You can use this IT resource for trusted source reconciliation operations.
See Also:
Reconciliation Metadata in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for generic information about reconciliation rules and reconciliation action rules
This section describes the reconciliation rules used by the reconciliation engine for this connector.
The following are the reconciliation rules for target resource reconciliation:
Rule name: DBUM MySQL Target Recon
Rule element: User Login Equals User Name
The following are the reconciliation rules for trusted source reconciliation:
Rule name: MySQL DB Trusted
Rule element: User Login Equal User ID
In these rule elements:
User Login is the field on the OIM User form.
User Name and User ID are the target system fields.
After you deploy the connector, you can view the reconciliation rule for reconciliation by performing the following steps:
Note:
Perform the following procedure only after the connector is deployed.
Reconciliation action rules define that actions the connector must perform based on the reconciliation rules defined for Users.
using-and-extending-connector-mysql.htm#GUID-E378B228-3CD6-4810-B5D8-E945B2B386B7__CHDCEIBF lists the action rules for target resource reconciliation.
Table 5-14 Action Rules for Target Resource Reconciliation
| Rule Condition | Action |
|---|---|
|
No Matches Found |
Assign to Administrator With Least Load |
|
One Entity Match Found |
Establish Link |
|
One Process Match Found |
Establish Link |
using-and-extending-connector-mysql.htm#GUID-E378B228-3CD6-4810-B5D8-E945B2B386B7__CHDCBFFC lists the action rules for trusted source reconciliation.
Table 5-15 Action Rules for Trusted Source Reconciliation
| Rule Condition | Action |
|---|---|
|
No Matches Found |
Create User |
|
One Entity Match Found |
Establish Link |
After you deploy the connector, you can view the reconciliation action rules for target resource reconciliation by performing the following steps:
Full reconciliation involves reconciling all existing user records from the target system into Oracle Identity Manager. After you deploy the connector, you must first perform full reconciliation.
To perform a full reconciliation run, remove (delete) any value currently assigned to the Filter attribute and run one of the following scheduled jobs:
For MySQL as a target resource: DBUM MySQL User Target Reconciliation
For MySQL as a trusted source: DBUM MySQL User Trusted Reconciliation
See Attributes for Scheduled Jobs for MySQL for information about this scheduled job.
By default, all target system records that are added or modified after the last reconciliation run are reconciled during the current reconciliation run. You can customize this process by specifying the subset of added or modified target system records that must be reconciled. You do this by creating filters for the reconciliation module.
You can perform limited reconciliation by creating filters for the reconciliation module. This connector provides a Filter attribute (a scheduled task attribute) that allows you to use any of the DBUM resource attributes to filter the target system records. You can apply filters to the parent parameters in the reconciliation query file stored in a JAR file in the bundle directory of the connector installation media. For example, to locate the reconciliation query file, you can extract the bundle/org.identityconnectors.dbum-1.0.1116.jar file and open scripts/mysql/Search.queries.
The following table provides the description of the parent parameter that can be used with the Filter attribute of the scheduled jobs:
| Parameter | Description |
|---|---|
|
__UID__ |
Unique identity representing the user This parameter is mapped to USERNAME or __NAME__ connector attribute. |
For detailed information about ICF Filters, see ICF Filter Syntax in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.
While deploying the connector, follow the instructions in Configuring Scheduled Jobs for MySQL to specify attribute values.
During a reconciliation run, all changes in the target system records are reconciled into Oracle Identity Manager. Depending on the number of records to be reconciled, this process may require a large amount of time. In addition, if the connection breaks during reconciliation, then the process would take longer to complete.
You can configure batched reconciliation to avoid these problems.
To configure batched reconciliation, you must specify value for the Batch Size reconciliation scheduled job attribute. Use this attribute to specify the number of records that must be included in each batch. By default, this value is empty.
If you specify a value other than All, then some of the newly added or modified user records may not get reconciled during the current reconciliation run. The following example illustrates this:
Suppose you specify the Batch Size value as 200 while configuring the scheduled jobs. Suppose that 314 user records were created or modified after the last reconciliation run. Of these 314 records, only 200 records would be reconciled during the current reconciliation run. The remaining 114 records would be reconciled during the next reconciliation run.
You specify values for the Batch Size attribute by following the instructions described in Configuring Scheduled Jobs for MySQL.
Provisioning involves creating or modifying user account on the target system through Oracle Identity Manager.
This section contains the following topics about provisioning:
The following are guidelines that you must apply while performing provisioning operations:
Before you perform provisioning operations, lookup definitions must be synchronized with the lookup fields of the target system. In other words, run the scheduled jobs for lookup field synchronization before provisioning operations.
Passwords for user accounts provisioned from Oracle Identity Manager must adhere to the password policy set in the target system.
The character length of target system fields must be taken into account when specifying values for the corresponding Oracle Identity Manager fields.
During an update password provisioning operation, ensure that you clear the existing text in the Password field, and then enter the new password.
Provisioning involves creating and managing user accounts. When you allocate (or provision) a database resource to an OIM User, the operation results in the creation of an account on the target database for that user. Similarly, when you update the resource on Oracle Identity Manager, the same update is made to the account on the target system.
When you install the connector on Oracle Identity Manager, the direct provisioning feature is automatically enabled. This means that the process form is enabled when you install the connector.
This following are types of provisioning operations:
Direct provisioning
Request-based provisioning
Provisioning triggered by policy changes
If you configure the connector for request-based provisioning, then the process form is suppressed and the object form is displayed. In other words, direct provisioning is disabled when you configure the connector for request-based provisioning. If you want to revert to direct provisioning, then see Switching Between Request-Based Provisioning and Direct Provisioning for MySQL.
The following is an overview of the Create User provisioning process in MySQL that is started through direct provisioning:
On the Create User page of the Administrative and User Console, the administrator enters the data required for an OIM User account creation.
Suppose the administrator enters the following values for the fields on the Create User page:
First Name: John
Last Name: Doe
User ID: jdoe
An OIM User account is created for John Doe.
The administrator selects the resource to be provisioned to the OIM User account that has been created. In this example, the administrator selects the MySQL DB User resource.
The administrator enters the data required for provisioning the MySQL DB User resource. Suppose the administrator wants to create a local user that requires a password to log in to the database. Therefore, the administrator enters the following values on the resource provisioning process form:
IT Resource: MySQL DB
User Name: JDoe
User Password: my_pa55word
In addition, the administrator also enters the following values on the process form for granting privileges:
Privilege: SELECT ON information_schema
From the information available in the IT resource for the target system, the configuration (Lookup.DBUM.MySQL.Configuration) lookup definition is identified. This lookup definition stores configuration information that is used during connector operations.
The connector bundle contains the script (Provisioning.queries) required for provisioning operations.
The identifiers in the SQL statement are replaced with the input parameters fetched from the query. Then, the SQL statement with actual values is formed.
The connector runs the SQL statement on MySQL and creates the jdoe account on the target system. The next step of the process depends on whether the administrator had entered data for granting privileges to the target system account.
If the administrator did not enter any values for granting privileges, then the provisioning process ends here. Otherwise, the process continues to the next step.
While performing Step 3, the administrator had entered the required data for granting privileges to the jdoe account. Therefore, the corresponding query as mentioned in Step 6 is read.
The complete SQL statement that must be run to perform the Add privilege provisioning operation is formed.
The input parameters required to run the SQL statement are fetched from the parameter configuration done using the queries in the query files.
The identifiers in the SQL statement (formed in Step 9) are replaced with the input parameters fetched from the query. Then, the SQL statement with actual values is formed.
The query runs the SQL statement on the target system (MySQL) and grants privileges to the jdoe target system account.
In direct provisioning, the Oracle Identity Manager administrator uses the Administrative and User Console to create a target system account for a user.
To provision a resource by using the direct provisioning approach:
Log in to the Administrative and User Console.
To first create an OIM User before provisioning a database account to the user:
On the Welcome to Identity Administration page, in the Users region, click Create User.
On the Create User page, enter values for the OIM User fields, and then click the save icon.
To search for an existing OIM User to be provisioned:
On the Welcome to Identity Administration page, search for the user by selecting Users from the Search list on the left pane.
Alternatively, in the Users region, click Advanced Search - User, provide a search criterion, and then click Search.
From the list of users displayed in the search results, select the OIM User.
The user details page is displayed.
From the Action menu, select Add Resource. Alternatively, you can click the add resource icon with the plus (+) sign. The Provision Resource to User page is displayed in a new window.
On the Step 1: Select a Resource page, select the MySQL DB User resource from the list, and then click Continue.
On the Step 2: Verify Resource Selection page, click Continue.
On the Step 5: Provide Process Data page, enter the details of the account that you want to create on the target system and then click Continue.
If you want to provide child data, then on the Step 5: Provide Process Data page for child data, search for and select the child data for the user on the target system and then click Continue. Repeat the same step if you have more than one child data and you want to provision them.
On the Step 6: Verify Process Data page, verify the data that you have provided and then click Continue.
The "Provisioning has been initiated" message is displayed. Perform the following steps:
Close the window displaying the "Provisioning has been initiated" message.
On the Resources tab, click Refresh to view the newly provisioned resource.
If the resource status is Provisioned, then provisioning was successful. If the status is Provisioning, then there may be an error. To verify if there was an error, you can check the resource history.
The following sections discuss the steps to be performed to enable request-based provisioning:
In request-based provisioning, an end user creates a request for a resource by using the Administrative and User Console. Administrators or other users can also create requests for a particular user. Requests for a particular resource on the resource can be viewed and approved by approvers designated in Oracle Identity Manager.
The following are features of request-based provisioning:
A user can be provisioned only one resource (account) on the target system.
Note:
Direct provisioning allows the provisioning of multiple database accounts on the target system.
Direct provisioning cannot be used if you enable request-based provisioning.
The following sections provide information about the procedures you must perform to enable request-based provisioning:
Note:
The procedure described in this section is applicable only if you are using Oracle Identity Manager release 11.1.1.x.
The following are steps performed by the approver in a request-based provisioning operation:
A request dataset is an XML file that specifies the information to be submitted by the requester during a provisioning operation. These request datasets specify information about the default set of attributes for which the requester must submit information during a request-based provisioning operation.
To import a request dataset XML file by using the Deployment Manager:
The following steps are performed by the end user in a request-based provisioning operation:
To enable the Auto Save Form feature:
Run the PurgeCache utility to clear content belonging to the Metadata category from the server cache.
See Clearing Content Related to the Connector Resource Bundles from the Server Cache for instructions.
The procedure to enable enabling request-based provisioning ends with this step.
If you have configured the connector for request-based provisioning, you can always switch to direct provisioning. Similarly, you can always switch back to request-based provisioning any time. This section discusses the following topics:
Note:
It is assumed that you have performed the procedure described in Configuring Request-Based Provisioning for MySQL.
If you want to switch from request-based provisioning to direct provisioning, then:
Log in to the Design Console.
Disable the Auto Save Form feature as follows:
Expand Process Management, and then double-click Process Definition.
Search for and open the MySQL DB process definition.
Deselect the Auto Save Form check box.
Click the save icon.
If the Self Request Allowed feature is enabled, then:
Expand Resource Management, and then double-click Resource Objects.
Search for and open the MySQL DB User resource object.
Deselect the Self Request Allowed check box.
Click the save icon.
If you want to switch from direct provisioning back to request-based provisioning, then:
Log in to the Design Console.
Enable the Auto Save Form feature as follows:
Expand Process Management, and then double-click Process Definition.
Search for and open the MySQL DB process definition.
Select the Auto Save Form check box.
Click the save icon.
If you want to enable end users to raise requests for themselves, then:
Expand Resource Management, and then double-click Resource Objects.
Search for and open the MySQL DB User resource object.
Select the Self Request Allowed check box.
Click the save icon.
To perform provisioning operations in Oracle Identity Manager release 11.1.2.x:
Log in to Identity Self Service.
If you want to first create an OIM User and then provision a target system account, then:
Note:
See Creating Users in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager for more information about creating a user.
In the left pane, under Administration, click Users.
The Search Users page is displayed.
From the Actions menu, select Create. Alternatively, you can click Create on the toolbar.
On the Create User page, enter values for the OIM User fields, and then click Submit. A message is displayed stating that the user is created successfully.
If you want to provision a target system account to an existing OIM User, then:
Note:
See Searching Users in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager for more information about searching a user.
In the left pane, under Administration, click Users.
The Search Users page is displayed.
Specify a search criteria to search for the OIM User, and then click Search.
From the list of users displayed in the search results, select the OIM User. The user details page is displayed on the right pane.
On the Account tab, click Request Accounts.
In the Catalog page, search for and add to cart the application instance (in other words, the account to be provisioned), and then click Checkout.
Specify value for fields in the application form and then click Ready to Submit.
Click Submit.
If you want to provision entitlements, then:
On the Entitlements tab, click Request Entitlements.
In the Catalog page, search for and add to cart the entitlement, and then click Checkout.
Click Submit.
The following sections describe procedures that you can perform to extend the functionality of the connector for addressing your specific business requirements:
Note:
From Oracle Identity Manager Release 11.1.2 onward, lookup queries are not supported. See Managing Lookups in Oracle Fusion Middleware Administering Oracle Identity Manager for information about managing lookups by using the Form Designer in Identity System Administration.
Modifying Predefined Queries or Creating New Queries for MySQL
Configuring Queries to Add Support for Custom Parameters and Lookup Fields for MySQL
About Configuring the Connector for Multiple Installations of MySQL
About Configuring the Connector for Multiple Trusted Source Reconciliation from MySQL
Configuring Validation of Data During Reconciliation and Provisioning for MySQL
Configuring Transformation of Data During User Reconciliation for MySQL
The following sections discuss the syntax and guidelines that you must apply while modifying the predefined queries or creating new queries:
Predefined queries are provided to reconcile target system user records, synchronize lookup field values with Oracle Identity Manager, and for provisioning operations. You can modify the predefined queries or add your own queries.
The query files are included in a JAR file in the bundle directory of the connector installation media. For example, bundle/org.identityconnectors.dbum-1.0.1116.jar.
The connector includes the following types of queries:
Provisioning Queries
They are used for create, update, and delete operations. The query file is scripts/mysql/Provisioning.queries.
List of Values Search Queries
They are used for reconciliation of lookup definitions. A list of value query operates on a set of values for fields such as profiles, privileges, roles, and tablespaces. The query file is scripts/mysql/LoVSearch.queries.
Account Search Queries
They are used for full and delete reconciliation operations. An account search query operates on account and group searches with various conditions. The query file is scripts/mysql/Search.queries.
Note:
The stored procedure OUT parameters cannot be configured for write-back on the process form. The returned values cannot be used for any connector operations.
The following is the syntax of the queries used for provisioning operations:
QUERYID {
Query="QUERY"
QueryType="QUERYTYPE"
Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]
ExtensionJoin="EXTENSIONJOIN"
ExtensionSeparator="EXTENSIONSEPARATOR"
QueryExtensions=["EXTENSION1","EXTENSION2"...]
}
For example:
CREATE_USER {
Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}"
QueryType="SQL"
Parameters=["__NAME__":"Type:String","__PASSWORD__":"Type:GuardedString,TAGS:QUOTES"]
QueryExtensions=[]
}
In this syntax:
QUERYID refers to the unique name of the query.
For example: CREATE_USER
QUERY refers to the main query.
For example: Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}"
QueryType refers to the type of the main query, either an SQL query or a stored procedure. The value of QUERYTYPE can be SQL or StoredProc.
For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.
For example: Parameters=["__NAME__":"Type:String","__PASSWORD__":"Type:GuardedString,TAGS:QUOTES"]
A parameter can have the following attributes:
Type is the type of the parameter.
Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
TAGS is the enclosure characters that are applied to each parameter before the query is processed. It can have a value of DOUBLEQUOTES, QUOTES, UPPERCASE, or LOWERCASE.
If you want to use multiple tags, you must encapsulate the tags in escaped quotes and separate them by commas. However, you must not use DOUBLEQUOTES with QUOTES or UPPERCASE with LOWERCASE in the same query.
For example: "Type:String,TAGS:\"DOUBLEQUOTES,UPPERCASE\"
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.
For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.
For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.
During a provisioning operation, the connector combines all these components to the following query:
QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]
For example:
CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}
using-and-extending-connector-mysql.htm#GUID-51430BEC-D598-4112-B44D-C22F85D35802__CHDDJGIC lists the script selection logic of the provisioning queries:
Table 5-16 Script Section Logic for MySQL Provisioning Queries
| Operation | Selection Logic | Query IDs |
|---|---|---|
|
CREATE |
CREATE_OBJECTYPE |
CREATE_USER |
|
DELETE |
DELETE_OBJECTTTYPE |
DELETE_USER |
|
RESET PASSWORD |
SET_PASSWORD |
SET_PASSWORD |
|
ADD CHILD VALUES |
UPDATE_ADD_ATTRIBUTE |
UPDATE_ADD_PRIVILEGES |
|
REMOVE CHILD VALUES |
UPDATE_REVOKE_ATTRIBUTE |
UPDATE_REVOKE_PRIVILEGES |
The following is the syntax of the search queries used during reconciliation operations:
QUERYID {
Query="QUERY"
QueryType="QUERYTYPE"
Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]
ExtensionJoin="EXTENSIONJOIN"
ExtensionSeparator="EXTENSIONSEPARATOR"
QueryExtensions=["EXTENSION1","EXTENSION2"...]
}
For example:
SEARCH_USER {
Query="SELECT {__UID__} FROM MYSQL.USER {filter}"
QueryType="SQL"
Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USER"]
QueryExtensions=["SEARCH_USER_PRIVILEGE"]
}
In this syntax:
QUERYID refers to the unique name of the query.
For example: SEARCH_USER
QUERYID can be one of the following values:
SEARCH_USER
BATCHED_SEARCH_USER
SEARCH_USER_PRIVILEGE
QUERY refers to the main query.
For example: Query="SELECT {__UID__} FROM MYSQL.USER {filter}"
QueryType refers to the type of the main query, either an SQL query, a stored procedure, or a query extension. The value of QUERYTYPE can be SQL, StoredProc, or QUERYEXTENSION.
For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.
For example:
Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USER"]
A parameter can have the following attributes:
Type is the type of the parameter.
Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
ColName is the column name in the target system corresponding to the parameter in the query.
ColQuery is the query used to fetch values for the corresponding query parameter.
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.
For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.
For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.
For example: QueryExtensions=["SEARCH_USER_PRIVILEGE"]
During a reconciliation operation, the connector combines all these components to the following query:
QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]
For example:
SELECT {__UID__} FROM MYSQL.USER {filter} SEARCH_USER_PRIVILEGE
If a search query is performed on account types, such as User Name, then the query is considered as a reconciliation query. If a search query is performed on any other object, then the query is considered as a list of values query.
The following is the syntax of the list of values queries used for lookup field synchronization:
OBJECTTYPE = "QUERY"
For example:
__PRIVILEGES__="SELECT CONCAT(p.PRIVILEGE_TYPE, ' ON ',s.SCHEMA_NAME) SchemaPrivilege FROM INFORMATION_SCHEMA.SCHEMATA s,INFORMATION_SCHEMA.SCHEMA_PRIVILEGES p"
In this syntax:
OBJECTTYPE refers to the lookup field attribute.
For example: __PRIVILEGES__
QUERY refers to the query used for fetching a lookup field attribute.
For example: SELECT CONCAT(p.PRIVILEGE_TYPE, ' ON ',s.SCHEMA_NAME) SchemaPrivilege FROM INFORMATION_SCHEMA.SCHEMATA s,INFORMATION_SCHEMA.SCHEMA_PRIVILEGES p
The list of values queries return values that are used as lookup field entries. By default, the connector includes dedicated scheduled job for each lookup definition. To use a custom lookup definition, you must add custom fields in the query file.
The connector uses preconfigured queries for connector operations such as create, delete, and search. You can add custom parameters and lookup definition fields as per your requirements.
The procedure to add a parameter or a lookup definition field to a query file is discussed in the following sections:
To update the query files:
If the connector is already installed, run the Oracle Identity Manager Download JARs utility to download the connector bundle JAR file from the Oracle Identity Manager database. This utility is copied into the following location when you install Oracle Identity Manager:
Note:
Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
For Microsoft Windows:
OIM_HOME/server/bin/DownloadJars.bat
For UNIX:
OIM_HOME/server/bin/DownloadJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Manager administrator, URL of the Oracle Identity Manager host computer, context factory value, type of JAR file being downloaded, and the location from which the JAR file is to be downloaded. Select ICFBundle as the JAR type.
Copy the bundle JAR file in a temporary directory.
Sample JAR file: bundle/org.identityconnectors.dbum-1.0.1116.jar
Sample temporary directory: c:\temp
Run the following command to extract the connector bundle JAR file:
jar -xvf org.identityconnectors.dbum-1.0.1116.jar
Note:
You can also run the WinZip or WinRAR utility to extract the contents from the JAR file.
Delete the bundle JAR file in the temporary directory.
Update the value of ConnectorBundle-Version in the manifest file, META-INF/MANIFEST.MF, to a new value.
For example:
ConnectorBundle-Version: 1.0.1117
Depending on your requirement, update the query files with new parameters as per the query syntax described in Modifying Predefined Queries or Creating New Queries for MySQL.
For example, if you want to add a new parameter, CUSTOM_ATTRIBUTE, to the CREATE_USER provisioning query:
Open the provisioning query file in a text editor.
Sample query file: c:\temp\bundle\org.identityconnectors.dbum-1.0.1116\scripts\mysql\Provisioning.queries
Add the parameter, CUSTOM_ATTRIBUTE, to the CREATE_USER query.
The following is a sample updated query:
CREATE_USER {
Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}, {CUSTOM_ATTRIBUTE}"
QueryType="SQL"
Parameters=["__NAME__":"Type:String", "__PASSWORD__":"Type:GuardedString,TAGS:QUOTES", "CUSTOM_ATTRIBUTE":"Type:String,Direction:IN"]
QueryExtensions=[]
}
Save and close the query file.
Create a new bundle JAR file that contains the updated manifest file and the provisioning query file as follows:
Open the command prompt and navigate to the temporary directory:
c:\temp
Run the following command:
jar -cvfm org.identityconnectors.dbum-1.0.1117.jar *
The new connector bundle JAR name contains the new bundle version.
In the case of a remote connector server, copy the new bundle JAR file in the bundles directory of the remote connector server, instead of posting the JAR file to the Oracle Identity Manager database. Skip to Step 10.
Run the Oracle Identity Manager Update JARs utility to update the JAR file created in Step 7 to the Oracle Identity Manager database. This utility is copied into the following location when you install Oracle Identity Manager:
Note:
Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
If you have installed both the Oracle and MySQL connectors on the same Oracle Identity Manager, then ensure that all third-party JAR files are part of the /lib directory in the connector bundle JAR file.
For Microsoft Windows:
OIM_HOME/server/bin/UpdateJars.bat
For UNIX:
OIM_HOME/server/bin/UpdateJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Manager administrator, URL of the Oracle Identity Manager host computer, context factory value, type of JAR file being updated, and the location from which the JAR file is to be updated. Select ICFBundle as the JAR type.
Update the configuration lookup with the new bundle version.
For example, you can update the Lookup.DBUM.MySQL.Configuration lookup definition.
You can skip this procedure if the parameter you added already exists as a default form field in Oracle Identity Manager.
To configure Oracle Identity Manager for adding a parameter:
Log into Oracle Identity Manager Design Console.
Create a new version of the process form:
Expand Development Tools.
Double-click Form Designer.
Search for and open the UD_DB_MYS_U process form.
Click Create New Version.
On the Create a new version dialog box, enter a new version in the Label field, and then click the save icon.
Add the new field on the process form.
Click Add.
A field is added to the list. Enter the details of the field.
For example, if you are adding the CustomAttribute1 field, enter UD_DB_MYS_U_CUSTOM1 in the Name field and then enter the rest of the details of this field.
Click the save icon and then click Make Version Active.
If you are using Oracle Identity Manager release 11.1.2.x or later, then all changes made to the Form Designer of the Design Console must be done in a new UI form as follows:
Log in to Oracle Identity System Administration.
Create and active a sandbox.
Create a new UI form to view the newly added field along with the rest of the fields. See Creating Forms By Using the Form Designer in Oracle Fusion Middleware Administering Oracle Identity Manager.
Associate the newly created UI form with the application instance of your target system. To do so, open the existing application instance for your resource, from the Form field, select the form (created in Step 4.c), and then save the application instance.
Publish the sandbox as described in Publishing a Sandbox of Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.
Create an entry for the field in the lookup definition for provisioning as follows:
Expand Administration.
Double-click Lookup Definition.
Search for and open the Lookup.DBUM.MySQL.UM.ProvAttrMap lookup definition.
Click Add and enter the Code Key and Decode values for the field.
The Code Key value must be the form field name. The Decode value must be the attribute name on the target system.
For example, enter Custom Attribute 1 in the Code Key field and then enter CustomAttribute1 in the Decode field.
Click the save icon.
Create a process task to update the new field Custom Attribute 1 as follows:
Expand Process Management.
Double-click Process Definition and open the MySQL DB User process definition.
Click Add and enter the task name, for example, Custom Attribute 1 Updated, and the task description.
In the process definition, select Conditional and Allow Multiple Instances fields and click the save icon.
On the Integration tab, click Add, and then click Adapter.
Select the adpMYSQLDBUMUPDATEUSER adapter, click the save icon, and then click OK in the message that is displayed.
To map the adapter variables listed in this table, select the adapter, click Map, and then specify the data given in the following table:
| Variable Name | Data Type | Map To | Qualifier | Literal Value |
|---|---|---|---|---|
|
Adapter return value |
Object |
Response code |
NA |
NA |
|
attributeName |
String |
Literal |
String |
Custom Attribute 1 |
|
itRes |
String |
Literal |
String |
UD_DB_MYS_U_ITRES |
|
objectType |
String |
Literal |
String |
User |
|
processInstanceKey |
Long |
Process Data |
Process Instance |
NA |
On the Responses tab, click Add to add the following response codes:
| Code Name | Description | Status |
|---|---|---|
|
ERROR |
Error occurred |
R |
|
UNKNOWN |
An unknown response was received |
R |
|
SUCCESS |
Operation completed |
C |
Click the save icon and then close the dialog box.
You might want to configure the connector for multiple installations of the target system. The following example illustrates this requirement:
The London and New York offices of Example Multinational Inc. have their own installations of the target system. The company has recently installed Oracle Identity Manager, and they want to configure Oracle Identity Manager to link all the installations of the target system.
To meet the requirement posed by such a scenario, you can create copies of connector objects, such as the IT resource and resource object.
The decision to create a copy of a connector object might be based on a requirement. For example, an IT resource can hold connection information for one target system installation. Therefore, it is mandatory to create a copy of the IT resource for each target system installation.
With some other connector objects, you do not need to create copies at all. For example, a single attribute-mapping lookup definition can be used for all installations of the target system.
All connector objects are linked. For example, a scheduled job holds the name of the IT resource. Similarly, the IT resource for a target system such as MySQL holds the name of the configuration lookup definition, Lookup.DBUM.MySQL.Configuration. If you create a copy of an object, then you must specify the name of the copy in associated connector objects.
Note:
To reconcile data from a particular target system installation, specify the name of the IT resource for that target system installation as the value of the scheduled job attribute that holds the IT resource name. For example, you enter the name of the IT resource as the value of the IT resource attribute of the scheduled job that you run.
When you use Identity Self Service to perform provisioning, you can specify the IT resource corresponding to the target system installation to which you want to provision the user.
using-and-extending-connector-mysql.htm#GUID-6EB127B6-2620-4EDE-A5DF-3AB68E14B031__CHDCDIJA lists associations between connector objects whose copies can be created and the other objects that reference these objects. When you create a copy of a connector object, use this information to change the associations of that object with other objects.
Note:
On a particular Oracle Identity Manager installation, if you create a copy of a connector object, then you must set a unique name for it.
If you are using Oracle Identity Manager release 11.1.2.x or later, then in addition to the procedure described in this section, you must create an application instance for each IT resource. See Configuring Oracle Identity Manager Release 11.1.2 or Later for information on creating an application instance.
Table 5-17 Connector Objects and Their Associations
| Connector Object | Name | Referenced By | Comments on Creating a Copy |
|---|---|---|---|
|
IT resource |
MySQL DB |
|
Create a copy of the IT resource with a different name. |
|
Resource object |
MySQL DB User MySQL DB Trusted |
All connector operations |
It is optional to create a copy of the resource object. If you are reconciling the same set of attributes from all installations of the target system, then you need not create a copy of the resource object. Note: Create copies of the resource object only if there are differences in attributes between the various installations of the target system. |
|
Scheduled Jobs |
There are many scheduled jobs for different purposes. |
NA |
You can use the scheduled jobs with the same names. However, you must update the values of the parameters depending on the target system you want to use. |
|
Process definition |
MySQL DB User |
NA |
It is optional to create a copy of the process definition. If you are reconciling or provisioning the same set of attributes from all installations of the target system, then you need not create a copy of the process definition. Note: Create copies of the process form only if there are differences in attributes between the various installations of the target system. |
|
Process form |
UD_DB_MYS_U |
MySQL DB User (Process definition) |
It is optional to create a copy of the process form. If you are provisioning the same set of attributes from all installations of the target system, then you need not create a copy of the process definition. Note: Create copies of the process form only if there are differences in attributes between the various installations of the target system. |
|
Child process form |
|
|
It is optional to create a copy of the child process form. If you are provisioning a new set of child data, then you need to create a copy of the child and parent process forms. Then, assign the newly created child process form to the newly created parent process form. |
|
Configuration lookup definition for a target system configured as a target resource |
Lookup.DBUM.MySQL.Configuration |
MySQL DB (IT resource) |
It is optional to create a copy of the configuration lookup definition. If you are provisioning and reconciling the same set of attributes in all installations of the target system (configured as a target resource), then you need not create a copy of the configuration lookup definition. Note: Create copies of the configuration lookup definition only if there are differences in attributes between the various installations of the target system and you have created a new process form. |
|
Configuration lookup definition for a target system configured as a trusted source |
Lookup.DBUM.MySQL.Configuration.Trusted |
MySQL DB (IT resource) |
It is optional to create a copy of the configuration lookup definition. If you are reconciling the same set of attributes in all installations of the target system (configured as a trusted source), then you need not create a copy of the configuration lookup definition. Note: Create copies of the configuration lookup definition for trusted source only if there are differences in attributes between the various installations of the target system and you have created a new process form. |
|
Resource object attributes mapping lookup definition (for target resource) |
Lookup.DBUM.MySQL.UM.ReconAttrMap |
NA |
It is optional to create a copy of resource object attribute mapping lookup definition. If you are reconciling the same set of attributes in all installations of the target system, then you need not to create a copy of resource object attribute mapping lookup. Note: Create copies of this lookup definition only if there are differences in attributes between the two installations of the target system. |
|
Configuration lookup definition for a target system configured as a trusted source |
Lookup.DBUM.MySQL.UM.ReconAttrMap.Trusted |
MySQL DB (IT resource) |
It is optional to create a copy of the configuration lookup definition. If you are reconciling the same set of attributes in all installations of the target system (configured as a trusted source), then you need not create a copy of the configuration lookup definition. Note: Create copies of the configuration lookup definition for trusted source only if there are differences in attributes between the various installations of the target system and you have created a new process form. |
Note:
This connector supports multiple trusted source reconciliation.
This section describes an optional procedure. Perform this procedure only if you want to configure the connector for multiple trusted source reconciliation.
The following are examples of scenarios in which there is more than one trusted source for user data in an organization:
One of the target systems is a trusted source for data about users. The second target system is a trusted source for data about contractors. The third target system is a trusted source for data about interns.
One target system holds the data of some of the identity fields that constitute an OIM User. Two other systems hold data for the remaining identity fields. In other words, to create an OIM User, data from all three systems would need to be reconciled.
If the operating environment of your organization is similar to that described in either one of these scenarios, then this connector enables you to use the target system as one of the trusted sources of person data in your organization.
See Managing Reconciliation in Oracle Fusion Middleware Administering Oracle Identity Manager for detailed information about multiple trusted source reconciliation.
You can configure validation of reconciled and provisioned single-valued data according to your requirements. For example, you can validate data fetched from the First Name attribute to ensure that it does not contain the number sign (#). In addition, you can validate data entered in the First Name field on the process form so that the number sign (#) is not sent to the target system during provisioning operations.
To configure validation of data:
You can configure transformation of reconciled single-valued user data according to your requirements. For example, you can use First Name and Last Name values to create a value for the Full Name field in Oracle Identity Manager.
To configure transformation of single-valued user data fetched during reconciliation:
You can specify a list of accounts that must be excluded from reconciliation and provisioning operations. Accounts whose user IDs you specify in the exclusion list are not affected by reconciliation and provisioning operations.
In one of the lookup definitions for exclusion lists, enter the user IDs of target system accounts for which you do not want to perform provisioning and reconciliation operations. See Lookup Definitions for Exclusion Lists for MySQL for information about the lookup definitions and the format of the entries in these lookups.
To add entries in the lookup for exclusions during provisioning and reconciliation operations for MySQL:
Learn about action scripts and how to configure them to run before or after the create, update, or delete an account provisioning operations.
This section provides information about the following topics:
Action scripts are scripts that you can configure to run before or after the create, update, or delete an account provisioning operations. For example, you could configure a script to run before every user creation. In another scenario, suppose you have a table called AUDIT_USERLOG where you want to log user creation activities performed only by the connector. Then, you could create and use after create script for adding data to this table after create operation.
Note:
To configure a before or after action, your connector must support running scripts. An exception is Groovy (with target set to Connector), which the Identity Connector Framework (ICF) supports by default for all converged connectors.
Every connector should specify which scripting language and which target it supports. This connector supports the following script:
shell: shell script
target: Connector
The target refers to the location where the script is executed. In this case, the script is executed on the same computer (JVM or .NET Runtime) where the connector is deployed. For example, if you deploy the connector on the connector server, the script will be executed on that computer.
That is, if you are using a local framework, the script runs in your JVM. If you are connected to a remote framework, the script runs in the remote JVM or .NET Runtime.