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 DB2 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:db2://[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:db2://192.168.16.76:50000/DBUSER
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=sales#port=50000
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 Roles lookup field to select a role to be assigned to a user from the list of available roles. 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: DB2 DB~SYS_ADM
While performing a provisioning operation in 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-db2.htm#GUID-92062C4A-E146-4BCE-A9B9-31D83E0E5BF1__CFAIAHAF lists column names of the tables in DB2 that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.
Table 6-2 Lookup Definitions Synchronized with DB2
Lookup Definition | Target Column Name |
---|---|
Lookup.DBUM.DB2.Schema |
Schema |
Lookup.DBUM.DB2.Tablespaces |
Tablespace |
Lookup.DBUM.DB2.UserType |
User Type |
By default, the Lookup.DBUM.DB2.UserType lookup definition contains the following entries for user types:
Code Key | Decode |
---|---|
GROUP |
GROUP |
USER |
USER |
The Lookup.DBUM.DB2.WithGrantOption lookup definition is used with tablespaces and schema. If you select With Grant Option, then tablespaces and schema are granted with this option. The Lookup.DBUM.DB2.WithGrantOption lookup definition contains the following entry:
Code Key | Decode |
---|---|
WITH GRANT OPTION |
WITH GRANT OPTION |
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.DB2.Configuration lookup definition holds connector configuration entries that are used during target resource reconciliation and provisioning operations.
Table 6-3 Entries in Lookup.DBUM.DB2.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. |
disableValuesSet |
|
Possible values for the disabled status of a user |
reservedWordsList |
"GRANT","REVOKE","OF","ON","TO", "DATABASE","TABLESPACE","SCHEMA","CREATEIN", "ALTERIN","DROPIN","FROM","USE" |
List of words that are reserved and are not allowed to be used in the names of the connector artifacts |
User Configuration Lookup |
Lookup.DBUM.DB2.UM.Configuration |
Name of the lookup definition that contains user-specific configuration properties Do not modify this entry. |
The Lookup.DBUM.DB2.UM.Configuration lookup definition holds user-specific connector configuration entries that are used during target resource reconciliation and provisioning operations.
Table 6-4 Entries in Lookup.DBUM.DB2.UM.Configuration
Code Key | Decode Key |
---|---|
Provisioning Attribute Map |
Lookup.DBUM.DB2.UM.ProvAttrMap |
Provisioning Exclusion List |
Lookup.DBUM.DB2.UM.ExclusionList |
Provisioning Validation Lookup |
Lookup.DBUM.DB2.UM.ProvValidations |
Recon Validation Lookup |
Lookup.DBUM.DB2.UM.ReconValidations |
Recon Attribute Map |
Lookup.DBUM.DB2.UM.ReconAttrMap |
Recon Exclusion List |
Lookup.DBUM.DB2.UM.ExclusionList |
Recon Transformation Lookup |
Lookup.DBUM.DB2.UM.ReconTransformations |
The Lookup.DBUM.DB2.Configuration.Trusted lookup definition holds connector configuration entries that are used during reconciliation and provisioning operations in trusted source mode.
Table 6-5 Entries in Lookup.DBUM.DB2.Configuration.Trusted
Code Key | Decode Key |
---|---|
Bundle Name |
|
Bundle Version |
1.0.1116 |
Connector Name |
|
disableValuesSet |
|
User Configuration Lookup |
Lookup.DBUM.DB2.UM.Configuration.Trusted |
The Lookup.DBUM.DB2.UM.Configuration.Trusted lookup definition holds user-specific connector configuration entries that are used during reconciliation and provisioning operations in trusted source mode.
Table 6-6 Entries in Lookup.DBUM.DB2.UM.Configuration.Trusted
Code Key | Decode Key |
---|---|
Recon Attribute Defaults |
Lookup.DBUM.DB2.UM.ReconDefaults.Trusted |
Recon Attribute Map |
Lookup.DBUM.DB2.UM.ReconAttrMap.Trusted |
Recon Exclusion List |
Lookup.DBUM.DB2.UM.ExclusionList.Trusted |
Recon Transformation Lookup |
Lookup.DBUM.DB2.UM.ReconTransformations.Trusted |
This section describes the following lookup definitions:
The Lookup.DBUM.DB2.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 6-7 Entries in Lookup.DBUM.DB2.UM.ProvAttrMap
Code Key | Decode Key |
---|---|
Return Id |
__UID__ |
UD_DB_DB2_S~Schema[LOOKUP] |
schemas~DBSchema~__NAME__ |
UD_DB_DB2_S~Schema Grant Option |
schemas~DBSchema~grantOption |
UD_DB_DB2_T~Tablespace[LOOKUP] |
tablespaces~DBTablespaces~__NAME__ |
UD_DB_DB2_T~Tablespace Grant Option |
tablespaces~DBTablespaces~grantOption |
Username |
__NAME__ |
User Type |
userType |
The Lookup.DBUM.DB2.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 6-8 Entries in Lookup.DBUM.DB2.UM.ReconAttrMap
Code Key | Decode Key |
---|---|
Return ID |
__UID__ |
Schema List~Schema Grant option |
schemas~DBSchema~grantOption |
Schema List~Schema Name[LOOKUP] |
schemas~DBSchema~__NAME__ |
Status |
__ENABLE__ |
Tablespace List~Tablespace Grant Option |
tablespaces~DBTablespaces~grantOption |
Tablespace List~Tablespace Name[LOOKUP] |
tablespaces~DBTablespaces~__NAME__ |
User Name |
__UID__ |
User Type |
userType |
The Lookup.DBUM.DB2.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 6-9 Entries in Lookup.DBUM.DB2.UM.ReconAttrMap.Trusted
Code Key | Decode Key |
---|---|
First Name |
__UID__ |
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 6-10 Entries in Lookup.DBUM.DB2.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.DB2.UM.ReconAttrMap or Lookup.DBUM.DB2.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.DB2.UM.ExclusionList
By default, this lookup definition has the following entry:
Code Key | Decode |
---|---|
User Name |
db2admin |
For trusted source mode: Lookup.DBUM.DB2.UM.ExclusionList.Trusted
By default, this lookup definition has the following entry:
Code Key | Decode |
---|---|
User ID |
db2admin |
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 DB2 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.DB2.UM.ReconTransformations
By default, this lookup definition has the following entries:
Code Key | Decode |
---|---|
Schema List |
db2.iam.connectors.dbum.transformations.SchemaGrantOptionTransformation |
Tablespace List |
db2.iam.connectors.dbum.transformations.TablespaceGrantOptionTransformation |
User Type |
db2.iam.connectors.dbum.transformations.UserTypeTransformation |
For trusted source mode: Lookup.DBUM.DB2.UM.ReconTransformations.Trusted
Configuring Transformation of Data During User Reconciliation for DB2 describes the procedure to add entries in these lookup definitions.
You can use the Lookup.DBUM.DB2.UM.ProvValidations lookup to configure validation of data during provisioning operations.
Configuring Validation of Data During Reconciliation and Provisioning for DB2 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 following scheduled jobs are used for lookup field synchronization:
DBUM DB2 Schema Lookup Reconciliation
DBUM DB2 Tablespaces Lookup Reconciliation
You must specify values for the attributes of these scheduled jobs. using-and-extending-connector-db2.htm#GUID-20B29024-2410-4477-88E0-BAF00CFD24F1__CFACCAEG describes the attributes of these scheduled jobs. The procedure to configure scheduled jobs is described later in the guide.
Table 6-11 Attributes of the Scheduled Jobs 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. Depending on the scheduled job you are using, the default values are as follows:
|
Object Type |
Enter the type of object whose values must be synchronized. Depending on the scheduled job you are using, the default values are as follows:
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 job is used to reconcile user data in the target resource (account management) mode of the connector:
DBUM DB2 User Target Reconciliation
The following scheduled job is used to reconcile user data in the trusted source (identity management) mode of the connector:
DBUM DB2 User Trusted Reconciliation
using-and-extending-connector-db2.htm#GUID-02A13E22-F50F-43A8-8EE8-F52EBFA1BC44__CFAFGBGD describes the attributes of the scheduled jobs.
Table 6-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 DB2 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 DB2 User Target Reconciliation: For DBUM DB2 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 DB2 User Target Reconciliation: For DBUM DB2 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. |
You can apply this procedure to configure the scheduled jobs for lookup fields synchronization and reconciliation.
See Scheduled Jobs for Lookup Field Synchronization for DB2 and Attributes for Scheduled Jobs for DB2 for the scheduled jobs that are part of the connector and for information about their attributes.
To configure a scheduled job:
If you are using 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 DB2.
After specifying the attributes, click Apply to save the changes.
Postinstallation steps are divided across the following sections:
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 Sourcefor 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 DB2 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.DB2.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.DB2.UM.ReconAttrMap for more information.
The Lookup.DBUM.DB2.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.DB2.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:
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, DB2 DB Trusted
.
IT Resource Type: Select the DB2 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.DB2.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 DB2 Target Recon
Rule element: User Login Equals User Name
The following are the reconciliation rules for trusted source reconciliation:
Rule name: DB2 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-db2.htm#GUID-A61C03F7-FD23-4236-B057-1BDFED357D11__CFADCBEF lists the action rules for target resource reconciliation.
Table 6-13 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-db2.htm#GUID-A61C03F7-FD23-4236-B057-1BDFED357D11__CFACBAIG lists the action rules for trusted source reconciliation.
Table 6-14 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 DB2 as a target resource: DBUM DB2 User Target Reconciliation
For DB2 as a trusted source: DBUM DB2 User Trusted Reconciliation
See Attributes for Scheduled Jobs for DB2 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/db2/Search.queries
.
The following table provides a list of parent parameters 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. |
userType |
Type of the user account The value of this parameter can be one of the following: USER or GROUP |
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 DB2 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 DB2.
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.
DB2 does not allow deletion of created user accounts. Therefore, as part of the Revoke Resource operation of Oracle Identity Manager, the following changes will be made:
On the target system, the corresponding user account is set to Inactive, which revokes connect and database administration authorizations for the user.
In Oracle Identity Manager, the tasks for the corresponding account are cancelled and the account status is set to Disabled.
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 DB2.
The following is an overview of the Create User provisioning process in DB2 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 DB2 DB User resource.
The administrator enters the data required for provisioning the DB2 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: DB2
Username: JDoe
User Type: USER
In addition, the administrator also enters the following values on the process form for granting tablespace and schema:
Tablespace: 3~USERSPACE1
Tablespace Grant Option: WITH GRANT OPTION
Schema: 3~SYSTOOLSPACE
Schema Grant Option: WITH GRANT OPTION
From the information available in the IT resource for the target system, the configuration (Lookup.DBUM.DB2.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 DB2 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 tablespace or schema to the target system account.
If the administrator did not enter any values for granting tablespace or schema, 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 tablespace and schema 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 tablespace and schema provisioning operation is formed. Depending on whether the administrator had granted a tablespace with the grant option, the SQL statement is one of the following:
If the administrator specified a value for granting the tablespace With Grant Option, then the following SQL statement is formed:
GRANT USE OF TABLESPACE USERSPACE1 TO USER jdoe WITH GRANT OPTION
If the administrator did not specify a value for granting tablespace With Grant Option, then the following SQL statement is formed:
GRANT USE OF TABLESPACE USERSPACE1 TO USER jdoe
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 11) 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 (DB2) and grants the USERSPACE1 tablespace 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 DB2 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 sections discuss the steps to be performed to enable request-based provisioning:
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 DB2.
To switch from request-based provisioning to direct provisioning:
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 DB2 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 DB2 DB User resource object.
Deselect the Self Request Allowed check box.
Click the save icon.
To switch from direct provisioning back to request-based provisioning:
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 DB2 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 DB2 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 Oracle 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 the Identity System Administration.
Modifying Predefined Queries or Creating New Queries for DB2
Configuring Queries to Add Support for Custom Parameters and Lookup Fields for DB2
About Configuring the Connector for Multiple Installations of DB2
About Configuring the Connector for Multiple Trusted Source Reconciliation from DB2
Configuring Validation of Data During Reconciliation and Provisioning for DB2
Configuring Transformation of Data During User Reconciliation for DB2
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/db2/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/db2/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/db2/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="GRANT CONNECT,DBADM,CREATETAB,BINDADD,CREATE_NOT_FENCED_ROUTINE,"+ "IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON "+ "DATABASE TO {userType} {__NAME__}" QueryType="SQL" Parameters=["__NAME__":"Type:String,Direction:IN", "userType":"Type:String,Direction:IN,Tags:EXCLUDE_VALIDATION"] 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="GRANT CONNECT,DBADM,CREATETAB,BINDADD,CREATE_NOT_FENCED_ROUTINE,"+ "IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON "+ "DATABASE TO {userType} {__NAME__}"
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,Direction:IN", "userType":"Type:String,Direction:IN,Tags:EXCLUDE_VALIDATION"]
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,
LOWERCASE, or EXCLUDE_VALIDATION.
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:
GRANT CONNECT,DBADM,CREATETAB,BINDADD,CREATE_NOT_FENCED_ROUTINE,"+ "IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON "+ "DATABASE TO {userType} {__NAME__}
using-and-extending-connector-db2.htm#GUID-DC42A273-79EA-4F82-BCB3-609EF1BDCEB1__CFAJEBCD lists the script selection logic of the provisioning queries:
Table 6-15 Script Section Logic for DB2 Provisioning Queries
Operation | Selection Logic | Query IDs |
---|---|---|
CREATE |
CREATE_OBJECTYPE |
CREATE_USER |
DELETE |
DELETE_OBJECTTTYPE |
DELETE_USER |
ENABLE |
ENABLE_OBJECTTTYPE |
ENABLE_USER |
DISABLE |
DISABLE_OBJECTTTYPE |
DISABLE_USER |
RESET PASSWORD |
SET_PASSWORD |
SET_PASSWORD |
ADD CHILD VALUES |
UPDATE_ADD_ATTRIBUTE |
UPDATE_ADD_TABLESPACES UPDATE_ADD_SCHEMAS |
REMOVE CHILD VALUES |
UPDATE_REVOKE_ATTRIBUTE |
UPDATE_REVOKE_TABLESPACES UPDATE_REVOKE_SCHEMAS |
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__}, {userType} FROM SYSIBM.SYSDBAUTH {filter}" QueryType="SQL" Parameters=["__UID__":"Type:String,Direction:OUT,ColName:GRANTEE", "userType":"Type:String,Direction:OUT,ColName:GRANTEETYPE"] QueryExtensions=["SEARCH_USER_TABLESPACE","SEARCH_USER_SCHEMA","SEARCH_USER_STATUS"] }
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_SCHEMA
SEARCH_USER_TABLESPACE
SEARCH_USER_STATUS
QUERY refers to the main query.
For example: Query="SELECT {__UID__}, {userType} FROM SYSIBM.SYSDBAUTH {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:GRANTEE", "userType":"Type:String,Direction:OUT,ColName:GRANTEETYPE"]
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_TABLESPACE","SEARCH_USER_SCHEMA","SEARCH_USER_STATUS"]
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__}, {userType} FROM SYSIBM.SYSDBAUTH {filter} SEARCH_USER_TABLESPACE, SEARCH_USER_SCHEMA, SEARCH_USER_STATUS
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:
__TABLESPACES__="SELECT DISTINCT tbspace FROM syscat.tablespaces"
In this syntax:
OBJECTTYPE refers to the lookup field attribute.
For example: __TABLESPACES__
and __SCHEMAS__
QUERY refers to the query used for fetching a lookup field attribute.
For example: SELECT DISTINCT tbspace FROM syscat.tablespaces
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 DB2.
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\db2\Provisioning.queries
Add the parameter, CUSTOM_ATTRIBUTE
, to the CREATE_USER
query.
The following is a sample updated query:
CREATE_USER { Query="GRANT CONNECT,DBADM,CREATETAB,BINDADD,CREATE_NOT_FENCED_ROUTINE,"+ "IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON "+ "DATABASE TO {userType} {__NAME__} {CUSTOM_ATTRIBUTE}" QueryType="SQL" Parameters=["__NAME__":"Type:String,Direction:IN", "userType":"Type:String,Direction:IN,Tags:EXCLUDE_VALIDATION", "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 DB2 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.DB2.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_DB2_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_DB2_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.DB2.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 DB2 DB User process definition.
Click Add and enter the task name, for example, Custom Attribute 1 Updated
, and the task description.
In the Task Properties section, select Conditional and Allow Multiple Instances fields and click the save icon.
On the Integration tab, click Add, and then click Adapter.
Select the adpDB2UPDATECHILDTABLEVALUES 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_DB2_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 DB2 holds the name of the configuration lookup definition, Lookup.DBUM.DB2.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-db2.htm#GUID-AF1DB012-DE2A-431C-92CF-3E8A485F942D__CFABBJEB 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 6-16 Connector Objects and Their Associations
Connector Object | Name | Referenced By | Comments on Creating a Copy |
---|---|---|---|
IT resource |
DB2 DB |
|
Create a copy of the IT resource with a different name. |
Resource object |
DB2 DB User DB2 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 |
DB2 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_DB2_U |
DB2 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.DB2.Configuration |
DB2 (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.DB2.Configuration.Trusted |
DB2 (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.DB2.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.DB2.UM.ReconAttrMap.Trusted |
DB2 (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 DB2 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 DB2:
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.