1. Administering Oracle Directory Integration Platform
  2. Provisioning with the Oracle Directory Integration Platform
  3. Deploying Provisioning-Integrated Applications

16 Deploying Provisioning-Integrated Applications

This chapter explains how to deploy provisioning-integrated applications with the Oracle Provisioning Service.

Topics:

See Also:

Managing the Oracle Directory Integration Platform

16.1 Deploying Provisioning-Integrated Applications

Perform the steps described in this section to deploy provisioning-integrated applications with the Oracle Provisioning Service.

Complete the following steps:

  1. Install the back-end directory and Oracle Directory Integration Platform.

    Note:

    • Only Oracle Unified Directory and Oracle Internet Directory is supported for provisioning.

    • If you are using Oracle Unified Directory for provisioning, ensure that Oracle Directory Integration Platform is enabled as described in Installing Oracle Unified Directory.

  2. Load user information into Oracle Internet Directory or Oracle Unified Directory.
  3. Start the Oracle Directory Integration Platform.
  4. Install the applications and use the manageProvProfiles to create a provisioning profile for each application. Refer to "About manageProvProfiles Command" for more information.
  5. Configure application registration by following the procedures described in "Registering Applications for Provisioning".
  6. Configure application provisioning by following the procedures described in "Understanding How to Configure Application Provisioning Properties".
  7. Periodically monitor the status of the provisioning event propagation for each application. You can do this by using the Oracle Enterprise Manager Fusion Middleware Control.

    See Also:

16.2 About manageProvProfiles Command

Use the manageProvProfiles command to manage provisioning profiles.

Provisioning enables you to ensure that an application is notified of directory changes, such as changes to user or group information. Such changes can affect whether the application allows a user access to its processes and resources.

When you install an application that you want to provision, you must create a provisioning integration profile using the manageProvProfiles command located in the ORACLE_HOME/bin directory. For more information, see manageProvProfiles Command and Tasks and Examples for manageProvProfiles.

You can use the manageProvProfiles to:

  • Create a new provisioning profile. A new provisioning profile is created and set to the enabled state so that Oracle Directory Integration Platform can process it.

  • Disable an existing provisioning profile.

  • Enable a disabled provisioning profile.

  • Modify an existing provisioning profile.

  • Delete an existing provisioning profile.

  • Get the current status of a given provisioning profile.

  • Clear all of the errors in an existing provisioning profile.

The manageProvProfiles utility shields the location and schema details of the provisioning profile entries from the callers of the tool. From the callers' perspective, the combination of an application and a realm uniquely identify a provisioning profile. The constraint in the system is that there can be only one provisioning profile for each application for each realm.

Once a profile is created, its mode—that is, INBOUND, OUTBOUND, or BOTH—cannot be changed by using the modify operation. To change the mode, you must delete, then re-create, the profile.

The Oracle Directory Integration Platform server automatically monitors provisioning profile configuration changes in Oracle Unified Directory or Oracle Internet Directory, including the creation, modification, and deletion of provisioning profiles. For this reason, you do not need to manually enable or disable a provisioning profile.

Note:

For improved security, do not enter a password with the manageProvProfiles command unless prompted for one.

16.3 Tasks and Examples for manageProvProfiles

Use the manageProvProfiles to create, modify, delete, or disable a provisioning profile.

Topics:

16.3.1 Creating a Provisioning Profile

The following example creates a new provisioning profile that makes Portal aware of updates to the user and group information that is maintained in the back-end directory.

Example for Oracle Internet Directory:

manageProvProfiles operation=create ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

Example for Oracle Unified Directory

manageProvProfiles operation=create ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=directory manager" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

16.3.2 Modifying a Provisioning Profile

The following example modifies an existing provisioning profile for the Portal application. It changes the event subscription for the attributes that are provisioned when a user entry is modified.

Example:

manageProvProfiles operation=modify ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" \
subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword,mail,cn,sn)"

16.3.3 Deleting a Provisioning Profile

The following example disables a provisioning profile for the Portal application.

Example:

manageProvProfiles operation=delete ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com"

16.3.4 Disabling a Provisioning Profile

The following example disables a provisioning profile for the Portal application.

Example:

manageProvProfiles operation=disable ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com"

16.3.5 Re-enabling a Disabled Provisioning Profile

The following example re-enables a disabled provisioning profile for the Portal application.

Example:

manageProvProfiles operation=enable ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com"

16.4 Registering Applications for Provisioning

After you install an application and use the manageProvProfiles to create a provisioning profile for it, you must perform the steps described in this section to register the application for provisioning.

Complete the following steps to register the application for provisioning:

  1. Perform the initial provisioning registration and create a provisioning-integration profile. The Oracle Directory Integration Platform Service uses the provisioning-integration profiles to identify provisioning-integrated applications.
  2. Provide the Oracle Directory Integration Platform Service with application- specific attributes, default values, and whether an attribute is mandatory when provisioning users for the application.
  3. Register any plug-ins that are required by the provisioning-integrated application. This can include application-specific plug-ins that the application uses to enforce business policies.

Note:

The Oracle Directory Integration Platform Service does not support instance-level provisioning of applications that support a multiple instance architecture. If you install multiple instances of the same application, the Oracle Directory Integration Platform Service treats each instance as a separate provisioning-integrated application.

When creating users, an administrator can assign user attributes for a specific provisioning-integrated application. Application-specific attributes are stored in back-end directory for each user that is provisioned for an application. For better performance, provisioning-integrated applications usually cache a local copy of user attributes instead of retrieving them from the back-end directory. Applications are notified of user creations, user deletions, and attribute modifications either synchronously with the Data Access Java plug-in or asynchronously with a PL/SQL plug-in.

Registration creates a unique identity for an application in the back-end directory. Oracle applications typically register themselves for provisioning by using the repository APIs located in the repository.jar file, which Oracle Application Server installs by default in the $ORACLE_HOME/jlib directory. In addition to creating an application entry in the back-end directory, the repository APIs can be used to add applications to privileged groups.

For non-Oracle applications that are not capable of using the registration APIs, you can use LDAP commands and LDIF templates to create identities for the applications in the back-end directory. You create a container for the application under cn=Products,cn=OracleContext" or cn=Products, cn=OracleContext, Realm DN. The container where you create an application identity depends on whether the application will be available to users in a single realm or multiple realms. In most cases, you should create an application identity in the cn=Products, cn=OracleContext container so the application is not bound by the identity management policies of a specific back-end directory identity management realm.

You can install multiple instances of the same application. Installing a new instance of a provisioning-integrated application creates a separate entry for the new instance under the application identity container. Although some configuration settings are instance-specific, other settings are shared across multiple instances of the same application. As an example, consider an application that is similar to Oracle Files. You can deploy multiple instances of Oracle Files in an environment where each instance is independent of other instances. You define each instance as a separate provisioning-integrated application. You can also provision users in multiple instances of the application.

When you install the first instance of an application, you must create in Oracle Unified Directory or Oracle Internet Directory the entries shown in the following example. The example creates the application identity in the cn=Products, cn=OracleContext container, and assumes the application name and type are Files-App1 and FILES.

Example 16-1 Oracle Internet Directory

dn: cn=FILES,cn=Products,cn=OracleContext
changetype: add
objectclass: orclContainer

dn: orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext
changetype: add
objectclass: orclApplicationEntityorclappfullname: Files Application Instance 1
userpassword: password
description: This is a test application instance.
protocolInformation: protocol information
orclVersion: 1.0
orclaci: access to entry by group="cn=odisgroup,cn=DIPAdmins,cn=Directory
Integration Platform,cn=Products,cn=OracleContext" (browse,proxy) by
group="cn=User Provisioning Admins,cn=Groups,cn=OracleContext" (browse,proxy)
orclaci: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins,cn=Directory
Integration Platform,cn=Products,cn=OracleContext" (search,read,write,compare) by
group="cn=User Provisioning Admins,cn=Groups,cn=OracleContext"
(search,read,write,compare)

Example 16-2 Oracle Unified Directory

dn: orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext
changetype: add
objectclass: orclApplicationEntity
orclappfullname: Files Application Instance 1
userpassword: password
description: This is a test application instance.
protocolInformation: protocol information
aci:(target="ldap:///orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext"">ldap:///orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext"</a>)(version 3.0; acl "Access by the DIP admin Group"; 
allow (browse,proxy) groupdn="ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory">ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory</a> Integration Platform,cn=Products,cn=OracleContext";)
aci: (target="ldap:///orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext"">ldap:///orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext"</a>)(version 3.0; acl "Access by the User Provisioning Admins group"; 
allow (browse,proxy) groupdn="ldap:///cn=User">ldap:///cn=User</a> Provisioning Admins,cn=Groups,cn=OracleContext";)
aci: (targetattr="*") (version 3.0; acl "Access to attributes of the Application by DIP admin groups group"; allow (search,read,write,compare) groupdn="ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory">ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory</a> Integration Platform,cn=Products,cn=OracleContext";)
aci: (targetattr="*") (version 3.0; acl "Access to attributes of the Application by DIP admin groups group"; allow (search,read,write,compare) 
groupdn="ldap:///cn=User">ldap:///cn=User</a> Provisioning Admins,cn=Groups,cn=OracleContext";)

When you install the second instance of an application, you must create in the back-end directory, the entries shown in the following example. The example also creates the application identity in the cn=Products, cn=OracleContext container, and assumes the application name is Files-App2.

Example 16-3 Oracle Internet Directory

dn: orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext
changetype: add
objectclass: orclApplicationEntityorclappfullname: Files Application Instance 2
userpassword: password
description: This is a test Appliction instance.
protocolInformation: protocol information
orclVersion: 1.0
orclaci: access to entry by group="cn=odisgroup,cn=DIPAdmins,cn=Directory
Integration Platform,cn=Products,cn=OracleContext" (browse,proxy) by
group="cn=User Provisioning Admins,cn=Groups,cn=OracleContext" (browse,proxy)
orclaci: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins,cn=Directory
Integration Platform,cn=Products,cn=OracleContext" (search,read,write,compare) by
group="cn=User Provisioning Admins,cn=Groups,cn=OracleContext"
(search,read,write,compare)

Example 16-4 Oracle Unified Directory

dn: orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext
changetype: add
objectclass: orclApplicationEntity
orclappfullname: Files Application Instance 2
userpassword: password
description: This is a test application instance.
protocolInformation: protocol information
aci: (target="ldap:///orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext"">ldap:///orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext"</a>)(version 3.0; acl "Access by the DIP admin Group"; 
allow (browse,proxy) groupdn="ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory">ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory</a> Integration Platform,cn=Products,cn=OracleContext";)
aci: (target="ldap:///orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext"">ldap:///orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext"</a>)(version 3.0; acl "Access by the User Provisioning Admins group"; 
allow (browse,proxy) groupdn="ldap:///cn=User">ldap:///cn=User</a> Provisioning Admins,cn=Groups,cn=OracleContext";)
aci: (targetattr="*") (version 3.0; acl "Access to attributes of the Application by DIP admin groups group"; allow (search,read,write,compare) groupdn="ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory">ldap:///cn=odisgroup,cn=DIPAdmins,cn=Directory</a> Integration Platform,cn=Products,cn=OracleContext";)
aci: (targetattr="*") (version 3.0; acl "Access to attributes of the Application by DIP admin groups group"; allow (search,read,write,compare) 
groupdn="ldap:///cn=User">ldap:///cn=User</a> Provisioning Admins,cn=Groups,cn=OracleContext";)

After you successfully register a provisioned-integrated application with the back-end directory, you may need to add the application to various privileged groups. Table 16-1 lists common privileged groups in Oracle Unified Directory or Oracle Internet Directory.

Table 16-1 Common Privileged Groups in Oracle Internet Directory

Group Description

OracleDASCreateUser

Create users

OracleDASEditUser

Edit users

OracleDASDeleteUser

Delete users

OracleDASCreateGroup

Create groups

OracleDASEditGroup

Edit groups

OracleDASDeleteGroup

Delete groups

The following LDIF file demonstrates how to grant create user privileges in all realms to the Files-App1 application:

dn:cn=OracleCreateUser,cn=Groups,cn=OracleContext 
changetype: modify
add: uniquemember
uniquemember: orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext

16.5 Understanding How to Configure Application Provisioning Properties

After you register a provisioning-integrated application, you must configure its properties. Each application's provisioning profile maintains its own provisioning configuration properties.

Provisioning-integrated applications use properties to store the following types of metadata:

  • Application identity information

  • Identity realm information

  • Default application provisioning policies

  • Application attribute properties and defaults

  • Application provisioning plug-ins

  • Application event interface information

  • Application event propagation information

Oracle Internet Directory Provisioning supports three versions of provisioning profiles: 1.1, 2.0, and 3.0 and Oracle Unified Directory supports two versions of provisioning profiles: 2.0 and 3.0. Different applications support different provisioning profile versions. For example, many Oracle applications only support version 2.0. However, Oracle Collaboration Suite supports provisioning profile version 3.0. The primary differences between the provisioning profile versions are as follows:

  • Provisioning applications that support provisioning profile versions 1.1 and 2.0 is a single-step process involving the manageProvProfiles utility, which is described in the chapter on Oracle Directory Integration Platform tools in the Oracle Identity Management User Reference. However, provisioning applications that support provisioning profile version 3.0 is a multiple-step process, which is described in the centralized user provisioning Java API reference chapter of Oracle Identity Management.

  • Oracle Directory Integration Platform Provisioning only maintains user provisioning status for applications that support provisioning profile version 3.0.

    See Also:

    The centralized user provisioning Java API reference chapter of Oracle Identity Management

16.6 manageProvProfiles Command

You can create a provisioning integration profile using the manageProvProfiles command located in the ORACLE_HOME/bin directory.

Syntax for manageProvProfiles

manageProvProfiles operation=[create|modify] ldap_host=backend_hostname ldap_port=port 
ldap_user_dn="bindDN"
[profile_mode=INBOUND|OUTBOUND|BOTH]
application_dn="DN" application_type=type [application_name=name] 
[application_display_name=display name] organization_dn=DN 
[application_isdasvisible=TRUE|FALSE] [manage_application_defaults=TRUE|FALSE] 
[enable_bootstrap=TRUE|FALSE]  [user_data_location=DN] 
[default_provisioning_policy=PROVISIONING_REQUIRED|PROVISIONING_NOT_REQUIRED] 
interface_name=SCHEMA.PACKAGE [interface_type=PLSQL|JAVA] 
interface_version=1.1|2.0|3.0] 
schedule=number_seconds lastchangenumber=number 
max_prov_failure_limit=number  
max_events_per_schedule=number max_events_per_invocation=number 
event_mapping_rules="OBJECT_TYPE:FILTER:DOMAIN" 
event_permitted_operations="OBJECT:DOMAIN:OPERATION(attributes,...)" 
event_subscription="USER|GROUP:DOMAIN:OPERATION(attributes,...)" 
max_events_per_schedule=number max_retries=number profile_group=number
profile_status=ENABLED | DISABLED profile_debug=debug_level 

manageProvProfiles {operation=enable|disable|delete|status|reset} 
application_dn=DN [organization_dn=DN] [ldap_host=backend_hostname] [ldap_port=port]
[ldap_user_dn=bindDN] [profile_debug=debug_level]

Arguments for manageProvProfiles

operation=create | modify | enable | disable | delete | status | reset

Required. The operation to perform using manageProvProfiles. You can only perform one operation at a time. The operations are:

  • create—Creates a new provisioning profile.

  • modify—Modifies the given properties of an existing provisioning profile.

  • enable—Enables a provisioning profile.

  • disable—Disables a provisioning profile.

  • delete—Deletes a provisioning profile.

  • status—Shows the current status of a given provisioning profile.

  • reset—Clears all errors for a provisioning profile.

ldap_host=backend_hostname

Optional. The host name of the Oracle Unified Directory or Oracle Internet Directory server. If not provided then the name of the local host is used.

ldap_port=port

Optional. The LDAP listening port of the back-end directory. The default port for Oracle Unified Directory or Oracle Internet Directory is 389.

Required. The DN of the superuser or a user that has sufficient permissions to perform provisioning subscription operations. The default value for Oracle Unified Directory is “cn=directory manager“and for Oracle Internet Directory is "cn=orcladmin“.

profile_mode=OUTBOUND | INBOUND | BOTH

Optional for the create operation only. The direction of the provisioning events. The default is OUTBOUND (data is provisioned from Oracle Unified Directory or Oracle Internet Directory to the application).

application_dn=DN

Required. The distinguished name of the application to which the provisioning subscription belongs. The combination of the application DN and organization DN uniquely identifies a provisioning profile. For example, here is the application DN for Portal:

"orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext"

application_type=type

Required. The type of application being provisioned.

application_name=name

Optional. The name of the application being provisioned. If not provided, defaults to the distinguished name assigned to application_dn.

application_display_name=name

Optional. The display name of the application being provisioned. If not provided, defaults to the value assigned to application_name.

organization_dn=DN

Optional. If not provided, defaults to the default identity management realm. The distinguished name of the organization to which the provisioning subscription belongs, for example "dc=company,dc=com". The combination of the application DN and organization DN uniquely identifies a provisioning profile.

application_isdasvisible=TRUE | FALSE

Optional. Determines whether the application is visible as a provisioning-integrated application in the Oracle Internet Directory. The default value is TRUE.

Note:

This argument is for Oracle Delegated Administration Services 10g Releases (10.1.4.x).

manage_application_default=TRUE | FALSE

Optional. Determines whether the Oracle Internet Directory manages the application's default values. The default value is TRUE.

Note:

This argument is for Oracle Delegated Administration Services 10g Releases (10.1.4.x).

enable_bootstrap=TRUE | FALSE

Optional. Indicates whether the application should receive provisioning events for users that existed in the back-end directory before creating the application's provisioning integration profile. The default value is FALSE.

user_data_location=DN

Optional. Identifies the DN of the container in which to store application-specific user information.

default_provisioning_policy=PROVISIONING_REQUIRED | PROVISIONING_NOT_REQUIRED

Optional. Specifies the application's default provisioning policy. The default value is PROVISIONING_REQUIRED.

interface_name=SCHEMA.PACKAGE

Required for create or modify operations. The database schema name for the PLSQL package. The format of the value is schema.package_name, for example here is the schema and PLSQL package information for Portal: 

interface_name=PORTAL.WWSEC_OID_SYNC

interface_version=1.1 | 2.0 | 3.0

The version of the interface protocol. Allowed values are 1.1, 2.0, or 3.0. The default value is 2.0.

Oracle Internet Directory supports versions 1.1, 2.0, or 3.0.

Oracle Unified Directory support versions 2.0 and 3.0.

interface_type=PLSQL | JAVA

Optional. The type of interface to which events will be propagated. The default is PLSQL.

Note:

For JAVA type, only interface protocol version 3.0 is supported.

schedule=number_seconds

Optional for create and modify operations only. The number of seconds between executions of this profile. The default is 3600, which means the profile is scheduled to be executed every hour.

lastchangenumber=number

Optional for create and modify operations on OUTBOUND events only. The last change number in the back-end directory after which all qualifying events should be provisioned to the application. Defaults to the latest current change number.

Note:

To update the lastchangenumber argument, you must perform the following steps:

  1. Stop Oracle Directory Integration Platform using Oracle Enterprise Manager Fusion Middleware Control. See Stopping Oracle Directory Integration Platform with Fusion Middleware Control.

  2. Update the last change number of the provisioning profile using the manageProvProfiles command.

  3. Start Oracle Directory Integration Platform using Oracle Enterprise Manager Fusion Middleware Control. See Starting Oracle Directory Integration Platform with Fusion Middleware Control.

If you do not set the lastchangenumber and restart Oracle Directory Integration Platform, then the lastchangenumber will be overwritten by an older (lower) value from the cache.

max_prov_failure_limit=number

Optional. Determines the number of times the Oracle Provisioning System attempts to provision a user. The default is 1.

max_events_per_schedule=number

Optional for create and modify operations only. The maximum number of events that the Oracle Directory Integration Platform server sends to an application during one execution of a provisioning profile. The default is 100.

max_events_per_invocation=number

Optional for create and modify operations only. The maximum number of events that can be packaged and sent to a target in one invocation of the interface.

event_mapping_rules="OBJECT_TYPE:FILTER:DOMAIN"

Required for create and modify operations on INBOUND events only. This rule maps the object type received from the application (using an optional filter condition) to a domain in the back-end directory. A provisioning profile can have multiple mapping rules defined.

The following example shows two mapping rules. The first rule shows that an employee object (EMP) whose locality attribute equals America (l=AMERICA) should be mapped to the domain l=AMER,cn=users,dc=company,dc=com. The second rule shows that an employee object (EMP) should be mapped to the domain cn=users,dc=company,dc=com (no filter conditions). 

event_mapping_rules="EMP:l=AMERICA:l=AMER,cn=users,dc=company,dc=com"
event_mapping_rules="EMP::cn=users,dc=company,dc=com"

event_permitted_operations="OBJECT:DOMAIN:OPERATION(attributes,...)

Required for create and modify operations on INBOUND events only. This property is used to define the types of events that the application is allowed to send to the Oracle Directory Integration Platform service. A provisioning profile can have multiple permitted operations defined.

For example, if you wanted to permit the application to send events whenever a user object was added or deleted, or when certain attributes were modified, you would have three permitted operations such as this:

event_permitted_operations="USER:dc=mycompany,dc=com:ADD(*)"
event_permitted_operations="USER:dc=mycompany,dc=com:MODIFY(cn,sn,mail,password)"
event_permitted_operations="USER:dc=mycompany,dc=com:DELETE(*)"

event_subscription="USER | GROUP:DOMAIN:OPERATION(attributes,...)"

Required for create and modify operations on OUTBOUND events only. This property is used to define the types of events that the Oracle Directory Integration Platform service should send to the application. A provisioning profile can have multiple event subscriptions defined.

For example, if you wanted the directory integration server to send events to the application whenever a user or group object was added or deleted, you would have four event subscriptions such as this:

event_subscription="GROUP:dc=mycompany,dc=com:ADD(*)"
event_subscription="GROUP:dc=mycompany,dc=com:DELETE(*)"
event_subscription="USER:dc=mycompany,dc=com:ADD(*)"
event_subscription="USER:dc=mycompany,dc=com:DELETE(*)"

max_retries=number

Optional for create and modify operations only. The number of times a failed event should be retried. The default is 5.

profile_group=number

Required for create and modify operations only. The group number of the profile. Default is "DEFAULT". This is required to address scalability issues when different Oracle Directory Integration Platform server instances will be used to execute different selected groups.

profile_status=ENABLED | DISABLED

Required for the create operation only. Determines whether the profile is enabled or disabled. The default is ENABLED.

profile_debug=debug_level

Required. The debug level for the profile.

Note:

For security reasons, the ldap_user_password and interface_connect_info arguments are no longer accepted on the command line.