|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
 Previous |
 Next |
|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
|
Previous |
Next |
This section discusses the organization of user profiles in Oracle Internet Directory. It contains these topics:
The Oracle Provisioning Service relies on user profiles in the DIT that consist of attributes containing personal information and preferences for the various applications in which the user is provisioned. These user attributes for the Oracle Provisioning Service can be categorized as follows:
Base attributes that are available for every user entry
Application-specific attributes that are only available if a user is provisioned in an application
Base user attributes primarily belong to standard LDAP object classes such as organizationalPerson and inetOrgPerson, and consist of personal details that include first name, last name, given name, e-mail address, and telephone numbers. Base user attributes also consist of Oracle application-specific attributes that belong to the orclUserV2 auxilliary class.
Oracle Internet Directory is the primary repository for both base attributes and application-specific attributes. Both types of attributes are stored in each user's profile. However, an application may cache user attributes that are updated with the provisioning event notification service.As shown in Figure 12-6, user attributes are stored in two locations within the DIT. Base user entries, which include attributes belonging to inetorgperson and orcluserv2, are stored under cn=users,Realm DN. The provisioning status of each user entry is also stored in the base user entry. Application-specific attributes reside in separate entries in the application container. The LDAP schema relating to the application-specific attribute definitions and the object classes are created during the install or upgrade process. Application-specific attributes are qualified by an auxiliary object class, which will enable searching for the application-specific user properties of the entry. By default, application-specific entries are stored as orclOwnerGUID=GUID of the Base User under the cn=User Properties, cn=Application Type, cn=Products,cn=OracleContext, Realm DN container.Some applications manage their own application attributes and implement the Data Access Java plug-in, which is described in "Understanding Provisioning Concepts". The Oracle Provisioning Service invokes this plug-in whenever the base user attributes or application-specific attributes are modified.
Figure 12-6 Base User and Application-Specific Attributes
This section discusses the user provisioning statuses in Oracle Internet Directory. It contains these topics:
The Oracle Provisioning Service records a user's provisioning status in Oracle Internet Directory for each provisioning-integrated application. Provisioning status can be set by the Oracle directory integration and provisioning server, with bulk provisioning using the Directory Integration and Provisioning Assistant, or by a provisioning-integrated application. Table 12-1 lists the provisioning statuses.
Table 12-1 Provisioning Statuses in Oracle Internet Directory
| Internal Status | GUI Status | Description |
|---|---|---|
|
Provisioning Statuses |
|
|
|
|
Pending |
Provisioning required. This status is selected by an administrator or set according to an application's provisioning policies. Note that this status does determine whether a user has been provisioned. |
|
|
In Progress |
Provisioning in progress. The user can access the application when this is the current status. if the application performs provisioning at scheduled intervals. The application may also provision the user on-demand. |
|
|
Successful |
Provisioning successful. This status is updated automatically by the Oracle directory integration and provisioning server, with bulk provisioning using the Directory Integration and Provisioning Assistant, or a provisioning-integrated application. |
|
|
Not Requested |
Provisioning not required. This status is selected by an administrator or set according to an application's provisioning policies. Note that this status does determine whether a user will not be provisioned. |
|
|
Failed |
Provisioning failed. This status is updated automatically by the Oracle directory integration and provisioning server, with bulk provisioning using the Directory Integration and Provisioning Assistant, or a provisioning-integrated application. The user cannot access the application when this is the current status. |
|
Deprovisioning Statuses |
|
|
|
|
Pending de-provisioning |
Deprovisioning required. The user is still provisioned when this is the current status. |
|
|
De-provisioning In Progress |
Deprovisioning in progress. |
|
|
Successfully de-provisioned |
Deprovisioning successful. The user cannot access the application when this is the current status. |
|
|
Failed de-provisioning |
Deprovisioning failed. The user is still provisioned when this is the current status. |
|
Upgrade Statuses |
|
|
|
|
Pending Upgrade |
Provisioning upgrade pending. |
|
|
Upgrade In Progress |
Provisioning upgrade in progress. |
|
|
Upgrade Failed |
Provisioning upgrade failed. |
The provisioning status for each application is stored in the orclUserApplnProvStatus attribute in a user entry. This attribute is indexed in Oracle Internet Directory and searchable. A subtyped orclUserApplnProvStatus attribute is created for each provisioning-integrated application. For example, the following statements store a user's provisioning statuses for an e-mail application and a scheduling application. The user's provisioning status for the e-mail application is PROVISIONING_SUCCESS while his or her provisioning status for the scheduling application is PROVISIONING_FAILURE.
orclUserApplnProvStatus;CORP-MAIL_E-MAIL:PROVISIONING_SUCCESS orclUserApplnProvStatus;CORP-SCHEDULE_CALENDAR:PROVISIONING_FAILURE
Additional information about a user's provisioning status in an application is stored in the orclUserApplnProvStatusDesc attribute and the provisioning failure account for each application is stored in the orclUserApplnProvFailureCount attribute. As with the orclUserApplnProvStatus attribute, separate orclUserApplnProvStatusDesc and orclUserApplnProvFailureCount attributes are created for each provisioning-integrated application. The format for the orclUserApplnProvStatusDesc attribute is the same as the orclUserApplnProvStatus attribute, except that a timestamp and descriptive information are appended to the application name and type, as follows:
orclUserApplnProvStatusDesc;CORP-MAIL_E-MAIL:20040101010101^Missing employee ID
The orclUserApplnProvStatus, orclUserApplnProvStatusDesc, and orclUserApplnProvFailureCount attributes are contained in the orclUserProvStatus object class as optional attributes.
Table 12-2 lists the valid provisioning status transitions.
Table 12-2 Valid Provisioning Status Transitions in Oracle Internet Directory
| Internal Status | GUI Status | Valid Transition From |
|---|---|---|
|
Provisioning Statuses |
|
|
|
|
Pending |
Initial missing state
|
|
|
In Progress |
|
|
|
Successful |
|
|
|
Not Requested |
Initial missing state |
|
|
Failed |
|
|
Deprovisioning Statuses |
|
|
|
|
Pending de-provisioning |
|
|
|
De-provisioning In Progress |
|
|
|
Successfully de-provisioned |
|
|
|
Failed de-provisioning |
|
Figure 12-7 illustrates the valid provisioning status transitions.
Figure 12-7 Valid Provisioning Status Transitions
In Oracle Identity Management 10g Release 2 (10.1.2), a user entry can be physically represented in Oracle Internet Directory by multiple LDAP entries. In addition to the base user entry, separate LDAP entries may exist for each provisioning-integrated application.
In a typical upgrade of Oracle Identity Management, multiple middle tiers are not upgraded simultaneously. This means that following an Oracle Identity Management upgrade, middle tiers from a previous version may need to run in parallel with middle tiers from the upgraded version. When a middle tier is upgraded, all of a user's application-specific data that was previously stored in the application metadata repository, will be migrated on-demand. For each user entry that is present in Oracle Internet Directory prior to the upgrade, the Oracle directory integration and provisioning server will initiate a new user event and assign a provisioning status of PENDING_UPGRADE to the user entry. If a new user entry is created from an older middle tier or some unsupported route, such as an existing application using the standard LDAP SDK, the provisioning status attribute will be missing. In this case, the Oracle directory integration and provisioning server also initiates a new user event and assign a provisioning status of PENDING_UPGRADE to the user entry.
Once a provisioning-integrated application receives the event, it will return a response to the Oracle directory integration and provisioning server indicating whether the user is provisioned or not provisioned. The Oracle directory integration and provisioning server then updates the provisioning status in the user entry accordingly.
If a new user entry created with the Provisioning Console or through synchronization with an external data source does not contain enough information to provision the user in a particular application, provisioning may fail. Provisioning can also fail for a variety of other reasons. The Oracle Provisioning Service identifies user provisioning failures as exceptions. Whenever an application responds to a USER_ADD event with a failure status, the Oracle directory integration and provisioning server will change the user's provisioning status to PROVISIONING_FAILURE. The directory integration and provisioning server will then send notifications to the applications of the failed cases also just like a new user case. This will serve as a retry for the provisioning request. The provisioning status of a user displays in the Provisioning Console. The administrator can make the necessary changes to fix the problem and the provisioning would get retried automatically. This will result in invocation of the data access plug in if the provisioning is synchronous. However, an event will be propagated if the provisioning is asynchronous.This sequence of steps would be retried again as long as the user is not provisioned successfully.
