1 About the Connector

Oracle Identity Manager automates access rights management, security, and provisioning of IT resources. Oracle Identity Manager connectors are used to integrate Oracle Identity Manager with third-party applications. This guide discusses the procedure to deploy the connector that is used to integrate Oracle Identity Manager with database user management tables in IBM DB2 UDB, Microsoft SQL Server, MySQL, Oracle Database, and Sybase target systems.

In Microsoft SQL Server and Sybase, database access entities can be divided into the following types:

Microsoft SQL Server and Sybase treat these entities as parent (Login) and child (User) elements. In Oracle Identity Manager, these entities are treated as separate, independent entities. In other words, the connector provides login provisioning as well as user provisioning features in both Microsoft SQL Server and Sybase.

In IBM DB2 UDB, MySQL, and Oracle Database, the Login and User entities are treated as a single entity. In this guide, that entity is referred to as the Login entity.

Note:

At some places in this guide, Database User Management has been referred to as the target system.

This chapter contains the following sections:

1.1 Certified Components

Table 1-1 lists the certified components for the connector.

Table 1-1 Certified Components

Component Requirement

Oracle Identity Manager

You can use one of the following releases of Oracle Identity Manager:

  • Oracle Identity Manager release 9.1.0.2 BP08 or later

    Note: In this guide, Oracle Identity Manager release 9.1.0.x has been used to denote Oracle Identity Manager release 9.1.0.2 BP08 and future releases in the 9.1.0.x series that the connector will support.

  • Oracle Identity Manager 11g release 1 (11.1.1)

    Note: In this guide, Oracle Identity Manager release 11.1.1 has been used to denote Oracle Identity Manager 11g release 1 (11.1.1).

Target systems

The target system can be any one of the following:

  • IBM DB2 UDB Version 9.x

  • Microsoft SQL Server 2000, 2005, 2008

  • MySQL 5.1 or later

  • Oracle9i Database

  • Oracle Database 10g, 11g, as either single database or Oracle RAC implementation

  • Sybase Adaptive Server Enterprise 15.x

    Note: Sybase is supported as a target system only on Oracle Identity Manager release 9.1.0.x. If you are using Oracle Identity Manager release 11.1.1, then you cannot use the connector to integrate Sybase as a target system. This is tracked by Bug 9914961 in Chapter 7, "Known Issues."

JDK

The JDK version can be one of the following:

  • For Oracle Identity Manager release 9.1.0.x, use JDK 1.5

  • For Oracle Identity Manager release 11.1.1, use JDK 1.6 or later, or JRockit JDK 1.6 or later

Target system user account

Depending on the target system, one of the following user accounts is used by Oracle Identity Manager to perform reconciliation and provisioning operations on the target system:

  • For IBM DB2 UDB:

    Host operating system administrator account

    If IBM DB2 UDB is installed on a Microsoft Active Directory domain controller, then a Microsoft Windows 2003 Server (Domain Controller) Administrator account must be used.

  • For Microsoft SQL Server: sa (administrator)

  • For MySQL: root

  • For Oracle Database: sys as sysdba, or system

  • For Sybase: sa (administrator)

1.2 Certified Languages

The connector supports the following languages:

  • Arabic

  • Chinese Simplified

  • Chinese Traditional

  • Danish

  • English

  • French

  • German

  • Italian

  • Japanese

  • Korean

  • Portuguese (Brazilian)

  • Spanish

See Also:

Oracle Identity Manager Globalization Guide for information about supported special characters

1.3 Connector Architecture

This connector enables management of database accounts through Oracle Identity Manager. Figure 1-1 shows the architecture of the connector.

Figure 1-1 Architecture of the Connector

Description of Figure 1-1 follows
Description of "Figure 1-1 Architecture of the Connector"

The architecture of the connector can be explained in terms of the connector operations it supports:

1.3.1 Reconciliation Process

This connector can be configured to perform either trusted source reconciliation or target resource reconciliation.

Note:

It is recommended that you do not configure the target system as both a trusted source and a target resource.

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 or modified target system accounts. This data is used to create or update OIM Users.

See Also:

The "Reconciliation" section in Oracle Identity Manager Connector Concepts for conceptual information about target resource reconciliation and trusted source reconciliation.

The following is an overview of the steps involved in reconciliation:

Note:

In Oracle Identity Manager release 11.1.1, a scheduled job is an instance of a scheduled task. In this guide, the term scheduled task used in the context of Oracle Identity Manager release 9.1.0.x is the same as the term scheduled job in the context of Oracle Identity Manager release 11.1.1.

See Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about scheduled tasks and scheduled jobs.

  1. Depending on the target system that you are using, a SQL query or stored procedure is used to fetch target system records during reconciliation.

    All predefined SQL queries and stored procedures are stored in a properties file. Each query and stored procedures in the file is identified by a name. While configuring the scheduled tasks described in Section 3.4.5, "Reconciliation Scheduled Tasks," you specify the name of the query or stored procedure that you want to run as the value of the Query Name attribute.

  2. The scheduled task is run at the time or frequency that you specify. This scheduled task contains details of the mode of reconciliation (trusted source or target resource) that you want to perform.

  3. The scheduled task establishes a connection with the target system.

  4. The scheduled task reads values that you set for the task attributes, 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.

  5. Target system records that meet the query or stored procedure criteria are fetched into Oracle Identity Manager.

  6. If you have configured your target system as a trusted source, then:

    1. Each user record fetched from the target system is compared with existing OIM Users. The reconciliation rule is applied during the comparison process. See Section 1.6.3.2, "Reconciliation Rules for Trusted Source Reconciliation" for information about the reconciliation rule.

    2. 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.

  7. If you have configured your target system as a target resource, then:

    1. 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. See Section 1.6.3.1, "Reconciliation Rules for Target Resource Reconciliation" for information about the reconciliation rule.

    2. 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.

1.3.2 Provisioning Process

See Also:

The "Provisioning" section in Oracle Identity Manager Connector Concepts for conceptual information about provisioning

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.

The provisioning process can be started through one of the following events:

  • Direct provisioning

    The Oracle Identity Manager administrator uses the Administrative and User Console to create a target system account for a user.

  • Provisioning triggered by access policy changes

    An access policy related to accounts on the target system is modified. When an access policy is modified, it is reevaluated for all users to which it applies.

The following is an overview of the Create User provisioning process in Oracle Database that is started through direct provisioning. The provisioning process for other supported target systems is similar to the process described here.

  1. 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.

  2. The administrator selects the resource to be provisioned to the OIM User account that has been created. In this example, the administrator selects the Oracle DB User resource.

  3. The administrator enters the data required for provisioning the Oracle 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: Oracle

    • Username: JDoe

    • Authentication Type: PASSWORD

    • Password: my_pa55word

    • Default Tablespace: example

    • Profile Name: dba_user

    In addition, the administrator also enters the following values on the process form for granting roles:

    • Role: 3~JAVA_ADMIN

    • Role Admin Option: WITH ADMIN OPTION

  4. From the information available in the IT resource for the target system, the Configuration (Lookup.DBUM.Oracle.Configuration) lookup definition is identified. This lookup definition stores configuration information that is used during connector operations.

  5. The following entry in the Configuration lookup definition is read, and the Authentication Type Create User (Lookup.DBUM.Oracle.AuthType.KeyMapping.CreateUser) lookup definition is identified:

    Code Key Decode

    AuthType QueryCodeKey Mapping Lookup For CreateUser

    Lookup.DBUM.Oracle.AuthType.KeyMapping.CreateUser

    Note:

    If your database does not support authentication types for your database users, then the preceding lookup entry must not be present in your configuration lookup definition.

  6. The Authentication Type Create User lookup definition holds mappings between authentication types and names of SQL statements used for creating users.

    In Oracle Database, you can create a local database user, external database user, or global database user. Depending on the authentication type the administrator selects while performing Step 3, the name of the SQL statement to be run is identified.

    In this example, the following entry in the Authentication Type Create User lookup definition is read because the administrator selects password-based authentication while performing Step 3:

    Code Key Decode

    PASSWORD

    ORA_CREATE_USER

  7. Information in the Configuration lookup definition is read to identify the Query Configuration (Lookup.DBUM.Oracle.Query.Configuration) lookup definition, which maps SQL statement names with the SQL statements used for performing provisioning operations.

    The following entry in the Configuration lookup definition is read to identify the Query Configuration lookup definition:

    Code Key Decode

    Query Configuration Lookup

    Lookup.DBUM.Oracle.Query.Configuration

  8. The SQL statement name identified in Step 6 is used to determine the statement to be run to perform the provisioning operation.

    In Step 6, ORA_CREATE_USER, is identified as the name of the SQL statement to be run. The corresponding entry in the Query Configuration lookup definition is as follows:

    Code Key Decode

    ORA_CREATE_USER

    CREATE USER :ora_user_id IDENTIFIED BY :ora_password ACCOUNT UNLOCK~TABLESPACE_QUERY~TEMP_TABLESPACE_QUERY~PROFILE_QUERY~DEFAULTTS_QUOTA_QUERY~TEMPTS_QUOTA_QUERY

    The Decode value in the preceding table is a combination of the following elements:

    • SQL Keywords:

      For example, CREATE, USER, IDENTIFIED, and BY.

    • Identifiers:

      For example, ora_user_id and ora_password.

      Note:

      The actual values for these identifiers are determined later.

    • Name of SQL statement fragment: In the SQL statement used for the Create User provisioning operation, the following are the names of the SQL statement fragments:

      Note:

      Each SQL statement fragment name is separated by the tilde (~) character. Every SQL statement fragment name that is separated by the tilde character is optional.

      • TABLESPACE_QUERY

      • TEMP_TABLESPACE_QUERY

      • PROFILE_QUERY

      • DEFAULTTS_QUOTA_QUERY

      • TEMPTS_QUOTA_QUERY

  9. While performing Step 3, depending on whether the administrator had entered values in the Default Tablespace, Default Tablespace Quota (in MB), Temporary Tablespace, Temporary Tablespace Quota (in MB), or Profile Name process form fields, the Decode values of the corresponding SQL fragment name will be used.

    While provisioning the Oracle DB User resource in Step 3, the administrator had entered values for the Default Table Space and Profile Name process form fields. Therefore, the following lookup entries in the Query Configuration lookup definition are read:

    Code Key Decode

    TABLESPACE_QUERY

    DEFAULT TABLE SPACE :ora_default_tablespace

    PROFILE_QUERY

    PROFILE :ora_profile

  10. The complete SQL statement that must be run to perform the Create User provisioning operation is formed. In the example, this SQL statement is as follows:

    CREATE USER :ora_user_id IDENTIFIED BY :ora_password ACCOUNT UNLOCK DEFAULT TABLE SPACE :ora_default_tablespace PROFILE :ora_profile

  11. All input parameters required to run the SQL statement are stored in the Parameter Configuration (Lookup.DBUM.Oracle.Parameter.Configuration) lookup definition. The input parameters for the SQL statement (formed in Step 10) are retrieved by reading the following lookup entries:

    Code Key Decode

    ora_user_id

    UD_DB_ORA_U_USERNAME~varchar2~IN~UPPERCASE

    ora_password

    UD_DB_ORA_U_PASSWORD~varchar2~IN

    ora_default_tablespace

    UD_DB_ORA_U_TABLESPACE~varchar2~IN~EXCLUDE_VALIDATION

    ora_profile

    UD_DB_ORA_U_PROFILE~varchar2~IN~EXCLUDE_VALIDATION

  12. The identifiers in the SQL statement (formed in Step 10) are replaced with the input parameters fetched from the Decode values of the Parameter Configuration lookup definition. Then, the SQL statement with actual values is formed.

    Suppose while performing Step 1, the administrator enters jdoe as the value of the User ID field. While performing Step 3 of this procedure, the Username field is prepopulated with the value that the administrator had entered in the User ID field. Now, suppose while performing Step 3 of this procedure, the administrator enters example and dba_users as the values of the Default Table Space and Profile Name process form fields, respectively. The SQL statement with the actual values is as follows:

    CREATE USER jdoe IDENTIFIED BY dba_users ACCOUNT UNLOCK DEFAULT TABLE SPACE example PROFILE db_user

  13. The adapter runs the SQL statement on the target system (Oracle database) 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 roles or privileges to the target system account.

    If the administrator did not enter any values for granting roles, then the provisioning process ends here. Otherwise, the process continues to Step 14.

  14. While performing Step 3, the administrator had entered the required data for granting roles to the jdoe account. Therefore, the following lookup entry in the Query Configuration lookup definition is read:

    Code Key Decode

    ORA_ADD_ROLE

    GRANT :ora_role_name TO :ora_user_id_external~ROLE_WITH_ADMIN_OPTION

    In the preceding lookup entry, the SQL statement to grant a role is identified.

    The Decode value in the preceding table is a combination of the following elements:

    • SQL Keywords:

      For example, GRANT and TO.

    • Identifiers:

      For example, ora_role_name and ora_user_id_external.

    • SQL statement fragment name: ROLE_WITH_ADMIN_OPTION is the SQL fragment.

  15. While performing Step 3, in addition to specifying a value for the Role lookup field, if the administrator did not specify a value for the Role Admin Option lookup field, then proceed to Step 16.

    If the administrator had specified a value for the Role Admin Option lookup field, then the following lookup entry in the Query Configuration lookup definition is read:

    Code Key Decode

    ROLE_WITH_ADMIN_OPTION

    :ora_role_admin_option

  16. The complete SQL statement that must be run to perform the Add role provisioning operation is formed. Depending on whether the administrator had granted a role with the admin option, the SQL statement is one of the following:

    • If the administrator specified a value for granting the role with the admin option, then the following SQL statement is formed:

      GRANT :ora_role_name TO :ora_user_id_external :ora_role_admin_option

    • If the administrator did not specify a value for granting role with the admin option, then the following SQL statement is formed:

      GRANT :ora_role_name TO :ora_user_id_external

  17. The input parameters required to run the SQL statement are fetched from the Parameter Configuration (Lookup.DBUM.Oracle.Parameter.Configuration) lookup definition by reading the following lookup entries:

    Code Key Decode

    ora_role_name

    UD_DB_ORA_R_ROLE~varchar2~IN~EXCLUDE_VALIDATION

    ora_user_id_external

    UD_DB_ORA_U_USERNAME~varchar2~IN~DOUBLE_QUOTE~EXCLUDE_VALIDATION~UPPERCASE

  18. The identifiers in the SQL statement (formed in Step 16) are replaced with the input parameters fetched from the Decode values of the Parameter Configuration lookup definition. Then, the SQL statement with actual values is formed.

    While performing Step 3, the administrator had specified 3~JAVA_ADMIN as the value of the Role lookup field and WITH ADMIN OPTION as the value of the Role Admin Option lookup field. Therefore, the SQL statement with the actual values is as follows:

    GRANT 3~JAVA_ADMIN TO jdoe WITH ADMIN OPTION

    While performing Step 3, if the administrator did not specify a value for the Role Admin Option lookup field, then the SQL statement with the actual values is as follows:

    GRANT 3~JAVA_ADMIN TO jdoe

  19. The adapter runs the SQL statement on the target system (Oracle database) and grants the role 3~JAVA_ADMIN to the jdoe target system account.

  20. While performing Step 3, if the administrator had also specified required data for granting privileges then Steps 14 through 19 will be performed by reading the appropriate lookup entries in the Query Configuration and Parameter Configuration lookup definitions.

1.4 Features of the Connector

The following are features of the connector:

1.4.1 Mapping Standard and Custom Attributes for Reconciliation and Provisioning

You can create mappings for single-valued and multivalued target system attributes that are not included in the list of default attribute mappings. These attributes can be part of the standard set of attributes provided by the target system or custom attributes that you add on the target system.

See Chapter 4, "Extending the Functionality of the Connector" for more information.

1.4.2 Predefined and Custom Reconciliation Queries

Reconciliation involves running a SQL query or stored procedure on the target system database to fetch the required user account records to Oracle Identity Manager.

The connector provides predefined SQL queries and stored procedures that enable you to reconcile user data from the target system. These predefined SQL queries and stored procedures are stored in a file in the connector deployment package.

You can modify these SQL queries or stored procedures. In addition, you can add your own SQL queries or stored procedures for reconciliation.

See the following sections for more information:

1.4.3 Predefined and Custom Provisioning Statements

Provisioning involves running statements such as CREATE USER, ALTER USER, and DROP USER to perform Create User and Update user operations on the target system through Oracle Identity Manager.

The connector provides predefined statements that enable you to perform provisioning operations such as create, enable, and update target system accounts. These statements are stored in a lookup definition, which is created when you deploy the connector.

You can modify and use any of the predefined provisioning statements. In addition, you can create your own provisioning statements.

1.4.4 Framework for Supporting Connector Operations on JDBC-Based Databases

The Database User Management connector is built on a framework designed for JDBC-based databases. This framework enables you to perform connector operations on a target system other than IBM DB2 UDB, Microsoft SQL Server, MySQL, Oracle Database, and Sybase. You can configure the connector and add code to perform connector operations on your target system by performing the procedures described in Chapter 5, "Configuring the Connector for a JDBC-Based Database".

1.4.5 Support for Creating Global and External Users In Oracle Database

A local database user is a user who can be authenticated using a password stored in the database. In addition to support for local database users, the connector can also be used to work with the following types of users in Oracle Database:

  • Global users: These are database users who must be authorized by an enterprise directory service such as Oracle Internet Directory.

  • External users: These are database users who must be authenticated by an external service, such as an operating system or a third-party service such as Kerberos.

See Section A.4.9, "Lookup.DBUM.Oracle.Query.Configuration" for information about the SQL statements that are used for provisioning local, global, and external users.

1.4.6 Support for Configuring the Connector for Reconciling and Provisioning Object-Level Privileges in Oracle Database

You can configure this connector to reconcile and provision object-level privileges to a database user in Oracle Database. An object-level privilege is a permission that is granted to a database user to perform a particular action on a database object. This connector treats object-level privileges that are granted to a database user as an entitlement.

See Section 4.10, "Configuring the Connector for Reconciling and Provisioning Object-Level Privileges" for more information.

1.4.7 Dependent Lookup Fields

In earlier releases, if you had multiple installations of the target system, then entries in a lookup definition were not linked with the target system installation from which the entries were copied. During a provisioning operation, you could not select lookup field values that were specific to the target system installation on which the provisioning operation was to be performed.

From this release onward, entries in lookup definitions can be linked to the target system installation from which they are copied by enabling the dependent lookup fields feature.

See Section 4.5.1, "Enabling the Dependent Lookup Fields Feature" for information about enabling this feature.

See Section 1.5.1, "Lookup Definitions Synchronized with the Target System" for more information about the format in which data is stored in dependent lookup definitions.

1.4.8 Full and Incremental Reconciliation

After you deploy the connector, you can perform full reconciliation to bring all existing user data from the target system to Oracle Identity Manager. After the first full reconciliation run, you can configure your connector for incremental reconciliation. In incremental reconciliation, only records that are added or modified after the last reconciliation run are fetched into Oracle Identity Manager

See the following sections for more information:

1.4.9 Limited (Filtered) Reconciliation

To limit or filter the records that are fetched into Oracle Identity Manager during a reconciliation run, you can add conditions either in the WHERE clause of the reconciliation query that you run or in the Custom Query attribute of the scheduled task.

See Section 3.4.4, "Configuring Limited Reconciliation" for more information.

1.4.10 Batched Reconciliation

You can break down a reconciliation run into batches by specifying the number of records that must be included in each batch and the query that must be used to perform batched reconciliation.

Note:

Microsoft SQL Server and Sybase use stored procedures to perform reconciliation. Therefore, the connector does not support batched reconciliation.

See Section 3.4.3, "Batched Reconciliation" for more information.

1.4.11 Specifying Accounts to Be Excluded from Reconciliation and Provisioning Operations

You can specify a list of target system accounts that must be excluded from all reconciliation and provisioning operations. Accounts whose users attributes you specify in the exclusion list are not affected by reconciliation and provisioning operations.

See Section 3.1.3, "Setting Up the ExclusionList Lookup Definition" for more information.

1.4.12 Connection Pooling

A connection pool is a cache of objects that represent physical connections to the target. Oracle Identity Manager connectors can use these connections to communicate with target systems. At run time, the application requests a connection from the pool. If a connection is available, then the connector uses it and then returns it to the pool. A connection returned to the pool can again be requested for and used by the connector for another operation. By enabling the reuse of connections, the connection pool helps reduce connection creation overheads like network latency, memory allocation, and authentication.

One connection pool is created for each IT resource. For example, if you have three IT resources for three installations of the target system, then three connection pools will be created, one for each target system installation.

The configuration properties of the connection pool are part of the IT resource definition. Section 2.3.5, "Configuring the IT Resource" provides information about setting up the connection pool.

1.4.13 Support for Creating Connector Copies

You can configure this connector for multiple installations of your target system by creating copies of connector objects such as lookup definitions, resource objects, and process forms.

See Section 4.5, "Configuring the Connector for Multiple Installations of the Target System" for more information.

1.4.14 Transformation and Validation of Account Data

You can configure validation of account data that is brought into or sent from Oracle Identity Manager during reconciliation and provisioning. In addition, you can configure transformation of account data that is brought into Oracle Identity Manager during reconciliation. The following sections provide more information:

1.4.15 Support for Reconciling Data About Deleted Login Entities

You can reconcile data about login entities that have been deleted on the target system that has been configured as a trusted source or target resource.

After the records are fetched in to Oracle Identity Manager, depending on whether you have configured your target system as a target resource or trusted source, the records are compared with existing OIM Users or database resources provisioned to existing OIM Users.

See Section 3.4.5.2, "Scheduled Tasks for Reconciling Data About Deleted Users or Logins" for more information.

1.4.16 Separate Scheduled Tasks for Reconciliation of Users, Logins, and Deleted Login Entities

You can reconcile data about users, logins, or deleted login entities from a target system that is configured as a trusted source or target resource. Depending on the target system that you are using, the mode in which it is configured, and the type of data that you want to reconcile, separate scheduled tasks have been created.

See Section 3.4.5, "Reconciliation Scheduled Tasks" for more information.

1.4.17 Support for SSL Communication Between the Target System and Oracle Identity Manager

You can configure SSL to secure communication between Oracle Identity Manager and the target system.

See Section 2.3.3, "Configuring Secure Communication Between the Target System and Oracle Identity Manager" for more information.

1.4.18 Support for Managing Authorization to Oracle Database Vault Realms

Oracle Database Vault restricts access to specific areas in an Oracle Database from any user, including users who have administrative access. For example, you can restrict administrative access to employee salaries, customer medical records, or other sensitive information. This enables you to apply fine-grained access control to your sensitive data in a variety of ways. It hardens your Oracle Database instance and enforces industry standard best practices in terms of separating duties from users with administrative access. Most importantly, it protects data from super-privileged users but still allows them to manage the Oracle Database installation.

With Oracle Database Vault, you can address business requirements such as protecting against insider threats, meeting regulatory compliance requirements, and enforcing separation of duty.

You configure Oracle Database Vault to manage the security of an individual Oracle Database instance. You can install Oracle Database Vault on standalone Oracle Database installations, in multiple Oracle homes, and in Oracle Real Application Clusters (RAC) environments.

In Oracle Database installations on which Oracle Database Vault is installed, the connector can be used to grant and manage authorization to Oracle Database Vault realms. The connector treats access to Oracle Database Vault realms as an entitlement. You can use the connector to provision database users with access to multiple realms with different levels of access.

Because Oracle Identity Manager is an enterprise application for managing user accounts and access to entitlements, the connector does not support management of the following:

  • Realms

  • Command rules and rule sets

  • Factors

  • Secure Application Roles

See the following sections for more information:

1.4.19 Support for Configuring the Connector for Enterprise User Security

Oracle Enterprise User Security addresses user, administrative, and security challenges by using the identity management services supplied by Oracle Internet Directory, an LDAP-compliant directory service. Enterprise users are provisioned and managed centrally in an LDAP-compliant directory, such as Oracle Internet Directory, for database access. Enterprise users have a unique identity in the directory called the distinguished name (DN). When enterprise users log on to a database, the database authenticates those users by using their DN.

In Oracle Database installations configured with Oracle Enterprise User Security, the connector supports the creation of globally and externally authenticated users.

Note:

You must use either Oracle Identity Manager LDAP connectors or some other means to create the user in the LDAP-compliant directory.

You can use the connector to create and manage accounts of these enterprise users on the target database.

1.5 Lookup Definitions Used During Connector Operations

Lookup definitions used during connector operations can be categorized as follows:

1.5.1 Lookup Definitions Synchronized with the Target System

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 Role lookup field to select a role to be assigned to the 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 Database User Management 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 DBUMLookUpQuery.properties file. The DBUM Lookup reconciliation scheduled task is used to synchronize values of these lookup definitions with the target system. While configuring the DBUM Lookup reconciliation scheduled task, you specify the name of the lookup definition that you want to synchronize as the value of the Lookup Definition Name attribute. See Section 3.3, "Scheduled Task for Lookup Field Synchronization" for more information about this scheduled task.

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: Oracle~SYS_ADM

While performing a provisioning operation on the Administrative and User Console, 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. However, if you enable the Dependent Lookup Field feature, then only values that correspond to the IT resource that you select are displayed. See Section 4.5.1, "Enabling the Dependent Lookup Fields Feature" for information about enabling this feature.

During lookup field synchronization, new entries are appended to the existing set of entries in the lookup definitions. If you enable the Dependent Lookup Field feature, then you can switch between multiple installations of the same target system. Because the IT resource key is part of each entry created in each lookup definition, only lookup field entries that are specific to the IT resource you select during a provisioning operation are displayed.

Note:

The format in which data is stored after lookup definition synchronization remains the same whether or not the Dependent Lookup Field feature is enabled.

The following sections provide information about the lookup definitions in Oracle Identity Manager that correspond to each of the target systems:

1.5.1.1 Lookup Fields Synchronized with IBM DB2 UDB

Table 1-2 lists column names of the tables in IBM DB2 UDB that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.

Table 1-2 Lookup Definitions Synchronized with IBM DB2 UDB

Lookup Definition Target Table Name Target Column Name

Lookup.DBUM.DB2.Tablespaces

syscat.tablespaces

tbspace

Lookup.DBUM.DB2.Schema

syscat.tables

tabschema

1.5.1.2 Lookup Fields Synchronized with Microsoft SQL Server

Table 1-3 lists column names of the tables in Microsoft SQL Server that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.

Table 1-3 Lookup Definitions Synchronized with Microsoft SQL Server

Lookup Definition Target Table Name Target Column Name

Lookup.DBUM.MSSQL.DBNames

sys.sysdatabases

name

Lookup.DBUM.MSSQL.DBRoles

sysusers

name

Lookup.DBUM.MSSQL.DefaultLang

sys.syslanguages

alias

1.5.1.3 Lookup Fields Synchronized with MySQL

Table 1-4 lists column names of the tables in MySQL that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.

Table 1-4 Lookup Definitions Synchronized with MySQL

Lookup Definition Target Table Name Target Column Name

Lookup.DBUM.MySQL.SchemaPrivileges

information_schema.schema_privileges

PRIVILEGE_TYPE

Lookup.DBUM.MySQL.Schemata

information_schema.schemata

SCHEMA_NAME

1.5.1.4 Lookup Fields Synchronized with Oracle Database

Table 1-5 lists column names of the tables in Oracle Database that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.

Table 1-5 Lookup Definitions Synchronized with Oracle Database

Lookup Definition Target Table Name Target Column Name

Lookup.DBUM.Oracle.Profiles

dba_profiles

DISTINCT profile

Lookup.DBUM.Oracle.Roles

dba_roles

role

Lookup.DBUM.Oracle.Privileges

system_privilege_map

name

Lookup.DBUM.Oracle.Temp.Tablespace

dba_tablespaces

tablespace_name

Lookup.DBUM.Oracle.Tablespaces

dba_tablespaces

tablespace_name

1.5.1.5 Lookup Fields Synchronized with Sybase

Table 1-6 lists column names of the tables in Sybase that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.

Table 1-6 Lookup Definitions Synchronized with Sybase

Lookup Definition Target Table Name Target Column Name

Lookup.DBUM.Sybase.Databases

sysdatabases

name

Lookup.DBUM.Sybase.Roles

syssrvroles

name

Lookup.DBUM.Sybase.DefaultLang

syslanguages

alias

Lookup.DBUM.Sybase.DBGroups

sysusers

name

1.5.2 Preconfigured Lookup Definitions

This section describes the other 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.

The following sections discuss lookup definitions in Oracle Identity Manager for each target system:

1.5.2.1 Lookup Definitions for IBM DB2 UDB

The following are the lookup definitions that are created in Oracle Identity Manager for IBM DB2 UDB:

Note:

See Appendix A, "Lookup Definitions for IBM DB2 UDB" for information about each of the look up definitions.

Lookup.DBUM.DB2.Configuration

Lookup.DBUM.DB2.Error.Mapping

Lookup.DBUM.DB2.ExclusionList

Lookup.DBUM.DB2.Parameter.Configuration

Lookup.DBUM.DB2.Provisioning.Validation

Lookup.DBUM.DB2.Query.Configuration

Lookup.DBUM.DB2.TargetRecon.Delete.Mapping

Lookup.DBUM.DB2.TargetRecon.Mapping

Lookup.DBUM.DB2.TargetRecon.QueryFilter

Lookup.DBUM.DB2.TargetRecon.Schema.Configuration

Lookup.DBUM.DB2.TargetRecon.Schema.Mapping

Lookup.DBUM.DB2.TargetRecon.Schema.QueryFilter

Lookup.DBUM.DB2.TargetRecon.Tablespace.Configuration

Lookup.DBUM.DB2.TargetRecon.Tablespace.Mapping

Lookup.DBUM.DB2.TargetRecon.Tablespace.QueryFilter

Lookup.DBUM.DB2.TargetRecon.Transformation

Lookup.DBUM.DB2.TargetRecon.UserTypeMapping

Lookup.DBUM.DB2.TargetRecon.Validation

Lookup.DBUM.DB2.TrustedRecon.Configuration

Lookup.DBUM.DB2.TrustedRecon.Delete.Mapping

Lookup.DBUM.DB2.TrustedRecon.ExclusionList

Lookup.DBUM.DB2.TrustedRecon.Mapping

Lookup.DBUM.DB2.TrustedRecon.QueryFilter

Lookup.DBUM.DB2.TrustedRecon.Transformation

Lookup.DBUM.DB2.TrustedRecon.Validation

Lookup.DBUM.DB2.UserType

Lookup.DBUM.DB2.WithGrantOption

1.5.2.2 Lookup Definitions for Microsoft SQL Server

The following are lookup definitions that are created in Oracle Identity Manager for Microsoft SQL Server:

Note:

See Appendix A, "Lookup Definitions for Microsoft SQL Server" for information about each of the look up definitions.

Lookup.DBUM.MSSQL.AuthType

Lookup.DBUM.MSSQL.AuthType.KeyMapping.CreateLogin

Lookup.DBUM.MSSQL.AuthType.KeyMapping.CreateUser

Lookup.DBUM.MSSQL.AuthType.KeyMapping.DeleteLogin

Lookup.DBUM.MSSQL.AuthType.KeyMapping.DeleteUser

Lookup.DBUM.MSSQL.AuthType.KeyMapping.DisableLogin

Lookup.DBUM.MSSQL.AuthType.KeyMapping.EnableLogin

Lookup.DBUM.MSSQL.Configuration

Lookup.DBUM.MSSQL.Error.Mapping

Lookup.DBUM.MSSQL.ExclusionList

Lookup.DBUM.MSSQL.Parameter.Configuration

Lookup.DBUM.MSSQL.Provisioning.Validation

Lookup.DBUM.MSSQL.Query.Configuration

Lookup.DBUM.MSSQL.TargetRecon.Auth.Mapping

Lookup.DBUM.MSSQL.TargetRecon.Delete.Login.Mapping

Lookup.DBUM.MSSQL.TargetRecon.Delete.User.Mapping

Lookup.DBUM.MSSQL.TargetRecon.Login.Mapping

Lookup.DBUM.MSSQL.TargetRecon.Login.Transformation

Lookup.DBUM.MSSQL.TargetRecon.Login.Validation

Lookup.DBUM.MSSQL.TargetRecon.QueryFilter

Lookup.DBUM.MSSQL.TargetRecon.Role.Mapping

Lookup.DBUM.MSSQL.TargetRecon.User.Mapping

Lookup.DBUM.MSSQL.TargetRecon.User.Transformation

Lookup.DBUM.MSSQL.TargetRecon.User.Validation

Lookup.DBUM.MSSQL.TrustedRecon.Configuration

Lookup.DBUM.MSSQL.TrustedRecon.Delete.Mapping

Lookup.DBUM.MSSQL.TrustedRecon.ExclusionList

Lookup.DBUM.MSSQL.TrustedRecon.Mapping

Lookup.DBUM.MSSQL.TrustedRecon.QueryFilter

Lookup.DBUM.MSSQL.TrustedRecon.Transformation

Lookup.DBUM.MSSQL.TrustedRecon.Validation

1.5.2.3 Lookup Definitions for MySQL

The following are the lookup definitions that are created in Oracle Identity Manager for MySQL:

Note:

See Appendix A, "Lookup Definitions for MySQL" for information about each of the look up definitions.

Lookup.DBUM.MySQL.Configuration

Lookup.DBUM.MySQL.Error.Mapping

Lookup.DBUM.MySQL.ExclusionList

Lookup.DBUM.MySQL.Parameter.Configuration

Lookup.DBUM.MySQL.Provisioning.Validation

Lookup.DBUM.MySQL.Query.Configuration

Lookup.DBUM.MySQL.TargetRecon.Delete.Mapping

Lookup.DBUM.MySQL.TargetRecon.Mapping

Lookup.DBUM.MySQL.TargetRecon.QueryFilter

Lookup.DBUM.MySQL.TargetRecon.SchemaPrivilege.Configuration

Lookup.DBUM.MySQL.TargetRecon.SchemaPrivilege.Mapping

Lookup.DBUM.MySQL.TargetRecon.SchemaPrivilege.QueryFilter

Lookup.DBUM.MySQL.TargetRecon.Transformation

Lookup.DBUM.MySQL.TargetRecon.Validation

Lookup.DBUM.MySQL.TrustedRecon.Configuration

Lookup.DBUM.MySQL.TrustedRecon.Delete.Mapping

Lookup.DBUM.MySQL.TrustedRecon.ExclusionList

Lookup.DBUM.MySQL.TrustedRecon.Mapping

Lookup.DBUM.MySQL.TrustedRecon.QueryFilter

Lookup.DBUM.MySQL.TrustedRecon.Transformation

Lookup.DBUM.MySQL.TrustedRecon.Validation

1.5.2.4 Lookup Definitions for Oracle Database

The following are lookup definitions that are created in Oracle Identity Manager for Oracle Database:

Note:

See Appendix A, "Lookup Definitions for Oracle Database" for information about each of the look up definitions.

Lookup.DBUM.Oracle.AuthType

Lookup.DBUM.Oracle.AuthType.KeyMapping.CreateUser

Lookup.DBUM.Oracle.AuthType.KeyMapping.UpdateUser

Lookup.DBUM.Oracle.Configuration

Lookup.DBUM.Oracle.Error.Mapping

Lookup.DBUM.Oracle.ExclusionList

Lookup.DBUM.Oracle.Parameter.Configuration

Lookup.DBUM.Oracle.Provisioning.Validation

Lookup.DBUM.Oracle.Query.Configuration

Lookup.DBUM.Oracle.TargetRecon.Delete.Mapping

Lookup.DBUM.Oracle.TargetRecon.Mapping

Lookup.DBUM.Oracle.TargetRecon.Privilege.Configuration

Lookup.DBUM.Oracle.TargetRecon.Privilege.Mapping

Lookup.DBUM.Oracle.TargetRecon.Privilege.QueryFilter

Lookup.DBUM.Oracle.TargetRecon.QueryFilter

Lookup.DBUM.Oracle.TargetRecon.Role.Configuration

Lookup.DBUM.Oracle.TargetRecon.Role.Mapping

Lookup.DBUM.Oracle.TargetRecon.Role.QueryFilter

Lookup.DBUM.Oracle.TargetRecon.Transformation

Lookup.DBUM.Oracle.TargetRecon.Validation

Lookup.DBUM.Oracle.TrustedRecon.Configuration

Lookup.DBUM.Oracle.TrustedRecon.Delete.Mapping

Lookup.DBUM.Oracle.TrustedRecon.ExclusionList

Lookup.DBUM.Oracle.TrustedRecon.Mapping

Lookup.DBUM.Oracle.TrustedRecon.QueryFilter

Lookup.DBUM.Oracle.TrustedRecon.Transformation

Lookup.DBUM.Oracle.TrustedRecon.Validation

Lookup.DBUM.Oracle.WithAdminOption

1.5.2.5 Lookup Definitions for Sybase

The following are lookup definitions that are created in Oracle Identity Manager for Sybase:

Note:

See Appendix A, "Lookup Definitions for Sybase" for information about each of the look up definitions.

Lookup.DBUM.Sybase.Configuration

Lookup.DBUM.Sybase.Error.Mapping

Lookup.DBUM.Sybase.ExclusionList

Lookup.DBUM.Sybase.Parameter.Configuration

Lookup.DBUM.Sybase.Provisioning.Validation

Lookup.DBUM.Sybase.Query.Configuration

Lookup.DBUM.Sybase.TargetRecon.Delete.Login.Mapping

Lookup.DBUM.Sybase.TargetRecon.Delete.User.Mapping

Lookup.DBUM.Sybase.TargetRecon.Login.Mapping

Lookup.DBUM.Sybase.TargetRecon.Login.Transformation

Lookup.DBUM.Sybase.TargetRecon.Login.Validation

Lookup.DBUM.Sybase.TargetRecon.Role.Mapping

Lookup.DBUM.Sybase.TargetRecon.User.Mapping

Lookup.DBUM.Sybase.TargetRecon.User.Transformation

Lookup.DBUM.Sybase.TargetRecon.User.Validation

Lookup.DBUM.Sybase.TrustedRecon.Configuration

Lookup.DBUM.Sybase.TrustedRecon.Delete.Mapping

Lookup.DBUM.Sybase.TrustedRecon.ExclusionList

Lookup.DBUM.Sybase.TrustedRecon.Mapping

Lookup.DBUM.Sybase.TrustedRecon.QueryFilter

Lookup.DBUM.Sybase.TrustedRecon.Transformation

Lookup.DBUM.Sybase.TrustedRecon.Validation

Lookup.DBUM.TrustedRecon.StatusMapping

1.6 Connector Objects Used During Reconciliation

The following sections discuss connector objects used during reconciliation:

1.6.1 Reconciliation Queries

As mentioned earlier in this chapter, a SQL query or stored procedure is used to fetch target system records during reconciliation. All predefined SQL queries and stored procedures are stored in the DBUMReconQuery.properties file.

Note:

Depending on your requirements, you can modify existing queries or add your own query in the properties file. Alternatively, you can create and use your own properties file. Section 4.1, "Guidelines on Extending the Functionality of the Connector" provides more information.

Some of the predefined queries for Oracle Database are used in conjunction with the Last Execution Time scheduled task attribute. This attribute stores the time stamp at which the last reconciliation run started. When the next reconciliation run begins, only target system records for which the LAST UPDATED column value is greater than the value of the Last Execution Time attribute are fetched into Oracle Identity Manager. In other words, only records that were added or modified after the last reconciliation run started are considered for the current reconciliation run.

You can specify a value for the Last Execution Time attribute. See Section 3.4.2, "Reconciliation Time Stamp" for more information.

The following are predefined queries and stored procedures in the DBUMReconQuery.properties file:

  • IBM DB2 UDB

    The following are the predefined queries for IBM DB2 UDB:

    • DB2_TARGET_USER_RECON

      This query is used to fetch all grantee records from the SYSIBM.SYSDBAUTH table. It is used during target resource reconciliation.

    • DB2_TARGET_USER_RECON_WITH_BATCH

      This query is used to fetch from the SYSIBM.SYSDBAUTH table, grantee records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a target resource.

    • DB2_TARGET_USER_SCHEMA

      This query is used to fetch from the SYSIBM.SYSSCHEMAAUTH table, the name of the schema that a particular user can access.

    • DB2_TARGET_USER_TABLESPACE

      This query is used to fetch from the SYSIBM.SYSTBSPACEAUTH table, the name of the tablespace that a particular user can access.

    • DB2_TRUSTED_USER_RECON

      This query is used to fetch all grantee records from the SYSIBM.SYSDBAUTH table. It is used during trusted source reconciliation.

    • DB2_TRUSTED_USER_RECON_WITH_BATCH

      This query is used to fetch from the SYSIBM.SYSDBAUTH table grantee records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a trusted source.

    • DB2_DELETE_USER

      This query is used to fetch all grantee records from the SYSIBM.SYSDBAUTH tables. It is used to perform delete user reconciliation.

  • Microsoft SQL Server

    The following are the predefined queries and stored procedures for Microsoft SQL Server:

    • SQL_SERVER_DATABASE

      This query is used to fetch names of all databases that are managed by the Microsoft SQL Server instance.

    • SQL_SERVER_LOGIN

      This query is used to fetch all login names.

    • SQL_SERVER_LOGIN_DETAILS

      This stored procedure is used to fetch information about a given login and the users associated with it in each database.

    • SQL_SERVER_USER_DETAILS

      This stored procedure is used to fetch information about users in the current database.

    • SQL_SERVER_STATUS_AUTH_TYPE

      This query is used to fetch the status of a given login account on the target system. The result set specifies whether the login account is disabled. In addition, the result set specifies the authentication type used by the login account.

    • SQL_SERVER_LOGIN_USER_DELETE

      This query is used to fetch all login names. It is used to perform delete login reconciliation or delete user reconciliation.

  • MySQL

    The following are the predefined queries for MySQL:

    • MYSQL_TARGET_USER_PRIVILEGE

      This query is used to fetch from the information_schema.schema_privileges table, details of privileges granted to a given user.

    • MYSQL_TARGET_USER_RECON

      This query is used to fetch all user records from the mysql.user table. It is used during target resource reconciliation.

    • MYSQL_TARGET_USER_RECON_WITH_BATCH

      This query is used to fetch from the mysql.user table user records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a target resource.

    • MYSQL_DELETE_USER

      This query is used to fetch all user records form the mysql.user table. It is used to perform delete user reconciliation.

    • MYSQL_TRUSTED_USER_RECON

      This query is used to fetch all user records from the mysql.user table. It is used to perform trusted source reconciliation.

    • MYSQL_TRUSTED_USER_RECON_WITH_BATCH

      This query is used to fetch from the mysql.user table user records that are present within the specified range. This query is used to perform batched reconciliation on a target system that is configured as a trusted source.

  • Oracle Database

    The following are the predefined queries for Oracle Database:

    • ORACLE_TARGET_USER_RECON

      This query is used to fetch all user records from the DBA_USERS table. It is used during target resource reconciliation.

    • ORACLE_TARGET_USER_RECON_WITH_BATCH

      This query is used to fetch from the DBA_USERS table user records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a target resource.

    • ORACLE_TARGET_USER_ROLE

      This query is used to fetch from the DBA_ROLE_PRIVS table, details of roles granted to a particular user.

    • ORACLE_TARGET_USER_PRIVILEGE

      This query is used to fetch from the DBA_SYS_PRIVS table, details of privileges granted to a given user.

    • ORACLE_TRUSTED_USER_RECON

      This query is used to fetch all user records from the DBA_USERS table. It is used to perform trusted source reconciliation

    • ORACLE_TRUSTED_USER_RECON_WITH_BATCH

      This query is used to fetch from the DBA_USERS table, user records that are present within the specified range. This query is used to perform batched reconciliation on a target system that is configured as a trusted source.

    • ORACLE_RECON_TIME

      This query is used to determine the current time of the target system by calculating the difference in current date and 1st January, 1970 in milliseconds. This time is used as value for the Last Execution Time attribute of the scheduled task.

    • ORACLE_DELETE_USER

      This query is used to fetch all user records form the DBA_USERS table. It is used to perform delete user reconciliation.

  • Sybase

    The following are the predefined queries and stored procedures for Sybase:

    • SYBASE_DATABASE

      This query is used to fetch the names of all databases managed by the Sybase server instance.

    • SYBASE_LOGIN

      This query is used to fetch details of all login accounts.

    • SYBASE_LOGIN_DETAILS

      This stored procedure is used to display information about a given login account.

    • SYBASE_USER_DETAILS

      This stored procedure is used to fetch information about all users in the current database.

    • SYBASE_LOGIN_DELETE_USER

      This query is used to fetch all login accounts. It is used to perform delete login reconciliation.

1.6.2 Target System Columns Used in Reconciliation

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:

1.6.2.1 Target System Columns Used in Target Resource Reconciliation

Depending on the target system that you use, the following are the lookup definitions that map resource object fields and target system columns or column aliases used in the reconciliation query:

1.6.2.2 Target System Columns Used in Trusted Source Reconciliation

Depending on the target system that you use, the following are the lookup definitions that map resource object fields and target system columns or column aliases used in the reconciliation query:

1.6.3 Reconciliation Rules

See Also:

Oracle Identity Manager Connector Concepts for generic information about reconciliation rules and reconciliation action rules

The following sections provide information about reconciliation rules used by the reconciliation engine for this connector:

1.6.3.1 Reconciliation Rules for Target Resource Reconciliation

Reconciliation rules for target resource reconciliation can be divided into the following categories:

1.6.3.1.1 Reconciliation Rules for the Login Entity

Depending on the target system that you are using, the following are the reconciliation rules for the login entity:

  • Rule name for IBM DB2 UDB:

    DBUM DB2 Target Recon

  • Rule name for Microsoft SQL Server:

    DBUM MSSQL Login Target Recon

  • Rule Name for MySQL:

    DBUM MySQL Target Recon

  • Rule name for Oracle Database:

    DBUM Oracle Target Recon

  • Rule name for Sybase:

    DBUM Sybase Login Target Recon

Rule element for IBM DB2 UDB, MySQL, and Oracle Database: User Login Equals User Name

In this rule:

  • User Login is the field on the OIM User form.

  • User Name is the target system field.

Rule element for Microsoft SQL Server and Sybase: User Login Equals Login Name

In this rule:

  • User Login is the field on the OIM User form.

  • Login Name is the target system field.

1.6.3.1.2 Reconciliation Rules for the User Entity

Depending on the target system that you are using, the following are the reconciliation rules for the user entity:

  • Rule name for Microsoft SQL Server:

    DBUM MSSQL User Target Recon

  • Rule name for Sybase:

    DBUM Sybase User Target Recon

Rule element for all user entity reconciliation rules : User Login Equals User Name

In this rule:

  • User Login is the field on the OIM User form.

  • User Name is the target system field.

1.6.3.2 Reconciliation Rules for Trusted Source Reconciliation

For trusted source reconciliation, the same reconciliation rule is used for all target systems:

Rule name: DBUM Trusted Recon Rule

Rule element: User Login Equals User Login

In this rule element:

  • The User Login field to the left of "Equals" is the field on the OIM User form.

  • The User Login field to the right of "Equals" is the target system field.

1.6.3.3 Viewing Reconciliation Rules in the Design Console

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.

  1. Log in to the Oracle Identity Manager Design Console.

  2. Expand Development Tools.

  3. Double-click Reconciliation Rules.

  4. Search for the rule name.

1.6.4 Reconciliation Action Rules

The following sections provide information on the reconciliation action rules for reconciliation:

1.6.4.1 Reconciliation Action Rules for Target Resource Reconciliation

Table 1-7 lists the action rules for target resource reconciliation.

Table 1-7 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

Note:

No action is performed for rule conditions that are not predefined for this connector. You can define your own action rule for such rule conditions. See Oracle Identity Manager Design Console Guide for information about modifying or creating reconciliation action rules.

1.6.4.2 Reconciliation Action Rules for Trusted Source Reconciliation

Table 1-8 lists the action rules for trusted source reconciliation.

Table 1-8 Action Rules for Trusted Source Reconciliation

Rule Condition Action

No Matches Found

Create User

One Entity Match Found

Establish Link

Note:

No action is performed for rule conditions that are not predefined for this connector. You can define your own action rule for such rule conditions. See Oracle Identity Manager Design Console Guide for information about modifying or creating reconciliation action rules.

1.6.4.3 Viewing Reconciliation Action Rules

After you deploy the connector, you can view the reconciliation action rules for target resource reconciliation by performing the following steps:

  1. Log in to the Oracle Identity Manager Design Console.

  2. Expand Resource Management.

  3. Double-click Resource Objects.

  4. Search for and open the resource object. The following are the names of the resource objects for each target system database:

    • Resource object for IBM DB2 UDB:

      DB2 DB User

    • Resource object for Microsoft SQL Server login entity:

      MSSQL DB User Login

    • Resource object for Microsoft SQL Server user entity:

      MSSQL DB User

    • Resource object for MySQL:

      MySQL User

    • Resource object for Oracle Database:

      Oracle DB User

    • Resource object for Sybase login entity:

      Sybase DB User Login

    • Resource object for Sybase login entity:

      Sybase DB User Login

  5. Click the Object Reconciliation tab, and then click the Reconciliation Action Rules tab. The Reconciliation Action Rules tab displays the action rules defined for this connector.

1.7 Connector Objects Used During Provisioning

Provisioning involves creating or modifying user account on the target system through Oracle Identity Manager.

See Also:

The "Provisioning" section in Oracle Identity Manager Connector Concepts for conceptual information about provisioning

This section is divided into the following topics:

1.7.1 Provisioning Functions

The following sections list the supported provisioning functions and the corresponding adapters that perform these functions for each target system:

1.7.1.1 Provisioning Functions for IBM DB2 UDB

Table 1-9 lists the supported provisioning functions and the adapters that perform these functions.

See Also:

Oracle Identity Manager Connector Concepts for generic information about process tasks and adapters

Table 1-9 Provisioning Functions for IBM DB2 UDB

Function Adapter

Create user

adpDBUMExecuteQuery

Delete user

adpDBUMExecuteQuery

Enable user

adpDBUMExecuteQuery

Disable user

adpDBUMExecuteQuery

Add tablespace

adpDBUMExecuteQuery

Add schema

adpDBUMExecuteQuery

Update Tablespace

adpDBUMExecuteOldDataQuery

Delete Tablespace

adpDBUMExecuteOldDataQuery

Update Schema

adpDBUMExecuteOldDataQuery

Delete Schema

adpDBUMExecuteOldDataQuery

Update user name

adpDBUMPreventUpdate

Update tablespace grant option

adpDBUMPreventUpdate

Update schema grant option

adpDBUMPreventUpdate

1.7.1.2 Provisioning Functions for Microsoft SQL Server

Table 1-10 lists the supported provisioning functions and the adapters that perform these functions.

See Also:

Oracle Identity Manager Connector Concepts for generic information about process tasks and adapters

Table 1-10 Provisioning Functions for Microsoft SQL Server

Function Adapter

Login entity provisioning functions

  

Create login

adpDBUMExecuteStoredProcForAuthTypeUser

Delete login

adpDBUMExecuteStoredProcForAuthTypeUser

Enable login

adpDBUMExecuteQueryForAuthTypeUser

Disable login

adpDBUMExecuteQueryForAuthTypeUser

Update login name

adpDBUMPreventUpdate

Update password

adpDBUMExecuteStoredProc

Update default language

adpDBUMExecuteStoredProc

Update default database

adpDBUMExecuteStoredProc

Update authentication type

adpDBUMPreventUpdate

User entity provisioning functions

  

Create user

adpDBUMExecuteStoredProcForAuthTypeUser

Delete user

adpDBUMExecuteStoredProcForAuthTypeUser

Enable user

adpDBUMPreventEnable

Disable user

adpDBUMPreventDisable

Add role

adpDBUMExecuteStoredProc

Remove role

adpDBUMExecuteOldDataStoredProc

Update login name

adpDBUMPreventUpdate

Update user name

adpDBUMPreventUpdate

Update database group

adpDBUMExecuteStoredProc

Update role

adpDBUMExecuteOldDataStoredProc

1.7.1.3 Provisioning Functions for MySQL

Table 1-11 lists the supported provisioning functions and the adapters that perform these functions.

See Also:

Oracle Identity Manager Connector Concepts for generic information about process tasks and adapters

Table 1-11 Provisioning Functions for MySQL

Function Adapter

Create user

adpDBUMExecuteQuery

Delete user

adpDBUMExecuteQuery

Add privilege

adpDBUMExecuteQuery

Revoke privilege

adpDBUMExecuteOldMultiDataQuery

Update privilege

adpDBUMExecuteOldMultiDataQuery

Update user name

adpDBUMPreventFunctionality

Update password

adpDBUMExecuteQuery

Enable user

adpDBUMPreventEnable

Disable user

adpDBUMPreventDisable

1.7.1.4 Provisioning Functions for Oracle Database

Table 1-12 lists the supported provisioning functions and the adapters that perform these functions.

See Also:

Oracle Identity Manager Connector Concepts for generic information about process tasks and adapters

Table 1-12 Provisioning Functions for Oracle Database

Function Adapter

Create user

adpDBUMExecuteQueryForAuthTypeUser

Delete user

adpDBUMExecuteQuery

Add role

adpDBUMExecuteQuery

Revoke role

adpDBUMExecuteOldDataQuery

Update role

adpDBUMExecuteOldDataQuery

Update role admin option

adpDBUMPreventFunctionality

Add privilege

adpDBUMExecuteQuery

Revoke privilege

adpDBUMExecuteQuery

Update privilege

adpDBUMExecuteOldDataQuery

Update privilege admin option

adpDBUMPreventFunctionality

Update user name

adpDBUMPreventFunctionality

Update default tablespace

adpDBUMExecuteQuery

Update default tablespace quota

adpDBUMExecuteQuery

Update temporary tablespace

adpDBUMExecuteQuery

Update temporary tablespace quota

adpDBUMExecuteQuery

Update authentication type

adpDBUMExecuteQueryForAuthTypeUser

Update global DN

adpDBUMExecuteQuery

Update password

adpDBUMExecuteQuery

Update profile name

adpDBUMExecuteQuery

Enable user

adpDBUMExecuteQuery

Disable user

adpDBUMExecuteQuery

1.7.1.5 Provisioning Functions for Sybase

Table 1-13 lists the supported provisioning functions and the corresponding adapters that perform these functions. The functions listed in the table correspond to either a single or multiple process tasks.

See Also:

Oracle Identity Manager Connector Concepts for generic information about process tasks and adapters

Table 1-13 Provisioning Functions for Sybase

Function Adapter

Login entity provisioning functions

  

Create login

adpDBUMExecuteStoredProc

Delete login

adpDBUMExecuteStoredProc

Enable login

adpDBUMExecuteStoredProc

Disable login

adpDBUMExecuteStoredProc

Update login name

adpDBUMPreventFunctionality

Update password

adpDBUMExecuteOldDataStoredProc

Update default language

adpDBUMExecuteStoredProc

Update default database

adpDBUMExecuteStoredProc

Update full name

adpDBUMExecuteStoredProc

Add role

adpDBUMExecuteStoredProc

Remove role

adpDBUMExecuteOldDataStoredProc

Update role

adpDBUMExecuteOldDataStoredProc

User entity provisioning functions

  

Create user

adpDBUMExecuteStoredProc

Delete user

adpDBUMExecuteStoredProc

Disable user

adpDBUMPreventFunctionality

Enable user

adpDBUMPreventFunctionality

Update login name

adpDBUMPreventFunctionality

Update user name

adpDBUMPreventFunctionality

1.7.2 Attributes for Provisioning

This section discusses the following topics:

1.7.2.1 Attributes for Provisioning in IBM DB2 UDB

Table 1-14 lists the process form fields and the corresponding target system column names for which you can specify or modify values during provisioning operations.

Table 1-14 Attributes for Provisioning in IBM DB2 UDB

Process Form Field Target Table Name Target Column Name Description Mandatory?

Username

SYSIBM.SYSDBAUTH

GRANTEE

User ID

Yes

User Type

SYSIBM.SYSDBAUTH

GRANTEETYPE

Type of user

Yes

Tablespace Child Form Fields

        

Tablespace

SYSIBM.SYSSCHEMAAUTH

TBSPACE

Tablespace name

No

Tablespace Grant Option

NA

NA

Grant tablespace to user with the option to grant tablespaces to other users

No

Schema Child Form Fields

        

Schema

SYSIBM.SYSSCHEMAAUTH

SCHEMANAME

Schema name

No

Schema Grant Option

NA

NA

Grant schema to user with the option to grant schemas to other users

No

1.7.2.2 Attributes for Provisioning in Microsoft SQL Server

Table 1-15 lists the process form fields and the corresponding target system column names for which you can specify or modify values during provisioning operations.

Table 1-15 Attributes for Provisioning in Microsoft SQL Server

Process Form Field Stored Procedure Description Mandatory?

Login entity provisioning fields

      

Login Name

If the login account uses Microsoft SQL Server authentication, then the following stored procedures are used:

  • sp_droplogin(:mssql_login)

  • sp_addlogin(:mssql_login,:mssql_pass,:mssql_dbname,:mssql_dbdefaultlang)

If the login account uses Microsoft Windows authentication, then the following stored procedures are used:

  • sp_revokelogin(:mssql_login)

  • sp_grantlogin(:mssql_login)

Login name

Yes

Password

sp_password(null,:mssql_pass,:mssql_login)

Login password

Yes, if the login account uses Microsoft SQL Server authentication.

Default Database

sp_defaultdb(:mssql_login,:mssql_dbname),

Default database name

Yes, if the login account uses Microsoft Windows authentication.

Default Language

sp_defaultlanguage(:mssql_login,:mssql_dbdefaultlang)

Default language

Yes, if the login account uses Microsoft Windows authentication.

Authentication Type

  

Type of authentication

Yes

User entity provisioning fields

      

Login Name

sp_adduser(:mssql_parent_login,:mssql_user_id,null)

Existing login account name

Yes

Username

If the login account associated with the user account uses SQL Server authentication, then the following stored procedures are used:

  • sp_adduser(:mssql_parent_login,:mssql_user_id,null)

  • sp_dropuser(:mssql_user_id)

If the login account associated with the user account uses Microsoft Windows authentication, then the following stored procedures are used:

  • sp_grantdbaccess(:mssql_parent_login,:mssql_user_id)

  • sp_revokedbaccess(:mssql_user_id)

User name

No

Database Name

  

Current database name in which the user account exists

No

Role Child Form Fields for User Entity

      

Role

  • sp_addrolemember(:mssql_role,:mssql_user_id)

  • sp_droprolemember(:mssql_role,:mssql_user_id)

Role name granted to user

no

1.7.2.3 Attributes for Provisioning in MySQL

Table 1-14 lists the process form fields and the corresponding target system column names for which you can specify or modify values during provisioning operations.

Table 1-16 Attributes for Provisioning in MySQL

Process Form Field Target Table Name Target Column Name Description Mandatory?

User Name

USER

USER

User name

Yes

Password

USER

PASSWORD

User's password

Yes

Privilege Child Form Fields

        

Privilege

SCHEMA_PRIVILEGES

PRIVILEGE_TYPE

Privilege type granted on schema

Yes

Schema Name

SCHEMA_PRIVILEGES

TABLE_SCHEMA

Schema Name on which privilege to be granted

Yes

1.7.2.4 Attributes for Provisioning in Oracle Database

Table 1-17 lists the process form fields for which you can specify or modify values during provisioning operations.

Table 1-17 Attributes for Provisioning in Oracle Database

Process Form Field Target Table Name Target Column Name Description Mandatory?

User Name

DBA_USERS

USERNAME

User name

Yes

Password

DBA_USERS

PASSWORD

User's password

Yes, if the user account uses password authentication

Authentication Type

DBA_USERS

PASSWORD

Type of authentication that user accounts use to connect to the database

Yes

Global DN

DBA_USERS

EXTERNAL_NAME

Distinguished external name that identifies the user at the enterprise directory server

No

Account Status

DBA_USERS

ACCOUNT_STATUS

Status of the user account

No

Default Tablespace

DBA_USERS

DEFAULT_TABLESPACE

Default tablespace

No

Default Tablespace Quota

DBA_TS_QUOTAS

MAX_BYTES

Quota allocated to the user account on the tablespace.

The following are the formats in which this value can be specified: bytes, kilobytes (K), megabytes (M), gigabytes (G), terabytes (T), petabytes (P), or exabytes (E).

For example, if you want to allocate 100 megabytes of tablespace, the value to be provided is 100M.

No

Temporary Tablespace

DBA_USERS

TEMPORARY_TABLESPACE

Temporary tablespace name

No

Temporary Tablespace Quota

DBA_TS_QUOTAS

MAX_BYTES

Quota allocated to the user account on the tablespace.

The following are the formats in which this value can be specified: bytes, kilobytes (K), megabytes (M), gigabytes (G), terabytes (T), petabytes (P), or exabytes (E).

For example, if you want to allocate 100 megabytes of tablespace, the value to be provided is 100M.

No

Profile Name

DBA_USERS

PROFILE

Name of the profile

No

Role Child Form Fields

        

Role

DBA_ROLE_PRIVS

GRANTED_ROLE

Role name granted to user

No

Role Admin option

DBA_ROLE_PRIVS

ADMIN_OPTION

Grant role to user with the option to grant roles to other users

No

Privilege Child Form Fields

        

Privilege

DBA_SYS_PRIVS

PRIVILEGE

Privilege name granted to user

No

Privilege Admin option

DBA_SYS_PRIVS

ADMIN_OPTION

Grant privilege to user with the option to grant privileges to other users

No

1.7.2.5 Attributes for Provisioning in Sybase

Table 1-18 lists the process form fields for which you can specify or modify values during provisioning operations.

Table 1-18 Attributes for Provisioning in Sybase

Process Form Field Stored Procedure Name Description Mandatory?

Login entity provisioning fields

      

Login Name

  • sp_addlogin(:syb_login,:syb_pass,:syb_defdb,:syb_deflang,:syb_fullname)

  • sp_locklogin(:syb_login,'unlock')

  • sp_locklogin(:syb_login,'lock')

  • sp_droplogin(:syb_login)

Login name

Yes

Password

sp_password(:syb_old_pass,:syb_pass,:syb_login)

Login password

Yes

Default Database

sp_password(:syb_old_pass,:syb_pass,:syb_login)

Default database name

No

Default Language

sp_modifylogin(:syb_login,'deflanguage',:syb_deflang),

Default language

No

Full Name

sp_modifylogin(:syb_login,'fullname',:syb_fullname),

Full name of the login

No

Role Child Form Fields for Login Entity

      

Role

  • sp_role('grant',:syb_role,:syb_login)

  • sp_role('revoke',:syb_role,:syb_login)

Role name

No

User entity provisioning fields

      

Login Name

sp_adduser(:syb_user_login,:syb_user_id,:syb_group)

Existing login account name

No

Username

  • sp_adduser(:syb_user_login,:syb_user_id,:syb_group)

  • sp_dropuser(:syb_user_id)

User name

No

Database Group

sp_changegroup(:syb_group,:syb_user_id)

Database group name

No

1.8 Roadmap for Deploying and Using the Connector

The following is the organization of information in the rest of this guide: