This chapter explains how to deploy provisioning-integrated applications with the Oracle Provisioning Service. It contains these topics:
To deploy provisioning-integrated applications with the Oracle Provisioning Service, you perform these general steps:
Install the back-end directory and Oracle Directory Integration Platform.
Notes:
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 Section 5.2.1, "Task 1: Installing Oracle Unified Directory".
Load user information into Oracle Internet Directory or Oracle Unified Directory.
Start the Oracle Directory Integration Platform.
Install the applications and use the manageProvProfiles
to create a provisioning profile for each application. Refer to "Managing Provisioning Profiles Using manageProvProfiles" for more information.
Configure application registration by following the procedures described in "Registering Applications for Provisioning".
Configure application provisioning by following the procedures described in "Configuring Application Provisioning Properties".
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:
"Monitoring Oracle Internet Directory" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
"Monitoring Oracle Unified Directory" in the Oracle® Fusion Middleware Administering Oracle Unified Directory.
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.
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 themanageProvProfiles
command unless prompted for one.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]
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.
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.
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).
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"
Required. The type of application being provisioned.
Optional. The name of the application being provisioned. If not provided, defaults to the distinguished name assigned to application_dn
.
Optional. The display name of the application being provisioned. If not provided, defaults to the value assigned to application_name
.
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 Provisioning Console. 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 Provisioning Console 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).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
.
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
.
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
.
Optional. The type of interface to which events will be propagated. The default is PLSQL
.
Note:
ForJAVA
type, only interface protocol version 3.0
is supported.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.
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.
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(*)"
Optional for create
and modify
operations only. The number of times a failed event should be retried. The default is 5
.
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
.
Required. The debug level for the profile.
Note:
For security reasons, theldap_user_password
and interface_connect_info
arguments are no longer accepted on the command line.You can perform the following tasks using manageProvProfiles
:
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
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.
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)"
The following example disables a provisioning profile for the Portal application.
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"
The following example disables a provisioning profile for the Portal application.
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"
After you install an application and use the manageProvProfiles
to create a provisioning profile for it, you must perform the following steps to register the application for provisioning:
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.
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.
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
.
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)
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
.
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)
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 |
---|---|
|
Create users |
|
Edit users |
|
Delete users |
|
Create groups |
|
Edit groups |
|
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
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 Fusion Middleware Application Developer's Guide for 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 Fusion Middleware Application Developer's Guide for Oracle Identity Management