PK j?oa,mimetypeapplication/epub+zipPKj?iTunesMetadata.plistj artistName Oracle Corporation book-info cover-image-hash 810047539 cover-image-path OEBPS/dcommon/oracle-small.JPG package-file-hash 785011545 publisher-unique-id E14316-07 unique-id 715224490 genre Oracle Documentation itemName Oracle® Fusion Middleware User's Guide for Oracle Identity Manager, 11g Release 1 (11.1.1) releaseDate 2011-08-25T16:44:13Z year 2011 PKppojPKj?META-INF/container.xml PKYuPKj?OEBPS/attestation.htm Managing Attestation Processes

19 Managing Attestation Processes

This chapter is divided into the following sections:

19.1 About Attestation

Attestation enables users designated as reviewers to be notified of reports they must review. These reports describe entitlements of other users. A reviewer can attest to the accuracy of these entitlements by providing a response. The attestation action, along with the response the reviewer provides, any associated comments, and an audit view of the data that the reviewer views and attests to, is tracked and audited to provide a complete trail of accountability. In Oracle Identity Manager, this process is known as an attestation task.

In Oracle Identity Manager, attestation is supported through the definition of scheduled attestation processes. An attestation process is not the same as an Oracle Identity Manager workflow. It is implemented as a configurable business process in Oracle Identity Manager, and it creates an attestation task for a user. The user acts as a reviewer, and must complete this process to provide correct audit information.

Tracking of attestation activity for a provisioned resource instance is done through tasks in the provisioning processes of resource objects. You can initiate workflow activity based on attestation actions. Additional activities to be started, and a workflow that can be modeled in the process definition form or workflow designer can be initiated, based on an initial attestation action. This is possible due to attestation subflows in the provisioning processes defined in Oracle Identity Manager.

Attestation activity can be initiated on a periodic basis or when required.

A reviewer can delegate specific entitlements in an attestation task to another user for review. This action creates another attestation task that is assigned to the delegated user.

This section discusses the following topics:

19.1.1 Definition of an Attestation Process

An attestation process is the mechanism by which an attestation task is set up. Input that an attestation process requires includes information about how to define the components that constitute the attestation task and how to associate the attestation task with a schedule at which the task must be run. This definition is also the basis on which the attestation task can be initiated when required. An attestation process definition includes:

A single attestation process could result in multiple attestation tasks, if that process defines a set of reviewers. In such a case, the process would result in one attestation task for each reviewer in the set.

19.1.2 Components of Attestation Tasks

The basic purpose of the attestation process is to set up an attestation task in Oracle Identity Manager. The attestation task is displayed in the Attestation tab of the TaskList in the Oracle Identity Manager Self Service, where you can manage this task or delegate it to someone else to manage. The following are the basic components of an attestation task:

19.1.5 Attestation Lifecycle Process

The following is a description of the attestation lifecycle in Oracle Identity Manager.

19.1.5.1 Stage 1: Creation of an Attestation Task

This stage starts when an attestation process is run. Figure 19-2 describes the workflow involved in this stage.

When the attestation process is run, it first creates a corresponding attestation process instance. It then identifies the reviewers for this run of the process. In most cases, there is only one reviewer. There can even be a set of reviewers.

Whenever an invalid reviewer is found, a new reviewer is fetched from the process owner group. Oracle Identity Manager will select, if possible, a member of the process owner group who has not yet been used as a reviewer for this attestation request. If this is not possible, then Oracle Identity Manager will select a member of the process owner group who has already been selected to act as a reviewer. If Oracle Identity Manager cannot find a member of the process owner group, then it will assign XELSYSADM as the reviewer for the attestation task.

For each valid reviewer, the process calculates all the user entitlements that the reviewer must attest to as part of that task, as determined by the attestation scope defined in the process. The process then adds a reference and any related information regarding those user entitlements to the attestation data of the task. It also adds the number of entitlements covered by that task to the statistical field for the total number of entitlements identified for attestation in the process instance. The process then sends an e-mail message to the reviewer. It also sends e-mail to process owners about the reviewers with no e-mail address defined.

At the end of this stage, all the attestation tasks are in the attestation inboxes of the reviewers.

19.1.5.3 Stage 3: Processing a Submitted Attestation Task

The Attestation Task is marked as Submitted. At this point the attestation task is frozen, and cannot be acted on further. For each entitlement in the attestation task, the response is examined by the system. If the response is to either certify or reject, then the provisioned resource instance corresponding to that entitlement is updated accordingly. At the provisioned resource instance level, the last attestation result, the time at which last attestation occurred, and who the reviewer was are recorded. If the response is to decline or delegate, then the attestation detail at the provisioned resource level is not changed.

The User Attestation Event Occurred task is inserted into the provisioning process of the resource instance. This starts any attestation-driven workflows that may have been defined. Any comments are saved to the notes field of the task.

The attestation entitlement detail in the task is marked as Response Submitted. Figure 19-4 shows the flow of events after the attestation task response is submitted.

The following statistics are updated on the process instance:

  • Number of entitlements certified

  • Number of entitlements rejected

  • Number of entitlements declined

  • Number of entitlements delegated

After all entitlements are covered, a subflow for follow-up action is initiated. In this flow, the process examines if the response for any of the entitlements in the task was declined. If there were any such entitlements, then the process sends e-mail to the Process Owner outlining the details of the decline action.

Next, the process examines if the response for any of the entitlements in the task was delegated. If there were any such entitlements, then the process identifies all the users that the reviewer selected as delegates and creates an attestation task for each. Each attestation task is only for the entitlements that the reviewer delegated to the user. The delegated user receives e-mail notification about the delegation.

After all the delegated attestation tasks are created, the subflow is completed and it merges back into the main flow. Figure 19-5 shows the flow of events of the follow-up action subflow.

With the follow-up subflow complete, the attestation task is marked as Complete.

19.1.9 Attestation E-Mail

As part of the attestation processes, the Attestation Engine sends out e-mail to various interested parties. To make the e-mail configurable with respect to the content, they are made available as e-mail templates of the General type in Oracle Identity Manager Email Definition store. For context-sensitivity, the e-mail contain a set of variables that can be replaced with the required values.

19.1.9.3 Notify Process Owner About Declined Attestation Entitlements

The Notify Declined Attestation Entitlements template is used to build the e-mail to send to process owners notifying them of any declined entitlement attestations.

19.1.9.4 Notify Process Owner About Reviewers with No E-Mail Defined

The Attestation Reviewers With No Email Defined template is used to build the e-mail to send to process owners notifying them of reviewers for whom there is no e-mail address defined.

19.2 Attestation Process Configuration

A menu item in Oracle Identity Manager Administrative and User Console provides access to the Attestation Process Configuration pages. Oracle Identity Manager administrators can use these pages to:

  • Define new attestation processes.

  • Manage existing processes.

  • Initiate ad-hoc attestation processes.

19.3 Creating Attestation Processes


Note:

Oracle Identity Manager Permission model applies to the procedure described in this section. This model restricts any list of targets (for example, users) to only those targets for which the logged-in user has read access.

To create an attestation process:

  1. In the Welcome page of Oracle Identity Manager Advanced Administration, under Attestation Configuration list, select Create.

    The Step1: Define Process page is displayed.

  2. Enter values for the fields described in the following table, and then click Continue:

    FieldDescription
    NameA unique name for the attestation process. The name must be unique across system administrator and deleted attestation processes.
    CodeAn identifying code (up to 32 characters) for the process. The code must be unique across system administrator and deleted attestation processes.

    Note: A code enhances the identification of the attestation process definition. However, if you do not specify a value in the Code field, then the attestation process is identified by the unique name.

    DescriptionDetailed description of the attestation process.

  3. On the Step 2: Define User Scope page:

    1. Select an attribute from the Attribute list. The Attribute list displays the user attributes given in the FormMetaData.xml file and the user-defined attributes from the user form. The attribute that you select is used to specify the criteria that must be met by users on whom the attestation process is applied.

    2. From the Condition list, select a condition. The Condition list of values will change based on the type of attribute selected. For example, if you select User ID in the Attribute field, then the conditions displayed are Contains, Does Not Contain, Is Exactly, and Is Not Exactly. If you select the Start Date attribute, then the conditions displayed are Before, After, and Between.

    3. In the Value field, enter a value for the user attribute.

    4. Select the Recursive option. The Recursive check box is used for the entities for which you want to include the child entities while defining user scope. For example, if you select Organization in the user scope and then select Recursive, then the operation also includes all the suborganizations.

    5. Click Add to add a new row to the user scope table, and click Continue. If you add multiple rows to the user scope table, then the attestation process will apply only to users who match all of the attribute conditions in the user scope.

  4. On the Step 3: Define Resource Scope page, select a resource for the attestation process as follows:

    1. From the Attribute list, select one of the resource attributes listed in the following table:

      AttributeExpressionDescription
      NameFull text or wildcardThe name of the resource.
      TypeLookup values with the option to select all or a subsetThe type of resource.
      Resource Audit ObjectivesLookup values with the option to select all or a subsetThe audit objectives assigned for a resource, which is provisioned. For example, whether or not the resource is financially significant.

      For more information about Resource Audit Objectives, see "Viewing Resource Details" on page 12-1.

      Administrator User GroupsLookup values with the option to select all or a subsetThe user groups that have administrative permissions for a resource.
      Authorized User GroupsLookup values with the option to select all or a subsetThe user groups that are authorizers or approvers for the resources.
      Resource StatusFull text or wildcardThe status displayed when a resource is provisioned to a user, such as Certify, Reject, Open, or Closed.

    2. From the Condition list, select a search condition.

    3. In the Value field, enter a value for the resource attribute.

    4. Click Add to add a new row to the resource scope table, and then click Continue. If you add multiple rows to the resource scope table, then the attestation process will apply only to resources that match all of the attribute conditions in the resource scope.

  5. On the Step 4: Define Administration Details page, define the reviewer to attest data, the attestation process schedule, grace period, and the process owner by performing the following steps:

    1. From the Reviewer list, select the type of reviewer for the attestation process, such as a single specific user, role member, or resource administrator. Then, select the reviewer from the adjoining lookup field.

      When you select "Role Member" as the reviewer type, you must select a role for reviewing a particular attestation task. Once the attestation task has been created and run, it will be assigned to the role you selected based on the following conditions:

      - All users who are not in Deleted and Disabled state will be assigned the attestation task.

      - If the reviewer in that role happens to be the beneficiary as well, then that user will not be assigned the attestation task.

      - If after the above checks, there is no eligible user in that role, then the task is assigned to all the users in the System Administrator role.

    2. Specify the attestation process schedule to run the attestation process once or repeatedly after a specific number of days, months, or years.

    3. Specify the grace period, the number of days in which each reviewer must respond to any attestation task that is generated by this attestation process.

    4. In the Starting on field, specify a start date for the attestation process.

    5. In the Process owner group lookup field, specify a group that is the process owner for the attestation process.

    6. If you want the process owner to be notified by e-mail if the reviewer refuses the attestation process, select Email process owner if reviewer refuses attestation request. Then, click Continue.

  6. On the Step 5: Verify Info page, review the details of the attestation process, and then click Create Process.

    You are redirected to a page with a message that you have successfully created an attestation process definition. Clicking the process name takes you to the Attestation Process Detail page. To create another attestation process, click Create Another Attestation Process Definition.

    The Attestation Process Detail page is described in the "Managing Attestation Processes" section.

19.4 Managing Attestation Processes

To manage attestation processes:

  1. In the Welcome page, click Manage Attestation Process, and then click Manage. The Manage Attestation Process page is displayed.

  2. On the Manage Attestation Process page, enter the search criteria for the attestation process you want to manage. You can search by attestation process name, process code, reviewer type, or process owner. After you enter your search criteria, click Search. The Attestation Process Details page is displayed with the attestation processes that match your search criteria. The attestation processes displayed are the ones that the logged-in administrator is allowed to view based on permissions, or by virtue of being a member of the Process Owner group. This page does not show any deleted processes. The columns displayed on the page are listed in the following table:

    ColumnDescription
    NamesSpecifies the name of the process.
    CodeSpecifies the attestation process code.
    DescriptionSpecifies a description for the process.
    StatusIndicates whether the attestation process is active or system administrator.
    TypeSpecifies the type of resource.
    User ScopeSpecifies the scope of the user who will be a part of the attestation process.
    Resource ScopeSpecifies the resources that are within the scope of the attestation process.
    Reviewer TypeIndicates the type of the reviewer.
    Reviewer NameIndicates the name of the reviewer.
    ScheduleIndicates if the process is scheduled to run only once, or on a daily, monthly, or yearly basis.
    Last StartSpecifies the last time an attestation process was run.
    Next StartSpecifies when the process is scheduled to run next.
    Process Owner GroupIndicates the process owner group. In addition, it specifies whether or not the process owner will be notified by e-mail if the reviewer refuses the attestation request.
    Last CompletionSpecifies the last time an instance of this process was completed.

The rest of this section discusses the following topics:

19.5 Using the Attestation Dashboard

You use the Attestation Dashboard to view the state of attestation processes that are owned by any group of which you are a member.

To use the Attestation Dashboard, in the Welcome page of the Advanced Administration, click Launch Attestation Dashboard under Event Management. Alternatively, click the Event Management tab, and from the Attestation list, select Attestation Dashboard. The Attestation Dashboard page displays a table listing the state of attestation processes that are owned by any group of which you are a member. The Attestation Dashboard table contains the columns listed in the following table:

ColumnDescription
Process CodeThe attestation process code.
Process NameThe name of the process. The Attestation Process Detail page is displayed when the link for an attestation process name is clicked.
Last CompletionThe date and time when the instance was run before the latest one was completed. If it does not exist, then the value must be None. It is a link that takes the user to the Attestation Request Detail page for the required Attestation Request.
Current Request DateThe date and time when the last instance of this Process was run. If it has never been run, then the value is New. It is a link that takes the user to the Attestation Request Detail page for the required Attestation Request.
Current CompletionThe date and time when the last instance run was completed. If it has not been completed, then the value is Pending.
Total RecordsThe total number of entitlements identified for attestation and covered by an attestation task as part of the last process instance.
CertifiedThe number of entitlements certified in the last attestation process instance.
RejectedThe number of entitlements rejected in the last attestation process instance.
OpenAll the open records for which no responses have been provided by the reviewers.

19.5.1 Viewing Attestation Request Details

You can access the drill-down page from the Attestation Dashboard page. The drill-down page displays the attestation details of all entitlements covered by a particular run of the Attestation Process.

To view attestation request details:

  1. Click the link for the Last Completion or Current Request Page fields listed in the table on the Attestation Dashboard page.

    The Attestation Request Detail page displays the request details for the selected attestation process, along with a table that contains the following columns:

    ColumnDescription
    UserUser whose entitlement is being attested. The data is displayed as a link. When you click the link, the user profile page is displayed with the user details for the attestation date.
    ResourceResource that is the basis for the entitlement being attested. The data is displayed as a link. When you click the link, a page is displayed with the process form data of the entitlement for the attestation date.
    Descriptive DataDescription of the provisioned resource instance.
    CommentsComment or status of the request. The value can be one of the following:
    • Certify

    • Reject

    • Open

    • Closed

    Attestation ResultLast response that was provided for the attestation.
    ReviewerUser who provided the response. The data is displayed as a link. When you click the link, the user profile page is displayed with the current user details.
    Delegation PathIf the attestation of an entitlement goes through any delegation, then you can use the View link in this column to see the Delegation Path Detail page. If no delegation has taken place, then None is displayed.
    CommentsReviewer comments. Long comments are truncated, and tooltips are used to show the full text of the comments.

  2. Any attestation requests that require delegation include a link in the Delegation Path column.

    Clicking the link displays a Delegation Path page that provides information about the delegation path of the attestation request.

    The Data Attested field shows details about the entitlement being attested. It constructs the value by putting together user information, the resource name, and descriptive data in the following format:

    User_First_Name User_Last_Name [User_ID] - Resource_Name - Descriptive_Data
    

    The table on the Delegation Path page contains the following fields:

    ColumnDescription
    ReviewerThe reviewer to whom the entitlement for attestation is assigned. The data is displayed as a link. When you click the link, the current user profile data is displayed.
    Attestation ResultAction supplied by the reviewer. Except for the first record, the value is always Delegated.
    Attestation DateThe date and time of the attestation response of the reviewer.
    CommentsReviewer comments. Long comments are truncated, and tooltips are used to show the full text of the comments.

PK<4OOPKj?OEBPS/partpage_user.htm Oracle Identity Manager Self Service

Part II

Oracle Identity Manager Self Service

This part describes the various self service tasks that you can perform in Oracle Identity Manager.

It contains the following chapters:

PKEPKj?OEBPS/index.htm Index

Index

A  B  C  D  E  F  G  H  I  L  M  O  P  R  S  T  U  V  W  X 

A

access policies, 16, 16, 16
creating, 16.3
features, 16.2
managing, 16.4, 16.4
Access Policy Wizard, 3.1.3.1
account reconciliation, 4.2.1.1.2
Adapter Factory, 1.1.5, 2.1.9, 2.2.2.2.3
Administration Console
features, 3.1.3.1
Administrative and User Console, 3.1
customizable components, 3.1.4
customization, 3.1.4
login, 7.1.1
registering, 7.1.2
registration request, 7.1.2
tracking registration request, 7.1.3
administrative features, 3.2.1
Advanced Administration, 3.1.3
advanced search
approval policies, 18.3
authorization policies, 15.2.1.2
conjunction operators, 11.3.1.2.3
organizations, 13.2.1.2
page, 11.3.1.2.1
request templates, 17.2
requests, 14.2.1
results, 11.3.1.2.5
roles, 12.5.2.2.2
search comparators, 11.3.1.2.2
searchable attributes, 11.3.1.2.4
users, 11.3.1.2, 11.3.1.2.6
API services, 2.2.2.1
approval policies
advanced search, 18.3
creating, 18.2
deleting, 18.6
managing, 18
modify priority, 18.5
modifying, 18.4
searching, 18.3
simple search, 18.3
approval policy, 18
approval tasks, 9.1
approving, 9.1.4
claiming, 9.1.3
reassigning, 9.1.6
rejecting, 9.1.5
requesting more information, 9.1.7
submitting information, 9.1.8
task details, 9.1.2
approval workflow, 2.2.2.3.1
approvals
selection methodologies, 18.1
architecture, 2
Business Services Tier, 2.2.2
Data Tier, 2.2.3
Platform Services, 2.2.2.3
Presentation Tier, 2.2.1
reconciliation, 4.2.2
tiers, 2.2
attestation, 19
definition, 1.1.4
Attestation Dashboard, 19.5
e-mail notifications, 19.5.2
scheduled tasks, 19.5.3
using, 19.5
viewing attention request details, 19.5.1
attestation processes, 19.2
Attestation Dashboard, 19.5
Attestation engine, 19.1.6
Attestation Inbox, 19.1.2.1
attestation requests, 19.1.3
configuration, 19.2
creating, 19.3
declined attestation entitlements, 19.1.9.3
defining schedules, 19.1.1
definition, 19.1.1
delegation, 19.1.4
deleting, 19.1.1.1.2, 19.4.4
disabling, 19.1.1.1.1, 19.4.2
editing, 19.4.1
e-mails, 19.1.9
enabling, 19.4.3
lifecycle, 19.1.5
managing, 19.4
managing administrators, 19.4.6
notifying delegated reviewers, 19.1.9.2
notifying reviewers, 19.1.9.1
process owners, 19.1.1
reviewer setup, 19.1.1
reviewers, 19.1.9.4
running, 19.4.5
scheduled tasks, 19.1.7
scope, 19.1.1
task components, 19.1.2
viewing execution history, 19.4.7
attestation task
creating, 19.1.5.1
attestation task components
attestation actions, 19.1.2
attestation data, 19.1.2
attestation date, 19.1.2
reviewers, 19.1.2
task source, 19.1.2
attestation tasks, 9.3
actions, 19.1.5.2
attestation driven workflow capability, 19.1.8
processing submitted tasks, 19.1.5.3
request details, 9.3.2
reviewer response to entitlement, 19.1.5.2
searching, 9.3.1
workflow diagram, 19.1.5.1
audit and compliance management
attestation automation, 1.1.4
comprehensive reporting, 1.1.4
identity reconciliation, 1.1.4
rogue and orphan account, 1.1.4
audit and reports, 2.3
audit engine, 6, 6.2
audit levels, 6.2.1
audit management, 1.1.4
auditing, 6
audit levels, 6.2.1
audit messages, 6.2.3
profile auditing, 6.1.2
role profile auditing, 6.4
user profile auditing, 6.3
authenticated Self Service, 3.1.1
authorization
organization management, 13.3
role management, 12.6
user management, 11.4
authorization policies, 2.2.2.3.2, 15.1
advanced search, 15.2.1.2
approval policy management, 15.3.10
assignee, 15.1
authenticated self service, 15.3.2
authorization policy management, 15.3.4
based on existing policies, 15.2.3
creating, 15.2.2
data security, 15.1
deleting, 15.2.5
Diagnostic Dashboard, 15.3.13
managing, 15
notification management, 15.3.11
plug-ins, 15.3.14
policies for Oracle Identity Manager features, 15.2.5
privileges, 15.1
reconciliation management, 15.3.6
request creation by using request templates, 15.3.9
request template management, 15.3.8
role management, 15.3.3
scheduler, 15.3.7
searching, 15.2.1
simple search, 15.2.1.1
system properties, 15.3.12
user management, 15.3.1
user management configuration, 15.3.5
viewing and modifying, 15.2.4

B

beneficiary, 10
BI Publisher, 20
starting, 20.2
Bulk Load, 2.3
bulk request, 10.2

C

challenge questions and response, 8.5.2
child requests, 10.2
clustered environment, 5.5
common name, 11.6
common name generation, 11.6
common services, 2.3
components, 2.3
configure
integration with LDAP, 4.3.1
username policy, 11.5.2
Connector Framework, 2.2.2.2.1
connector performance
indexes, 4.2.2.8
connectors, 2.2.2.2.1
custom, 5.3
generic technology connector, 5.2
installing, 5.5
predefined, 5.1
create
access policies, 16.3
approval policies, 18.2
custom authorization policies, 15.2.2
organizations, 13.2.3
request templates, 17.1
requests, 14.1
roles, 12.5.1
users, 11.3.2

D

data collection, 6.3.1, 6.4.1
archiving, 6.4.1.1
capturing, 6.3.1.1, 6.4.1.1
data objects, 12.5.2.8, 12.5.2.8
database, 2.2.3.1
default roles, 12.4
delegated administration, 1.1.1, 2.1.4
delete
approval policies, 18.6
authorization policies, 15.2.5
delayed delete, 11.3.3.3.6
organizations, 13.2.8
request templates, 17.4
roles, 12.5.2.3
users, 11.3.3.3.6
deploying connectors
general considerations, 5.5
Deployment Manager, 2.1.1, 3.1.3.1
Design Console, 3.2
development tools, 3.2.1
direct provisioning, 4.1
disable
organizations, 13.2.5
username reservation, 11.5.1
users, 11.3.3.3.2

E

enable
organizations, 13.2.5
username reservation, 11.5.1
users, 11.3.3.3.1
entity definition
organizations, 13.1
roles, 12.3
users, 11.2
exception, 20.6
exception reports, 20.6
external libraries, 5.5
external software, 5.5

F

features, 2.1

G

Generic Technology Connector, 2.2.2.2.4, 5.2
GTC, 2.2.2.2.4, 5.2

H

high availability, 2.2.3.1

I

ICF, 2.2.2.2.2
Identity Administration, 2.3
identity connector, 2.2.2.2.2
Identity Connector Framework, 2.2.2.2.2
identity connector, 2.2.2.2.2
identity store, 2.2.3.3
installing connectors, 5.5
integrated solutions, 5
Adapter Factory, 1.1.5
predefined connectors, 1.1.5
integration
Oracle Identity Manager and LDAP, 4.3
integration services, 2.2.2.2
integration solutions, 1.1.5
Issue Audit Messages Task, 6.2.3
IT resource type, 5.4

L

LDAP, 2.2.3.3, 4.3
LDAP identity store, 4.3
provisioning, 4.3.2
reconciliation, 4.3.3
LDAP integration
configuring, 4.3.1
localization, 3.1.5
locating records, 3.1.2.1
lock
users, 11.3.3.3.3

M

manage
access policies, 16.4
approval policies, 18
approval tasks, 9.1
attestation tasks, 9.3
authorization policies, 15
organizations, 13
provisioning tasks, 9.2
request templates, 17
requests, 10
roles, 12, 12.5.2
tasks, 9
user profile, 8
users, 11
managing processes, 3.2.1
managing resources, 3.2.1
MDS, 2.2.3.2
Metadata Store, 2.2.3.2
mode of reconciliation, 4.2.1.2
modify
approval policies, 18.4
approval policy priority, 18.5
authorization policies, 15.2.4
organizations, 13.2.4
request templates, 17.2, 17.2
user information, 11.3.3
Multiple server instances, 2.1.2

O

OIM Account, 11.1.1
open architecture, 2.1.3
Oracle Identity Administration, 3.1.2
Oracle Identity Manager, 1
architecture, 2
attestation, 19.1
components, 2.3
connectors, 2.2.2.2.1
features, 2.1
LDAP integration, 4.3
reporting, 20
tiers of architecture, 2.2
Oracle identity Manager
registering, 7.1.2
Oracle Identity Manager architecture, 2
Oracle Identity Manager process, 3.2.1
Oracle Identity Manager reports, 2.2.3.1, 20.5
organization, 11.1.2
organization and role management, 1.1.7
organizations, 13
administrative roles, 13.2.6
advanced search, 13.2.1.2
attributes, 13.2.4.1
authorization policies, 13.3
browsing, 13.2.2
child organizations, 13.2.4.2
creating, 13.2.3
deleting, 13.2.8
enabling and disabling, 13.2.5
entity definition, 13.1
managing, 13
members, 13.2.4.3
permitted resources, 13.2.7
provisioning and revoking resources, 13.2.4.4
searching, 13.2.1
simple search, 13.2.1.1
viewing and modifying, 13.2.4

P

parent request, 10.2
password management, 1.1.3
advanced, 1.1.3
self-service, 1.1.3
synchronization, 1.1.3
performing searches, 3.2.1
Plug-in Framework, 2.2.2.3.3
policy-based provisioning, 4.1
post-processors, 6.3.2
predefined connectors, 5.1
process engine, 2.1.8
process form, 5.4
processes
managing, 3.2.1
profile auditing, 6.1.2
provisioning, 1.1.6, 2.3, 4.1
direct, 4.1
multiple resource objects to multiple target systems, 16.5.3
Oracle Identity Manager to LDAP, 4.3.2
policy-based, 4.1
request-based, 4.1
Provisioning Process components, 5.4.1
provisioning tasks, 9.2
="l2ix">adding notes, 9.2.4
assignment history, 9.2.6
form details, 9.2.7
modifying form details, 9.2.8
reassigning, 9.2.5
retrying, 9.2.9
searching, 9.2.1
setting response, 9.2.3
task details, 9.2.2

R

reconciliation, 4.2
account reconciliation, 4.2.1.1.2
action module, 4.2.2.7.2
action rules, 4.2.2.2, 4.2.2.7.2
APIs, 4.2.2.5
approach, 4.2.1.3
architecture, 4.2.2
archival, 4.2.2.10
backward compatibility, 4.2.2.11
changelog, 4.2.1.2
connector, 4.2.2.9
engine, 4.2.2.7
interface, 4.2.2.12
LDAP to Oracle Identity Manager, 4.3.3
mapping rules, 4.2.2.2
matching module, 4.2.2.7.1
matching rules, 4.2.2.2
metadata, 4.2.2.2
mode, 4.2.1.2
process flow, 4.2.1.1.3
profile, 4.2.2.1
push or pull model, 4.2.1.2
regular, 4.2.1.2
run, 4.2.2.4
schema, 4.2.2.6
target, 4.2.2.3
target attributes, 4.2.2.2
trusted source, 4.2.1.1.1
types, 4.2.1
Reconciliation Engine, 2.3
reconciliation engine, 4.2.2.7
action module, 4.2.2.7.2
matching module, 4.2.2.7.1
reconciliation-related tasks, 5.4.2
records
viewing, 3.2.1
regular reconciliation, 4.2.1.2
Remote Manager, 2.2.2.2.5
reporting, 2.2.3.1, 20
BI Publisher, 20
features, 20.1
reports, 20.5
access policy reports, 20.5.1
attestation, request, and approval reports, 20.5.2
Crystal Reports, 20.7
exception reports, 20.6
password reports, 20.5.4
resource and entitlement reports, 20.5.5
role and organization reports, 20.5.3
running, 20.3
user reports, 20.5.6
repository, 2.2.3.1
request
searching, 10.5
request models, 10.3
request service, 2.2.2.3.1, 2.2.2.3.1
request stages, 10.1
request templates, 17
additional attributes, 17.2.3
advanced search, 17.2
allowed resources, 17.2.1
allowed roles, 17.2.1
attribute restrictions, 17.2.2
cloning, 17.3
creating, 17.1
deleting, 17.4
managing, 17
modifying, 17.2
searching and modifying, 17.2
simple search, 17.2
template user roles, 17.2.4
request tracking, 10.5
request-based provisioning, 4.1
requester, 10
requests, 10
advanced search, 14.2.1
beneficiary, 10
bulk request, 10.2
child request, 10.2
closing, 10.8
creating, 14.1
managing, 10
parent request, 10.2
process flow, 10
request details, 14.2.2
request models, 10.3
request templates, 17
requester, 10
searching and tracking, 14.2
simple search, 14.2.1
stages, 10.1
target entity, 10
Task List, 10.7
tracking, 10.5
withdrawing, 10.6
resource object, 5.4
resources
managing, 3.2.1
viewing, 3.1.1.1
RFI tasks, 9.1.7
role profile auditing, 6.4
roles, 11.1.3, 12, 12.5.2.8
advanced search, 12.5.2.2.2
attributes, 12.5.2.4.1
authorization policies, 12.6
browsing, 12.5.2.1
creating, 12.5.1
default, 12.4
deleting, 12.5.2.3
entity definition, 12.3
hierarchy, 12.5.2.4.2
inherited by, 12.2, 12.5.2.4.2
inherited from, 12.2, 12.5.2.4.2
managing, 12, 12.5.2
members, 12.5.2.4.6
membership inheritance, 12.1
permission inheritance, 12.2
searching, 12.5.2.2
simple search, 12.5.2.2.1
viewing and administering, 12.5.2.4

S

scheduled task, 5.4
Issue Audit Messages Task, 6.2.3
scheduler service, 2.2.2.3.5
search
advanced search page, 11.3.1.2.1
approval policies, 18.3
attestation tasks, 9.3.1
authorization policies, 15.2.1
conjunction operator, 11.3.1.1.4
conjunction operators, 11.3.1.2.3
operations on results, 11.3.1.1.6
organizations, 13.2.1
provisioning tasks, 9.2.1
request templates, 17.2
requests, 10.5, 14.2
results, 11.3.1.2.5
roles, 12.5.2.2
search comparators, 11.3.1.1.2, 11.3.1.2.2
search results, 11.3.1.1.5
search string, 11.3.1.1.3
searchable attributes, 11.3.1.1.1, 11.3.1.2.4
users, 11.3.1, 11.3.1.1.7, 11.3.1.2.6
Segregation of Duties, 2.2.2.3.4
Self Service
authenticated, 3.1.1
unauthenticated, 3.1.1
self-service features, 1.1.1
profile management, 1.1.1
request management, 1.1.1
simple search
approval policies, 18.3
authorization policies, 15.2.1.1
conjunction operator, 11.3.1.1.4
operations on results, 11.3.1.1.6
organizations, 13.2.1.1
request templates, 17.2
requests, 14.2.1
roles, 12.5.2.2.1
search comparators, 11.3.1.1.2
search results, 11.3.1.1.5
search string, 11.3.1.1.3
searchable attributes, 11.3.1.1.1
users, 11.3.1.1, 11.3.1.1.7
snapshot
storing, 6.3.1.2, 6.4.1.2
SoD, 2.2.2.3.4
SPML Web Service interface, 3.3

T

target entity, 10
task
managing, 9
RFI, 9.1.7
Task List, 10.7
TaskList, 9
tasks, 9
approval tasks, 9, 9.1
attestation tasks, 9, 9.3
provisioning tasks, 9, 9.2
three-tier strategy, 5
trusted source reconciliation, 4.2.1.1.1
tuning
connector performance
tuning, 4.2.2.8

U

unauthenticated Self Service, 3.1.1
unlock
users, 11.3.3.3.4
user attributes, 11.2
user interfaces, 3
Administrative and User Console, 3.1
Design Console, 3.2
user profile
challenge questions and response, 8.5.2
managing, 8
profile attributes, 8.1
proxies, 8.4
resetting password, 8.6
resource profile, 8.3
role assignments, 8.2
security, 8.5
user profile audit tables, 6.3.3
user profile auditing, 6.3
data collection, 6.3.1, 6.4.1
post-processors, 6.3.2
XL.UserProfileAuditDataCollection, 6.3.1
user profile audits
tables used, 6.3.3
user profile snapshot
trigger, 6.3.1.3, 6.4.1.3
username, 11.5
policy configuration, 11.5.2
releasing, 11.5.3
username reservation, 11.5
enabling and disabling, 11.5.1
users, 11
adding and removing resources, 11.3.3.2.3
adding and removing roles, 11.3.3.2.2
advanced search, 11.3.1.2
attribute profile, 11.3.3.2.1
attributes, 11.2
authorization policies, 11.4
bulk operations, 11.3.3.4
creating, 11.3.2
delayed delete, 11.3.3.3.6
deleting, 11.3.3.3.6
disabling, 11.3.3.3.2
enabling, 11.3.3.3.1
enabling and disabling resources, 11.3.3.2.4
entity definition, 11.2
lifecycle, 11.1
locking, 11.3.3.3.3
managing, 11
OIM Account, 11.1.1
proxy details, 11.3.3.2.7
resetting password, 11.3.3.3.5
resource details, 11.3.3.2.5
resource history, 11.3.3.2.6
searching, 11.3.1, 11.3.1.1.7, 11.3.1.2.6
simple search, 11.3.1.1
unlocking, 11.3.3.3.4
user details, 11.3.3.1
viewing and modifying, 11.3.3

V

view
authorization policies, 15.2.4
organizations, 13.2.4
user information, 11.3.3
viewing records, 3.2.1
viewing resources, 3.1.1.1

W

Web-based user self-service, 2.1.5
wildcard, 3.2.1
workflow and policy
deprovisioning, 1.1.6
dynamic error handling, 1.1.2
policy management, 1.1.2
provisioning, 1.1.6
request tracking, 1.1.2
transaction integrity, 1.1.2
workflow management, 1.1.2
workflow and request service, 2.3

X

XL.UserProfileAuditDataCollection, 6.3.1
PKp2PKj?OEBPS/oimusrintrface.htm User Interfaces

3 User Interfaces

Oracle Identity Manager provides user interfaces that you can use to perform various tasks. These are Oracle Identity Manager Administrative and User Console and Oracle Identity Manager Design Console. These interfaces are located in the Presentation or Client tier of Oracle Identity Manager. Oracle Identity Manager also provides the SPML Web Service interface that supports inbound provisioning requests.

This chapter introduces Oracle Identity Manager interfaces and briefly describes the functionality of each. This chapter also provides a brief introduction to the SPML Web Service. The chapter contains the following topics:

3.1 Overview of Oracle Identity Manager Administrative and User Console

Oracle Identity Manager is an advanced, flexible provisioning system for automatically granting and revoking access to organization applications and managed systems. Oracle Identity Manager Administrative and User Console can provide the staff and partners of an organization with access to the organization's resources, and enforce access policies that are associated with these resources.

Oracle Identity Manager Administrative and User Console enables you to perform various functions, such as viewing user accounts, modifying profiles, viewing request status, and changing passwords. You can also customize Oracle Identity Manager Administrative and User Console, as explained at the end of this section.


Note:

Not all functions are available to all users. The features that you can view and use in Oracle Identity Manager depend on the privileges that you are assigned.

Oracle Identity Manager Administrative and User Console consists of the following main areas:

3.1.1 User Self Service

Unauthenticated user self service or Oracle Identity Manager login page allows the unauthenticated user to perform self service operations. In other words, a user who is not logged in to Oracle Identity Manager can use the login page to perform Oracle Identity Manager Self Service operations such as self registering to Oracle Identity Manager, tracking the self registration request, logging in to Oracle Identity Manager, and retrieve a forgotten password.

When you login to Oracle Identity Manager Administrative and User Console, Oracle Identity Manager Self Service is displayed. Oracle Identity Manager Self Service allows the authenticated or logged in user to perform various self service operations. This section describes the features of Oracle Identity Manager Self Service.

3.1.1.1 Features of the User Self Service

Use the Oracle Identity Manager Self Service to perform the following functions:

  • Self Registering to Oracle Identity Manager

    If you do not have an account in Oracle Identity Manager, you must create one by self registering to Oracle Identity Manager from the unauthenticated user self service. Depending on how your system is configured, you might need your manager to create an account for you.

    When you login to Oracle Identity Manager for the first time, provide answers to the challenge questions when prompted. These challenge questions and answers will be used to authenticate your account if you forget your password.

  • Tracking Self Registration Request

    You can track the self registration request with the help of the registration tracking ID that is generated when you submit the self registration request.

  • Retrieving Forgotten Password

    If you forget your password, you can retrieve the forgotten password by correctly answering the challenge questions.


See Also:

Chapter 7, "Configuring and Using Self-Service Registration" for detailed information about the unauthenticated user self service interface

3.1.2 Oracle Identity Administration

Oracle Identity Administration enables you to perform identity management tasks such as creating and managing users, roles, and organizations. It also lets you define authorization policies to control the access of various components and features in Oracle Identity Manager.

3.1.2.1 Features of Oracle Identity Administration

Use Oracle Identity Administration to perform the following functions:

3.1.3 Oracle Identity Manager Advanced Administration

Oracle Identity Manager Advanced Administration enables you to perform various administrative functions, such as creating and managing requests, reconciliation events, and policies.

3.1.3.1 Features of Oracle Identity Manager Advanced Administration

Use Oracle Identity Manager Advanced Administration to perform the following functions:

3.2 Overview of Oracle Identity Manager Design Console

Oracle Identity Manager Design Console is mainly used to configure the system settings. These settings control the systemwide behavior of Oracle Identity Manager and affect its users. This section describes the basic features of Oracle Identity Manager Design Console.

3.2.1 Features of Oracle Identity Manager Design Console

The following features of Oracle Identity Manager Design Console let you perform different tasks:


See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for more information about the features and functions of Oracle Identity Manager Design Console

3.3 SPML Web Service

Oracle Identity Manager provides client applications with the Identity Management service, which makes use of the Service Provisioning Markup Language (SPML). The SPML Web Service is an interface for inbound SPML-based provisioning requests. SPML has two profiles: the XSD profile and the DSML profile. This release of Oracle Identity Manager makes use of the XSD profile. It provides features for managing references (for example, assignment and revocation of role memberships, and role hierarchy changes such as adding or removing parent roles via SPML), resetting user passwords, and disabling and re-enabling user accounts.


See Also:

"SPML Services" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for details about the SPML Web Service

PKYӅɅPKj? OEBPS/toc.htm Table of Contents

Contents

List of Figures

List of Tables

Title and Copyright Information

Preface

Part I Concepts

1 Feature Overview

2 Architecture

3 User Interfaces

4 Deployment Configurations

5 Integration Solutions

6 Auditing

Part II Oracle Identity Manager Self Service

7 Configuring and Using Self-Service Registration

8 Managing Profile

9 Managing Tasks

10 Managing Requests

Part III Identity Administration

11 Managing Users

12 Managing Roles

13 Managing Organizations

14 Creating and Searching Requests

Part IV Policy Administration

15 Managing Authorization Policies

16 Managing Access Policies

17 Managing Request Templates

18 Managing Approval Policies

19 Managing Attestation Processes

Part V Reporting

20 Using Reporting Features

Index

PKg'siPKj?OEBPS/img_text/search.htm Description of the illustration search.gif

This figure shows the Search field and the search results table on the left pane of the User console.

PKAPKj?$OEBPS/img_text/attstn_req_detail.htm( Description of the illustration attstn_req_detail.gif

This figure shows the Attestation Request Detail window that displays the details of attestation tasks assigned to you or are pending for your action.

PKE-(PKj?!OEBPS/img_text/reqdet_apptask.htm Description of the illustration reqdet_apptask.gif

This figure shows the Approval Tasks tab that lists the pending approval tasks for the request.

PK\PKj?OEBPS/img_text/component.htm5 Description of the illustration component.eps

This figure shows the design components of the auditing process.

PKPKj?OEBPS/img_text/advnc_search.htm Description of the illustration advnc_search.gif

This figure shows the Advanced Search: Organization page with the search attribute fields and the search results table.

PK PKj?OEBPS/img_text/icf.htm Description of the illustration icf.gif

This figure shows the ICF architecture comprising the provisioning engine, common code, API and SPI, objects and utilities, and the target systems.

PKKMPKj?OEBPS/img_text/assgn_task.htm Description of the illustration assgn_task.gif

This figure shows the Select User Assignee for Task window that allows you to select a user or role to assign the task.

PK PKj?OEBPS/img_text/req_advres.htm) Description of the illustration req_advres.gif

This figure shows the search results with details about request ID, request type, status, date requested, and requester in the Advanced Search: Requests Page.

PK G.)PKj?OEBPS/img_text/arch1.htmK Description of the illustration arch1.eps

This figure illustrates the synchronization from Oracle Identity Manager to the target system and from the target system to Oracle Identity Manager for provisioning and reconciliation respectively.

PKrPKPKj?OEBPS/img_text/targ_recon.htm' Description of the illustration targ_recon.eps

This figure shows identity reconciliation followed by account reconciliation.

PKkPKj?OEBPS/img_text/authdata.htm@ Description of the illustration authdata.gif

The Data Constraints page of the Create Policy wizard.

PKuPKj?OEBPS/img_text/auth_advsrch.htm Description of the illustration auth_advsrch.gif

This figure shows the Advanced Search: Authorization Policies page with the search results.

PKhmPKj?OEBPS/img_text/sysprop.htm Description of the illustration sysprop.gif

This figure shows the System Property Detail page for the User Attribute Reservation Enabled system property.

PK37PKj?OEBPS/img_text/req_his.htmM Description of the illustration req_his.gif

This figure shows the Request History tab.

PKPKj?$OEBPS/img_text/recon_processflow.htm; Description of the illustration recon_processflow.eps

This figure shows the reconciliation process flow.

PKNcږPKj?OEBPS/img_text/rfi.htm Description of the illustration rfi.gif

This figure shows RFI added to the task name in the Task Preview column of the Approvals tab.

PK{PKj?OEBPS/img_text/authassign.htm+ Description of the illustration authassign.gif

This figure shows the Policy Assignment page of the Create Policy wizard.

PK@>PKj?OEBPS/img_text/create_org.htm Description of the illustration create_org.gif

This figure shows the Create Organization page in which you can specify basic user information.

PKYlPKj?OEBPS/img_text/attr_restr.htm Description of the illustration attr_restr.gif

This figure shows the Attribute Restrictions tab with attributes associated with the request data set.

PKBͮHPKj?'OEBPS/img_text/integra_sol_strategy.htm Description of the illustration integra_sol_strategy.eps

This figure shows the three-tier integration solutions strategy of Oracle Identity Manager.

PKV[PKj?OEBPS/img_text/usrname.htm9 Description of the illustration usrname.gif

This figure shows the System Property Detail page for the Default policy for username generation system property, whose value is edited to configure the default username policy.

PKsW>9PKj?OEBPS/img_text/resetpass.htmE Description of the illustration resetpass.gif

This figure shows the Reset Password dialog box.

PKSy>׿PKj?OEBPS/img_text/add_notes.htm5 Description of the illustration add_notes.gif

This figure shows the Add Notes for Task window that displays a few details of the task and the current note for the task, and allows you to enter a new note for the task.

PKh#:5PKj?OEBPS/img_text/reqtem6.htm Description of the illustration reqtem6.gif

This figure shows the Review Request Template Summary page of the Create Request Templates wizard.

PK(5PKj?OEBPS/img_text/rolememper.htm" Description of the illustration rolememper.gif

This figure shows the role membership inheritance and role permission inheritance.

PKPKj?OEBPS/img_text/usr_advsrch.htm Description of the illustration usr_advsrch.gif

This figure shows the Advanced Search: Users page with the search fields and the search results.

PKgPKj?#OEBPS/img_text/oimsyscomponents.htm+ Description of the illustration oimsyscomponents.gif

This figure shows the system components of Oracle Identity Manager.

PK*PKj?OEBPS/img_text/agfig8.htm Description of the illustration agfig8.eps

Flowchart describing the events in a follow-up action subflow created after all entitlements have been responded to.

PKUMPKj?OEBPS/img_text/users.htm> Description of the illustration users.gif

This figure shows the Users tab with the View Details link.

PKnPKj?"OEBPS/img_text/rfi_taskdetails.htm= Description of the illustration rfi_taskdetails.gif

This figure shows the task details of an RFI task.

PK)PKj?OEBPS/img_text/taskdetails.htm Description of the illustration taskdetails.gif

This figure shows the Task Details page that displays detailed information about a request.

PK~PKj?OEBPS/img_text/auth_recon.htm Description of the illustration auth_recon.eps

This figure shows trusted source reconciliation from single and multiple authoritative sources.

PK>\fPKj?OEBPS/img_text/org_details.htmC Description of the illustration org_details.gif

This figure shows the Organization Details page.

PK&PKj? OEBPS/img_text/temp_usr_role.htm Description of the illustration temp_usr_role.gif

This figure shows the Template User Roles tab with a list of roles that can be assigned to the request template.

PKkV PKj? OEBPS/img_text/simple_search.htm Description of the illustration simple_search.gif

This figure shows the search result for simple search for organizations in the Search Results tab.

PKPKj?OEBPS/img_text/recon_arch.htm Description of the illustration recon_arch.eps

This figure shows the reconciliation architecture along with the various components of the reconciliation service.

PK$&qPKj?OEBPS/img_text/reqtem4.htm Description of the illustration reqtem4.gif

This figure shows the Set Additional Attributes page of the Create Request Templates wizard.

PKPKj?OEBPS/img_text/reqtem2.htm Description of the illustration reqtem2.gif

This figure shows the Select Attributes to Restrict page of the Create Request Template wizard.

PK#PKj?OEBPS/img_text/res_det.htm Description of the illustration res_det.gif

This figure shows the Resource Details window with details about the resource associated with the request.

PKPKj?OEBPS/img_text/appol_srch.htm9 Description of the illustration appol_srch.gif

This figure shows the search results for approval policies.

PKqPKj?OEBPS/img_text/temp_advres.htm Description of the illustration temp_advres.gif

This figure shows the advanced search result with details about request template name, request model, approval process, and description.

PKpPKj?OEBPS/img_text/res_dat.htmT Description of the illustration res_dat.gif

This figure shows the Step 4: Verify Resource Data page of the Provision Resource to User wizard with sample values for ebusiness Suite User TCA Foundation resource to be provisioned to the user John Doe.

PKIYTPKj?+OEBPS/img_text/bulk_child_req_lifecycle.htm Description of the illustration bulk_child_req_lifecycle.gif

This figure illustrates the life cycle of the Bulk Request and the Child Request.

PKPKj?OEBPS/img_text/req_comment.htmH Description of the illustration req_comment.gif

This figure shows the Request Comments tab.

PKU#pPKj?OEBPS/img_text/agfig5.htm& Description of the illustration agfig5.eps

Flowchart describing events associated with the creation of an attestation process

PK{|PKj?OEBPS/img_text/oes_arch.htm Description of the illustration oes_arch.gif

This figure shows the components of the OES-based authorization service in Oracle Identity Manager.

PKEEPKj? OEBPS/img_text/all_resources.htm( Description of the illustration all_resources.gif

This figure shows the Allowed Resources tab of the Template Details page.

PKxPKj?OEBPS/img_text/prov.htmA Description of the illustration prov.eps

This figure shows the working of the provisioning module.

PKbYPKj? OEBPS/img_text/usr_lifecycle.htm Description of the illustration usr_lifecycle.gif

This figure illustrates the life cycle of an user entity including the various stages of the user lifecycle.

PK^KۏPKj?OEBPS/img_text/agfig6.htm Description of the illustration agfig6.eps

Flowchart describing the sequence of events when a reviewer provides a response to an entitlement.

PKxPKj?OEBPS/img_text/req_flow.htmK Description of the illustration req_flow.gif

This figure shows the request process flow.

PK PKj? OEBPS/img_text/auth_simpsrch.htm( Description of the illustration auth_simpsrch.gif

This figure shows the result of the authorization policies simple search.

PK/A}PKj?OEBPS/img_text/add_attr.htmF Description of the illustration add_attr.gif

This figure shows the Additional Attributes tab.

PKQҾPKj?OEBPS/img_text/sch_arch.htm1 Description of the illustration sch_arch.eps

This figure shows the Oracle Identity Manager Scheduler architecture.

PK PKj?OEBPS/img_text/rfi_opt.htm@ Description of the illustration rfi_opt.gif

This figure shows the available option for an RFI task.

PK<PKj? OEBPS/img_text/remotemanager.htm? Description of the illustration remotemanager.gif

This figure shows the Remote Manager architecture.

PK\;PKj?OEBPS/img_text/lifecycle.htm4 Description of the illustration lifecycle.gif

This figure shows the various stages that a request goes through.

PKZ()PKj?OEBPS/img_text/arch.htm Description of the illustration arch.gif

This figure illustrates the architecture of Oracle Identity Manager consisting of the presentation, server, and data and enterprise integration tiers.

PKS/u PKj?OEBPS/img_text/browse_org.htm Description of the illustration browse_org.gif

This figure shows all the organizations in Oracle Identity Manager in the browse list.

PK4dPKj?OEBPS/img_text/search_org.htm Description of the illustration search_org.gif

This figure shows the Search: Organizations dialog box in which you can search for organizations to be specified as the parent organization.

PK* m PKj?OEBPS/img_text/role.htm! Description of the illustration role.gif

This figure displays the Requested Roles tab with a list of beneficiaries and role names.

PKfgPKj?OEBPS/img_text/ldap.htm Description of the illustration ldap.eps

This figure shows the components involved in the integration between Oracle Identity Manager and LDAP identity store.

PK鲯PKj?OEBPS/img_text/trckng_ben.htm) Description of the illustration trckng_ben.gif

This figure shows the search results table for the requests raised for you.

PK wPKj?!OEBPS/img_text/authpermission.htm? Description of the illustration authpermission.gif

The Permissions page of the Create Policy wizard.

PKZPKj?OEBPS/img_text/task_hist.htm Description of the illustration task_hist.gif

This figure shows the Task History window that displays the history of the task assignment.

PK7SPKj?OEBPS/img_text/accnt_recon.htm5 Description of the illustration accnt_recon.eps

This figure shows account reconciliation from a target system.

PKP(PKj?"OEBPS/img_text/request_details.htm Description of the illustration request_details.gif

This figure shows the Request Details tab with detailed information about the request.

PKPKj?OEBPS/img_text/authcreate.htm6 Description of the illustration authcreate.gif

The Basic Policy Information page of the Create Policy wizard.

PKS8PKj?OEBPS/img_text/req_history.htmE Description of the illustration req_history.gif

This figure shows the request history details.

PKP}PKj?!OEBPS/img_text/gtc_arch_trans.htm Description of the illustration gtc_arch_trans.eps

This figure shows the functional architecture of a generic technology connector.

PK`-PKj?OEBPS/img_text/res_tab.htm Description of the illustration res_tab.gif

This figure shows the Requested Roles tab with details of the roles associated with the request.

PK7uPKj?OEBPS/img_text/userdetails.htm! Description of the illustration userdetails.gif

This figure shows the User Details window with that displays the user information.

PKiPKj?OEBPS/img_text/hierarchy.htm3 Description of the illustration hierarchy.gif

This figure shows an example of recursive organization membership.

PK AlPKj?OEBPS/img_text/reqtem3.htm Description of the illustration reqtem3.gif

This figure shows the Set Attribute Restrictions page of the Create Request Templates wizard.

PK0PKj?OEBPS/img_text/reqtem1.htmI Description of the illustration reqtem1.gif

This figure shows the Set request template details page of the Create Request Template wizard with values in the Request Template Name, Request Type, and Template Level Approval Process fields.

PKl~TNIPKj?OEBPS/img_text/agfig7.htm Description of the illustration agfig7.eps

Flowchart describing flow of events once reviewers submit their responses to an attestation task.

PK2PKj?OEBPS/img_text/appol_adv.htm1 Description of the illustration appol_adv.gif

This figure shows the advanced search results for approval policies.

PKl\PKj?OEBPS/img_text/reqtem5.htm Description of the illustration reqtem5.gif

This figure shows the Set Template User Roles page of the Create Request Templates wizard.

PKo_PKj?OEBPS/usr_mangmnt.htm Managing Users

11 Managing Users

The user management feature in Oracle Identity Manager includes the creation, updation, deletion, enabling and disabling, locking, and unlocking of user accounts. This feature is described in the following sections:

11.1 User Lifecycle

User lifecycle is a term to describe the process flow of how a user entity is created, managed, and terminated in the system based on certain events or time factors.

A user entity goes through various stages in the lifecycle. The stages are non-existent, disabled, active, and deleted. Figure 11-1 depicts the different lifecycle stages, all possible transitions, and the operations that set up those transitions:

There is a possibility of process rules or business requirements being defined for each transition of the user lifecycle. You can use the sample scenarios listed in Table 11-1 to establish the link between user lifecycle transitions and business objectives.

Table 11-1 User Life Cycle and Business Objectives Sample Scenarios

Current StateOperationSample ScenarioProcess Description

Non-existent

Create

HR enters user profile information for a new hire. If the new hire is not introduced to the system immediately, then HR sets a future start date for the user.

If the start is not a future date then the user is introduced into the system in an Active state.If the Start Date is in future then the create process creates the user in a disabled state.

Disabled

Enable

User's start date is in effect. The system initiates provisioning for the new hire.

User is marked enabled in the system and the user is now able to login and use the system. By default, all necessary memberships and accounts are established as part of the workflow.

Active

Modify

User is promoted to a new position. As a result, HR changes the job title of the user.

New resources are provisioned to the user, and old irrelevant resources are deprovisioned from the user.

Active

Disable

User takes one year sabbatical from the company. HR manually disables the user on the last working day of the user. The user re-joins the company after some period. HR can make the user Active again.

User is marked disabled in the system, and the user is no longer able to login to the system. The disabled users can be made Active again.

Active

Deleted

User retires from the company. HR manually deletes the user on the last working day of the user.

User is marked disabled in the system, and the user is no longer able to login to the system. By default, all users' accounts are deprovisioned as part of the workflow.


The following concepts are integral to user lifecycle management:

11.2 User Entity Definition

Attributes are defined for the user entity in Oracle Identity Manager. You can add your own attributes to the user entity.

For each attribute for a user entity, the following properties are defined in Oracle Identity Manager:

Table 11-2 lists the attributes defined for the user entity in Oracle Identity Manager:

Table 11-2 Attributes Defined for User Entity

Attribute NameCategoryDescriptionData TypePropertiesLOV (default in bold)

usr_key

Account Settings

The GUID of the user. It is autogenerated when the user is created.

number

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: ENTITY

N/A

act_key

Basic User Information

The GUID of the organization to which the user belongs. This is a mandatory field.

number

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 19

Visible: Yes

Display Type: ENTITY

N/A

Last Name

Basic User Information

The last name of the user. This is a mandatory field.

string

Required: Yes

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

First Name

Basic User Information

The first name of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Middle Name

Basic User Information

The middle name of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Full Name

Basic User Information

The full name of the user. The full name is localized and stored at account creation time.

string

Required: No

MLS: Yes

Multi-represented: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 164

Visible: No

Display Type: TEXT

N/A

Display Name

Basic User Information

The display name of the user. If not specified, then it is autogenerated while creating the user.

string

Required: No

MLS: No

Multi-represented: Yes

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 382

Visible: Yes

Display Type: TEXT

N/A

Xellerate Type

Basic User Information

The type of user, end-user or administrator.

string

Required: Yes

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 30

Visible: Yes

Display Type: CHECKBOX

Lookup.Users.XellerateType

End-User

End-User Administrator

usr_password

Account Settings

The password of the user. It is stored as an encrypted value.

string

Required: Yes

System Controlled: No

Encryption: Encrypt

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 128

Visible: Yes

Display Type: SECRET

N/A

usr_disabled

Account Settings

Indicates whether the user is disabled or enabled.

0 indicates that the user is enabled. 1 Indicates that the user is disabled.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: Yes

Read-Only: Yes

Max-Size: 1

Visible: Yes

Display Type: CHECKBOX

N/A

Status

Account Settings

The status of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: Yes

Max-Size: 25

Visible: Yes

Display Type: LOV

Lookup.WebClient.Users.Status

Active

Disabled

Deleted

Disabled Until Start Date

Role

Basic User Information

The role to which the user is a member.

string

Required: Yes

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 255

Visible: Yes

Display Type: LOV

Lookup.Users.Role

Full-Time

Part-Time

Temp

Intern

Consultant

EMP

CWK

NONW

OTHER

Contractor

User Login

Account Settings

The login ID of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

usr_manager_key

Basic User Information

The GUID of the user's manager.

number

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 19

Visible: Yes

Display Type: ENTITY

N/A

Start Date

Account Effective Dates

The start date of the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: -

Visible: Yes

Display Type: DATE_ONLY

N/A

End Date

Account Effective Dates

The end date of the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: -

Visible: Yes

Display Type: DATE_ONLY

N/A

usr_provisioning_date

Provisioning Dates

The date on which the user profile has been created in Oracle Identity Manager.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: -

Visible: Yes

Display Type: DATE_ONLY

N/A

usr_deprovisioning_date

Provisioning Dates

The date when the resources will be deprovisioned from the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: -

Visible: Yes

Display Type: DATE_ONLY

N/A

usr_provisioned_date

System

The date when the resources have been provisioned to the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_deprovisioned_date

System

The date when the resources are deprovisioned from the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

Email

Basic User Information

The e-mail address of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

usr_locked

Account Settings

Indicates whether the user account is locked or unlocked.

The value 0 indicates that the account is unlocked.

The value 1 indicates that the account is locked.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: Yes

Display Type: LOV

Users.Lock User

0

1

Locked On

Lifecycle

The date on which the user account has been locked.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

Automatically Delete On

Lifecycle

The date on which the user account will be automatically deleted.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

Manually Locked

Lifecycle

Indicates whether the user account has been automatically or manually locked.

1 indicates that the account has been manually locked by an administrator.

0 indicates that the account has been automatically locked, for instance, on exceeding the maximum number of login attempts with incorrect password.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: TEXT

N/A

usr_login_attempts_ctr

System

The number of times the user has tried logging in with incorrect password. It is set to 0 at every successful login.

number

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: NUMBER

N/A

usr_create

System

The date on which the user has been created.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_update

System

The date on which the user has been last updated.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_timezone

Preferences

The timezone preference of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 100

Visible: Yes

Display Type: TIME_ZONE

N/A

usr_locale

Preferences

The locale preference of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 100

Visible: Yes

Display Type: LOV

Notification.Languages

English

French

German

Italian Spanish

Brazilian Portuguese

Japanese

Korean

Simplified Chinese

Traditional Chinese

Arabic

Czech

Danish

Dutch

Finnish

Greek

Hebrew

Hungarian

Norwegian

Polish

Portuguese

Romanian

Russian

Slovak

Swedish

Thai

Turkish

usr_pwd_cant_change

System

This field is currently not used.

string

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: CHECKBOX

N/A

usr_pwd_must_change

System

This field is currently not used.

The value 0 indicates that the password is not required to be changed.

The value 1 mandates that the user changes the password.

string

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: CHECKBOX

N/A

usr_pwd_never_expires

System

This field is currently not used.

The value 0 indicates that the password will expire.

The value 1 indicates that password never expires.

string

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: Yes

Display Type: CHECKBOX

N/A

usr_pwd_expire_date

System

The date on which the password will expire. Valid if Password Never Expires is 0.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_pwd_warn_date

System

The date after which the user will be warned to change the password.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_pwd_expired

System

Indicates whether the user password has expired. If so, then the password must be reset.

The value 0 indicates that password has not expired.

The value 1 indicates that password has expired.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: CHECKBOX

N/A

usr_pwd_warned

System

Indicates whether the user has been warned to change the password.

0 indicates that the user has not been warned to change the password yet.

1 indicates that the user has been warned to change the password.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: CHECKBOX

N/A

usr_pwd_reset_attempts_ctr

System

The number of times the user has tried resetting the password with incorrect answers to challenge questions. It is set to 0 at every successful reset password.

number

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: NUMBER

N/A

usr_change_pwd_at_next_logon

System

Indicates whether the user must change his password at next login.

The value 1 indicates that the user must reset password at next login. The value 0 indicates that user does not need to reset password at next login.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: CHECKBOX

N/A

usr_data_level

System

Indicates the kind of operation, such as add, modify, or delete, supported on this record.

The possible values for this column are:

0: Indicates that this row can be updated or deleted

1: Indicates that this row cannot be updated and deleted

2: Indicates that the row can only be modified and cannot be deleted

3: Indicates that the row can only be deleted and cannot be modified

string

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: TEXT

N/A

usr_pwd_min_age_date

System

If set, then it indicates the date before which the user password cannot be changed.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: -

Visible: No

Display Type: DATE_ONLY

N/A

usr_createby

System

The GUID of the user who created this user.

number

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: ENTITY

N/A

usr_updateby

System

The GUID of the user who updated this user.

number

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: ENTITY

N/A

usr_created

System

This is not currently used in Oracle Identity Manager.

date

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 19

Visible: No

Display Type: DATE_ONLY

N/A

usr_policy_update

System

This is used to re-evaluate the user's policies. To re-evaluate object policies for any user to whom the current policy applies, evaluate the UPP and UPD tables to get list of users for the current policy. For each user found, set the policy_update flag. Attach as a post-insert, post-update and post_delete event handler to tcPOP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: Yes

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: TEXT

N/A

Country

Other User Attributes

The country of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 100

Visible: Yes

Display Type: TEXT

N/A

Department Number

Other User Attributes

The department number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Description

Other User Attributes

The description of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 2000

Visible: Yes

Display Type: TEXT

N/A

Common Name

Other User Attributes

The common name of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 240

Visible: Yes

Display Type: TEXT

N/A

Employee Number

Other User Attributes

The employee number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Fax

Other User Attributes

The FAX number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Generation Qualifier

Other User Attributes

The Generation Qualifier for the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Hire Date

Other User Attributes

The hire date of the user.

date

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: -

Visible: Yes

Display Type: DATE_ONLY

N/A

Home Phone

Other User Attributes

The home phone number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Locality Name

Other User Attributes

The locality name of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Mobile

Other User Attributes

The mobile number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Pager

Other User Attributes

The pager number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Home Postal Address

Other User Attributes

The home postal address of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

Postal Address

Other User Attributes

The postal address of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

Postal Code

Other User Attributes

The postal code of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 230

Visible: Yes

Display Type: TEXT

N/A

PO Box

Other User Attributes

The PO box number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

State

Other User Attributes

The state of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Street

Other User Attributes

The street name in the user's address.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Telephone Number

Other User Attributes

The telephone number of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: Yes

Display Type: TEXT

N/A

Title

Other User Attributes

The title of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

Initials

Other User Attributes

The initials of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 10

Visible: Yes

Display Type: TEXT

N/A

Password Generated

System

This flag indicates whether the password has been autogenerated for the user.

string

Required: No

System Controlled: Yes

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: Yes

Max-Size: 1

Visible: No

Display Type: TEXT

N/A

LDAP Organization

Other User Attributes

User organization name in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

LDAP Organization Unit

Other User Attributes

User organization unit in LDAP, such as department or any subentity of a larger entity.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 80

Visible: Yes

Display Type: TEXT

N/A

LDAP GUID

Other User Attributes

User global unique identifier in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

LDAP DN

Other User Attributes

User distinguished name in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display Type: TEXT

N/A

Embedded Help

Other User Attributes

Indicates whether to suppress the help popups on rollover. This attribute is not interpreted by Oracle Identity Manager and is used to persist values in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 10

Visible: No

Display Type: LOV

Lookup.Users.EmbeddedHelp

true

false

Number Format

Other User Attributes

The number format preference of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 30

Visible: No

Display Type: LOV

Lookup.Users.NumberFormat

#,##0.##[.,]

#,##0.###[\u00A0,]

#,##0.###

#,##0.###;#,##0.###-

#,##0.###[.,]

#,##0.###;(#,##0.###)[.,]

#,##0.##[\u00A0,]

#,##0.###['.]

#,##0.###[',]

Date Format

Other User Attributes

The date format preference of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: No

Display Type: LOV

Lookup.Users.DateFormat

MM-dd-yyyy

MM-dd-yy

MM.dd.yyyy

MM.dd.yy

MM/dd/yyyy

MM/dd/yy

M-d-yyyy

M-d-yy

M.d.yyyy

M.d.yy

M/d/yyyy

M/d/yy

dd-MM-yyyy

dd-MM-yy

d-M-yyyy

d-M-yy

dd.MM.yyyy

dd.MM.yy

d.M.yyyy

d.M.yy

dd/MM/yyyy

dd/MM/yy

d/M/yyyy

d/M/yy

yyyy-MM-dd

yy-MM-dd

yyyy-M-d

yy-M-d

yyyy.MM.dd

yy.MM.dd

yyyy.M.d

yy.M.d

yy. M. d

yyyy/MM/dd

yy/MM/dd

yyyy/M/d

yy/M/d

Time Format

Other User Attributes

The time format preference of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: No

Display Type: LOV

Lookup.Users.TimeFormat

HH.mm

HH.mm.ss

HH:mm

HH:mm:ss

H:mm

H:mm:ss

H.mm

H.mm.ss

a hh.mm

a hh.mm.ss

a hh:mm

a hh:mm:ss

ah:mm

ah:mm:ss

hh.mm a

hh.mm.ss a

hh:mm a

hh:mm:ss a

Currency

Other User Attributes

The preferred currency code of the user.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: No

Display Type: LOV

Lookup.Users.Currency

Font Size

Other User Attributes

The preferred font size of the user, such as large or medium. This is related to the Accessibility feature. This attribute is not interpreted by Oracle Identity Manager and is used to persist values in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 10

Visible: No

Display Type: LOV

Lookup.Users.FontSize

LARGE

MEDIUM

Color Contrast

Other User Attributes

The preferred color contrast of the user, such as standard or high. This is related to the Accessibility feature. This attribute is not interpreted by Oracle Identity Manager and is used to persist values in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 10

Visible: No

Display Type: LOV

Lookup.Users.ColorContrast

STANDARD

HIGH

Accessibility Mode

Other User Attributes

The preferred accessibility feature of the user, such as Screen Reader Optimized or Standard Accessibility. This attribute is not interpreted by Oracle Identity Manager and is used to persist values in LDAP.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: No

Support Bulk Update: No

Read-Only: No

Max-Size: 20

Visible: No

Display Type: LOV

Lookup.Users.AccessibilityMode

screenReader

inaccessible

default

User Name Preferred Language

Preferences

The preference language of the user used to only show the display name of the user in that language.

Note: The preference can be stored in Oracle Identity Manager, but it is not honored on Oracle Identity Manager UI.

string

Required: No

System Controlled: No

Encryption: Clear

Searchable: Yes

Support Bulk Update: Yes

Read-Only: No

Max-Size: 20

Visible: No

Display Type: LOV

Select MLS_LOCALE_CODE as USR_NAME_PREFERRED_LANG from mls_locale where locale_flag=0 OR locale_flag 1 order by mls_locale_code asc


11.3 User Management Tasks

You can perform the following user management tasks in the Oracle Identity Administration:

11.3.1 Searching Users

In Oracle Identity Manager Administration, you can perform the following types of search operations for the user entity:

11.3.1.1 Simple Search

The search operation lets you search user entities based on the search strings that you specify as search attributes. This operation is also referred to as simple search or quick search.

The search feature is described in the following topics:

11.3.1.1.5 Search Results

Result attributes define the set of attributes that are to be returned by the search operation. The actual set of result attributes, however, are determined dynamically based on user's permissions.


Note:

The search results do not include deleted users, which means users with status = Deleted.

The limited search result table shows a subset of the columns of the full search result table. User configuration specifies the columns to display in the search results, and the subset to display in the limited search result table. For more details about configuration management, see "Configuring User Attributes" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

The simple search result table displays the Display Name attribute only. Here, the Display Name of all those users whose Display Name, User Login, First Name, or Last Name attribute value equals search text are displayed in the search result.

You can perform sorting and paging of the displayed data in the search results table.


Tip:

When you scroll up or down, the page index changes. Each page contains a fixed set of entries. When page index changes and the next required page is not within the UI, the UI triggers an event. As a response to this event, the result page is displayed.

There are up and down arrows provided on each attribute in the search result table. Clicking the up or down arrow of the attribute provides with the sort attribute and sorting order.


11.3.1.2 Advanced Search

The advanced search options are displayed in the right pane of Oracle Identity Manager Administration. The advance search allows you to specify more complex search criteria than the simple search criteria. The results are displayed in search results tables.

The advanced search operation is described in the following sections:

11.3.1.2.6 Performing an Advanced Search Operation

To perform an advanced search operation and display the search result:

  1. In the Welcome page of Oracle Identity Manager Administration, under users, click Advanced Search - Users. Alternatively, you can click Administration, and under the Browse tab, click the Advanced Search: Users.

  2. Select All or Any conjunction operator. For information about these operators, see "Conjunction Operator".

  3. Specify a search criteria in the fields. You can include wildcard characters (*) in your search criterion. For performance reasons, initial (prefix) wildcards will be removed. Select the search comparators in the lists adjacent to the fields. See Table 11-3, "Advanced Search Comparators" for information about the advanced search comparators.


    Note:

    The asterix wildcard character (*) search for the Identity Status field returns only the users with Active , Disabled, and Disabled Until Start Date statuses, but not with Deleted status. To search for users with Deleted status, you must enter Deleted in the Identity Status field.

    To add a field in the search criteria, click Add Fields, and then select the field name from the list.

  4. Click Search. The user records that match your search criteria are displayed in the search results table, as shown in Figure 11-4:

11.3.2 Creating Users

You can create a new user in Oracle Identity Manager by using the Create User page. You can open this page only if you are authorized to create users as determined by the authorization policy on the Create User privilege on any organization in Oracle Identity Manager.

To create a user:

  1. Login to Oracle Identity Manager Administration.

  2. Open the Create User page. To do so, perform any one of the following:

    • In the Welcome page, under Users, click Create Users.

    • Click the Administration tab on the tool bar, and in the Welcome page, under Users, click Create Users.

    • Click the Search Results tab, and from the Action menu, select Create User.

    • In the Search Results tab, click the Create User icon on the toolbar.

    The Create User page displays input fields for user profile attributes. The attributes that are displayed in the create user page are determined by the configuration of the Create User page in User Management Configuration. In this configuration, each of the attributes defined for the user entity is marked as being available on the Create User page.


    See Also:

    "Configuring User Attributes" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about configuring the Create User page

  3. Enter details of the user in the Create User page. Table 11-5 describes the fields in the Create User page:

    Table 11-5 Fields in the Create User Page

    SectionFieldDescription

    Basic User Information

    First Name

    First name of the user.


    Middle Name

    Middle name of the user.


    Last Name

    Last name of the user.


    Design Console Access

    The user of OIM User type. It can have one of the two possible values, End-User and End-User Administrator. The OIM User type tells whether or not the user can log in to Oracle Identity Manager Design Console. If the "Design Console Access" check box is selected, the user type will be "End-User Administrator" and the user will have access to design console.


    Email

    E-mail address of the user.


    Manager

    The reporting manager of the user.


    Organization

    The organization to which the user belongs to.


    User Type

    The type of employee, such as full-time employee, intern, contractor, part-time employee, consultant, or temporary.


    Display Name

    It can have localized values, which can be added by clicking Manage Localizations, and selecting from a list of languages. Display Name is available in 33 languages.

    Account Settings

    User Login

    The user name to be specified for logging in to the Administration Console.


    Password

    The password to be specified for logging in to the Administration console.


    Confirm Password

    The password to be re-entered for confirmation.

    Account Effective Dates

    Start Date

    The date when the user will be activated in the system.


    End Date

    The date when the user will be deactivated in the system.

    Provisioning Dates

    Provisioning Date

    Date when user is getting provisioned into the system.


    Deprovisioning Date

    Date when the user is getting deprovisioned from the system.

    Other User Attributes

    Country

    The country where user resides.


    Department Number

    The department number of the user.


    Common Name

    The common name of the user.


    Employee Number

    The employee number of the user.


    Fax

    The fax number of the user.


    Generation Qualifier

    Whether the user qualifies the generation.


    Hire Date

    The hiring date of the user.


    Home Phone

    The home phone number of the user.


    Locality Name

    The name of the locality where user resides.


    Mobile

    The mobile number of the user.


    Pager

    The pager number of the user.


    Home Postal Address

    The house address of the user.


    Postal Address

    The postal address of the user.


    Postal Code

    The postal code number of the user's address.


    PO Box

    The post box number of the user's address.


    State

    The state name of the user.


    Street

    The street name where the user resides.


    Telephone Number

    The telephone number of the user's residence.


    Title

    The title for the user.


    Initials

    The initials of the user.


    You can enter attribute values in more than one language in the pages for creating or updating entities, such as users, organizations, and roles.

  4. After you enter the user information, click Save to create the user.


Tip:

Users can be created by any one of the following methods:
  • By using Oracle Identity Administration

  • By self registration

  • By creating a request

  • By using SPML Web service or APIs

For all the above methods, Oracle Identity Manager uses the default password policy or Password Policy against Default Rule. If you want to use a different password policy, then you must attach the new password policy to the default rule by using the Design Console. To do so, see "Managing Password Policies" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.


11.3.3 Viewing and Modifying User Information

The view user operation allows you to view detailed user profile information in the User Detail page. You can open this page if you are authorized to view the user's profile as determined by the authorization policy through the View User Details privilege. If you have the authorization to modify the user, then you can modify the user by using this page.

To display user details, perform any of the following:

  • Click the user login link in the search results table for simple search.

  • Select a record in the user search results table for both simple and advanced search, and then select Modify User from the Actions menu. Alternatively, you can click Modify User on the toolbar.

The viewing and modifying operations are described in the following sections:

11.3.3.1 User Details Page

The user details page for the user entity is auto-generated based on configuration and authorization. This page is divided into the following tabs:

11.3.3.1.1 The Attributes Tab

This tab displays the attribute profile that includes details about basic user information, account settings, and other user attributes. You can modify any field to change the attribute profile information, and click Apply.

To eliminate the changes made in this page, click Revert.

11.3.3.1.3 The Resources Tab

This section displays a list of resources that a user has been provisioned. For each resource in the list, it displays the following:

  • Resource Name: Name of the resource assigned to a user

  • Request ID: If the provisioned instance is associated with a request

  • Service Account: Yes if the account was provisioned as a service account, otherwise No.

  • Description: If any, for the provisioned instance

  • Type: The type of resource

  • Status: The status of the resource such as Provisioned, Enabled, or Disabled

  • Provisioned On: The date when the resource was provisioned to the user

11.3.3.1.5 Direct Reports

This tab displays a read-only table of users for whom the user is set as the manager. In other words, this tab lists the direct reportees of the user. For each user in the table, it displays the following:

  • Display Name

  • User Login

  • Status

  • Organization

If you select a row in the table, then summary information about the direct reportee is displayed at the bottom.

Direct reports allows you to open the user details of the direct reportees. To do so, select a row in the table of direct reportees, and form the Action menu, select Open User. Alternatively, you can click Open User on the toolbar.

11.3.3.1.6 The Requests Tab

This tab displays the requests raised by the user (where the user is the requester) and the requests raised for the user (where the user is the beneficiary of the target user). For each request, the following details are displayed:

  • Request ID: An ID to uniquely identify the request

  • Model Name: The request model name

  • Status: Shows the current state of the request

  • Requested By: The requester who raised the request

  • Parent ID: An ID of the parent request, if any, to which the request is a child request

  • Date Requested: The date on which the request is created


See Also:

Chapter 14, "Creating and Searching Requests" for information about requests, request types, and parent and child requests

This tab allows you to open the details of the requests by clicking the request IDs.

11.3.3.2 User Modifications

You can perform administrative user modification tasks from the user details. The modification is broken up across the different tabs in the page that displays user details, which means that modifications done in each tab are independent of each other and must be saved individually. The modifications you can perform in each tab is outlined in the following sections:

11.3.3.2.2 Adding and Removing Roles

To add a role:

  1. In the Roles tab, from the Action menu, select Assign Roles. Alternatively, you can click Assign Roles on the toolbar. The Assign Role to User window is displayed.

  2. From the Search Roles list, select the type of role or role category. The default role categories are OIM Roles and Default. In addition, you can create custom role categories. See "Creating and Managing Role Categories" for detailed information about role categories.

  3. Search can be performed on the following fields:

    • Display Name

    • Name

    • Role Namespace

    Select All or any conjunction operator. For information about these operators, see "Conjunction Operator".

  4. Enter a search criterion in the search field. You can specify the asterix (*) wildcard character in the search criterion. Then, click the search icon. All roles that belong to the category you selected are displayed in the Available Roles list.

  5. Select one or more roles from the Available Roles list (Shift + Click for contiguous row selection and Ctrl + Click for non-contiguous selection). Then click the Move or Move All buttons to move the selected roles to the Roles to Assign list.


    See Also:

    Table 12-5, "Default Roles in Oracle Identity Manager" for information about the default roles in Oracle Identity Manager

  6. Click OK. A confirmation message is displayed and the roles you selected are assigned to the user.

The Roles tab allows you to select one or multiple roles in the list, and then allows you to remove roles. To remove a role:

  1. Select the role or roles that you want to remove.

  2. From the Action menu, select Revoke Roles. Alternatively, you can click Revoke Roles on the toolbar. A message is displayed asking you to confirm.

  3. Click OK. A success message is displayed on the user details page for successful role assignment.

11.3.3.2.3 Adding and Removing Resources

The Resources tab allows you to select one or multiple resources in the list, and then perform various operations, such as adding and removing resources, enabling and disabling resources, and displaying resource details and history.

To add a resource to a user:

  1. In the Resources tab, from the Action menu, select Add. Alternatively, you can click Add Resource on the toolbar. The Provision Resource to User wizard is displayed.

  2. In Step 1: Select a Resource page, select the resource you want to provision.

  3. Click Continue. The Step 2: Verify Resource Selection page is displayed. This page displays the resource that you selected for provisioning to the target user.

  4. Click Continue. The Step 3: Process Data page is displayed.

  5. Enter values in the fields to specify information about the selected resource.

  6. Click Continue. The Step 4: Verify Process Data page is displayed with details about the resource.

    Figure 11-5 shows the Step 4: Verify Process Data page with sample values for the ebusiness Suite User TCA Foundation resource to be provisioned to the user John Doe with user ID JohnD.

  7. If you want to edit any information displayed in this page, click Edit on the top-right corner of the page. The Step 3: Provide Process Data page is displayed that allows you to edit process data. When finished, click Continue to go back to the Step 4: Verify Process Data page.

    After verifying all information, click Continue.


    WARNING:

    Make sure that you verify the process data before clicking Continue. This is because clicking Continue starts provisioning.


  8. Click Continue to start provisioning the selected resource to the user. A message is displayed stating that the provisioning has been started.

To remove a resource from a user:

  1. In the Resources tab, select a resource that you want to remove.

  2. From the Action menu, select Remove Resource. Alternatively, you can click Revoke on the toolbar. A confirmation message is displayed.

  3. Click OK. The resource is removed, and a success message is displayed.

11.3.3.3 Single User Operations

You can perform user management operations for a single user from the page that displays user details. These operations are:

11.3.3.3.5 Resetting the Password for a User

You can reset the password for a user by performing any one of the following:

  • Generate the password manually: You can reset the password of a user manually in instances such as the user has forgotten the password and has called HelpDesk to reset the password quickly. Helpdesk can immediately reset the password manually by entering a password, and the user can login by using the new password. This resolves the issue faster than the user waiting for an e-mail notification.

  • Generate a random password: When a password has to be reset by someone other than the target user, an administrator for example, random password generation is useful so that the person changing the password will not know the new password. A random password can be generated in the following instances:

    • A user has forgotten the password and it needs to be reset.

    • The password has expired. A user has been locked.

    • A user has been locked.

    In such scenarios, when the password is reset, Oracle Identity Manager can automatically generate a new random password that conforms to the given password policy. Also, when the password is reset, the administrator gets an option to check a check box, which when checked will send out an e-mail notifying the user about the password change. This method enables you to generate temporary passwords randomly that cannot be easily guessed by anyone. After you generate the random password, at the next login, the user is prompted to reset the randomly generated password.

To reset the password for a user:

  1. In the user search result on the left pane of Oracle Identity Manager Administration, select a user. Alternatively, you can select the user from the search results of Advanced Search. In addition, you can perform this operation from the page that displays user details.

  2. From the Action menu, select Reset Password. Alternatively, you can click the Reset Password icon on the toolbar. If the user details page for the user is open, then you can click Reset Password on the toolbar. The Reset Password dialog box is displayed, as shown in Figure 11-6:

  3. To manually change the user's password:

    1. Select the Manually change the Password option.

    2. In the New Password field, enter the new password that conforms to the password policy that is displayed in the Password Policy section.

      The Password Policy section displays the password policy assigned to the user. This section does not display the password policy if no password policy is defined. For information about password policies, see "Managing Password Policies" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

    3. In the Confirm new password field, re-enter the password.

  4. To generate a random password, select the Auto generate the Password (Randomly generated) option.

  5. Verify that the Email the new password to the user option is selected so that the new password is sent to the user through e-mail.

  6. Click Reset Password. A confirmation message is displayed stating that the password is changed successfully.


Tip:

If the user forgets the password and tries to retrieve it, then the challenge questions are prompted to the user. The user must enter the same answers provided while creating a password. You can configure the challenge questions for the users by using Oracle Identity Manager Design Console.

To configure challenge questions for the user:

  1. Login to Oracle Identity Manager Design Console.

  2. Navigate to Administration, Lookup Definition.

  3. Search for the Lookup for challenge questions, that is, lookup Code = Lookup.WebClient.Questions.

  4. In the Lookup Code Information tab, add questions by entering the appropriate values in the Code Key and Decode fields.

  5. Click Add.

  6. Add this key to the custom resource bundle.

For more information about the Lookup Definition form, see "Lookup Definition Form" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.


11.3.3.3.6 Deleting User

This operation is available only if the user status is not Deleted.

If the user is currently disabled, and the Automatically Delete On attribute is set to a future date, then the disable operation fails, and a message is displayed stating that the user cannot be deleted because it is currently scheduled to be deleted at a future date.

To delete a user:

  1. In the user search result on the left pane of Oracle Identity Manager Administration, select a user. Alternatively, you can select the user from the search results of advanced search. In addition, you can perform this operation from the page that displays user details.

  2. From the Action menu, select Delete User. Alternatively, you can click the Delete User icon on the toolbar. If the user details page for the user is open, then you can click Delete User on the toolbar. A message is displayed asking for confirmation.

  3. Click OK. A confirmation message is displayed stating that the user is successfully deleted.

  4. Click OK to close the message box.

    If you delete a user from the user detail page, then the successful completion refreshes the Attributes tab. If you perform this operation from a user list, such as simple or advanced search results, then the corresponding row in the list is refreshed.

Sometimes, you might not want a delete operation to immediately delete the user. Instead, you might want a delete operation to disable the user for a predefined period of time, during which the delete operation can be canceled. After that predefined period of time, the user is deleted. This is called a delayed delete.

To configure delayed delete in Oracle Identity Manager, you must define the Period to Delay User Delete configuration property, which specifies the predefined wait period in days to hold on the delete operation. If you do not want to configure delayed delete, then set the value of the Period to Delay User Delete configuration property to 0 or a negative number. After a user is deleted, if you want to disable the user entity with a date counter that specifies the date and time when the user must be permanently deleted, then set the value of the Period to Delay User Delete configuration property to greater than 0.


Note:

To configure delayed delete:
  1. In the Welcome page for Oracle Identity Manager Administration, under System Management, click System Configuration.

  2. In the left pane, search for system properties.

  3. In the search result, select the Period to Delay User Delete property.

  4. Edit the property value to specify a delay period to delete the user.

  5. Save the property.

For more information about system properties, see "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.


As a result of delayed delete:

  • The disable status is similar to a regular disable operation that prevents the user from logging into Oracle Identity Manager and disables all provisioned resources.

  • When a user is in disabled status, enabling the user cancels the delete operation. The date on which the user will be deleted is displayed on the user profile.

  • If a user stays disabled and the predefined period expires, then the user is deleted at that time.

11.3.3.4 Bulk User Modifications

The bulk operations are performed from the search results for simple and advanced search. You can select multiple users and then select the available option from the Action menu. You can perform the following bulk operations:

  • Enabling users: If all the selected users are in Disabled state

  • Disabling users: If all the selected users are in Enabled state

  • Locking users: If all the selected user are in Unlocked state

  • Unlocking users: If all the selected users are in Locked state

  • Deleting users: If all the selected users are not in Deleted state


Note:

For all the bulk modify operations, you must have the required authorization and you must select multiple users.

You can use the Bulk Modify page to make changes to multiple users at a time. You can open this page if you are authorized to modify users as determined by the authorization policy on the Modify User Profile privilege on any organization in Oracle Identity Manager.

You can open the Bulk Modify page in any one of the following ways:

  • Selecting Bulk Modify from the Action menu in a user search results page, after selecting multiple users

  • Selecting the Bulk Modify icon on the toolbar in a user search results page, after selecting multiple users

Table 11-6 describes the fields in various sections of the Bulk Modify page:

Only those attributes configured as part of the modify operation in user management configuration are displayed as fields in the Bulk Modify page. The attributes displayed are restricted to those defined in the user entity definition with the Support Bulk Update property set to Yes. The attributes are further filtered based on authorization policies that specify the attributes for the selected users that you have privileges to modify.

The permissions are based on authorization policy. For instance, if the authorization policy mentions that you can modify only the first name for one user and only the last name for another user, based on the users selected, it is possible that you select these names and the attributes to display on the page, results in no fields being allowed. As a result, the Bulk Modify page displays an error message stating that the attributes of the selected users cannot be modified in bulk, and the user selection must be changed.

11.4 User Management Authorization

Run-time security is enforced in the user management service through authorization policies. Each role in Oracle Identity Manager can be associated with one or more such authorization policies. Users that are members of a role are authorized to perform various user tasks based on the privileges granted to the role by its associated authorization policies. Because a user may have many roles, the privileges of a user are the cumulative privileges of his collective roles.

The access controls are implemented in the form of authorization policies that are managed by the Oracle Entitlements Server (OES). These policies define the controls in terms of roles and targets. The target is a combination of privilege, entity, and entity attribute.


See Also:

Chapter 15, "Managing Authorization Policies" for detailed information about authorization policies in Oracle Identity Manager

If a user has multiple roles that have different authorization policies applicable in the same context, then the user's access rights are the cumulative rights across those policies. In other words, if a policy with read permission is granted to a role, and a policy with write permission is granted to another role, then a user with both the roles has read and write permission.

The authorization model is described in the following topics:

11.4.1 Privileges

All authorization privileges are controlled by authorization policies. Oracle Identity Manager explicitly defines privileges that control access rights for performing various operations in the application.

Table 11-7 lists the authorization privileges available in Oracle Identity Manager for the user management feature that and can be assigned to roles as part of an authorization policy definition:


Note:

For the Entity Instance Level, there must be a qualifier that determines over which users the logged in user has the privilege for all the privileges.

Table 11-7 Authorization Privileges for User Management

PrivilegeDescription

Search for Users

You can define this qualifier in terms of organizations, role memberships, or attribute-based rules. For information about defining this qualifier, see Chapter 15, "Managing Authorization Policies".

Note:

  • The "Search for Users" privilege depends on the "View User Details" privilege to determine which attributes can be included in the search results and which attributes can be included in the search criteria for a user search. Consequently, any User Management policy that provides the "Search User" permission should also provide the "View User Details" permission. The "View User Details" permission should include the User Login, Account Status, Identity Status, and Display Name attributes. If you do not provide these attributes, the user might not be fully viewable or editable.

  • To enable users to perform a search based upon an user attribute, you must also configure that attribute as "Searchable" in the user configuration.

There is a default authorization policy for the search operation that decides what the user can search. For information about default authorization policies for user management, see "User Management".

View User Details

This privilege determines if you have the ability to display the User Details page for a user from the search results table.

This privilege supports the following fine-grained controls:

  • Entity Instance Level: The qualifier can be defined in terms of the organization membership and/or the management chain. Refer "Creating an Authorization Policy for User Management" for details on how to define these qualifiers. Refer "Data Constraints" for information about data constraints used in authorization policies for user management.

  • Attribute Level: There must be qualifiers that determine your privilege to view attributes in the User Details page. This qualifier must list all the attributes from the user entity definition that you can view.

Note: The View User Details privilege cannot specify which detail sections can be viewed by the user. This privilege determines whether or not complete user details page with all sections can be viewed. If the user details page can be viewed, then this privilege determines which attributes are displayed in the Attribute Profile of a user.

Modify User Profile

This privilege determines if you have the ability to modify the user profile attributes of a user on the User Details page.

This privilege supports the following fine-grained controls:

  • Entity Instance Level: The qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

  • Attribute Level: There must be qualifiers that determine your privilege to modify attributes in the User Details page. This qualifier must list all the attributes from the user entity definition that you can edit. You must also grant the View User Details privilege for all these attributes.

Provision Resource to User

This privilege determines if you have the ability to provision or deprovision resources to a user on the Resource Profile section of the User Details Page. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Modify User Proxy Profile

This privilege determines if you have the ability to modify the user's proxy details on the Proxy Details section of the User Details page. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Modify User Status

This privilege determines if you have the ability to enable or disable a user. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Modify OIM Account Status

This privilege determines if you have the ability to lock or unlock a user. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Delete User

This privilege determines if you have the ability to delete a user. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Change Password

This privilege determines if you have the ability to change a user's enterprise password. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.

Create User

This privilege determines if you have the ability to create users in Oracle Identity Manager. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier must be defined in terms of organizations.

Evaluate Access Policies

This privilege determines if you have the ability to initiate access policy evaluation for a user when necessary.

Note: There is no UI operation to initiate on-demand access policy evaluation.

View User Requests

This privilege determines if you have the ability to view the requests raised for a user.

Change User Password

This privilege determines if you have the ability to change the password of a user. There must be a qualifier that determines over which users the logged in user has this privilege. This qualifier can be defined in terms of organizations, role memberships, or attribute-based rules.



Note:

The Modify Role Membership permission for role management determines if the user can perform add or remove role operations from the Roles tab of the modify user page. For more information about this permission, see "Managing Authorization for Roles".

11.4.2 Attributes

The read/write permissions for attributes define the actual set of readable or modifiable attributes in the context of the view or modify operation.

11.4.3 Data Constraints

The following data constraints are used in the authorization policies for user management:

  • List of organizations: This limits the scope of the privilege for the assignee to only the organizations listed. Organization membership can be controlled by the Hierarchy Aware option in the authorization policies UI.

    • When the Hierarchy Aware option is set to false, then the scope of the privilege is only to the users that are direct members of the organization. For example, if the organization is Development Center and it has USA Development Center and China Development Center as the suborganizations, then the privilege can be exercised against users that are directly under the Development Center organization.

    • When the Hierarchy Aware option is set to true, then the scope of the privilege is applicable to users who are direct members of the listed organization and the users who are members of any of the sub-organizations of these organizations. For example, if the organization is Development Center and it has USA Development Center and China Development Center as the suborganizations, then the privilege can be exercised against users in all of these organizations.

  • Assignee must be in the same organization: This flag limits the scope of the privilege for the assignee to only the assignee's organization. For example, the organization list in the policy is USA, China, and Canada. If this flag is set and the assignee's organization is USA, then the privilege can be exercised only in the USA organization.

  • Management chain of user: This flag limits the scope of the privilege for the assignee to only the assignee's direct and indirect reports. For example:

    DR1, DR2, and DR3 are direct reports of M1.

    DR1_1, DR1_2, DR1_3, and DR1_4 are direct reports of DR1.

    DR2_1, DR2_2, and DR2_3 are direct reports of DR2.

    DR2_2_1 and DR2_2_2 are direct reports of DR2_2.

    Here, M1 can exercise the privilege on all of DR1, DR2, and DR3 and their direct and indirect reports if the Management Chain of User option is selected.

11.4.4 Authorization with Multiple Policies

If a user has multiple roles that have different authorization policies applicable in the same context, then the user's access rights are the cumulative rights across those policies.

The authorization check for the Search for Users permission returns a list of obligations. This is a list of obligations from each applicable authorization policy. These obligations from multiple policies are combined to get a unified search result.

This section describes how obligations are handled for various user management operations. It contains the following topics:

11.4.4.1 Search Operation Authorization with Multiple Authorization Policies

There can be the following types of obligations for the search operation:

  • List of organizations: The list of organizations can be for direct or indirect organization membership, which is controlled by the Hierarchy Aware data constraint. A special value here can be list of all organizations in Oracle Identity Manager. The logged in user can search only within this set of organizations.

  • Is in the same organization: This obligation means that the logged in user can search for users only in the user's own organization.

  • Is in management hierarchy: This obligation means that the logged in user can search for any users in the user's management hierarchy.

  • Viewable Attributes: This obligation contains the list of authorized viewable attributes. The search operation can be performed only against these attributes.

If there are multiple authorization policies that grant the search privilege to a user, then the search behavior is as follows:

  1. The set of users who can be searched by the logged in user will be the union of set of users on which search privilege is provided by each of these policies.

  2. The set of attributes returned as part of the search results is the union of sets of attributes on which View User Details privilege is granted by each of the these policies.

This is described with the help of the following example:

Policy1 returns the First Name, Last Name, and Middle Name attributes, and Policy2 returns the User Login, User Type, and OIM User Type attributes. When obligations from both the policies are enforced, the returned attribute list is First Name, Last Name, Middle Name, User Login, User Type, and OIM User Type for all users. The policy due to which the user is selected as part of the results is not checked. Therefore, do not configure attributes from the configuration service that might display confidential data in the search results.

In an another example, suppose there are three authorization policies defined for the search operation. The following table lists the details of the sample authorization policies:

Policy NameEntity NamePermissionsData ConstraintsAssignment
Policy1User managementSearch

Modify User Profile. Attributes include First Name, Last Name, and Middle Name

View User Details. Attributes include Display Name, First Name, Last Name, and Middle Name

Users that are members of the Org1 and Org2 organizationsHierarchy Aware (include all Child Organizations) = TRUERole: Role1

Management Chain of User = FALSE

Assignee must be a member of the User's Organization = TRUE

Policy2User managementSearch

Modify User Profile. Attribute includes User Type

View User Details. Attributes include User Login, User Type, and OIM User Type

Users that are members of the Org3 organizationHierarchy Aware (include all Child Organizations) = FALSERole: Role2

Management Chain of User = FALSE

Assignee must be a member of the User's Organization = FALSE

Policy3User managementSearch

Modify User Profile. Attribute includes Designation

View User Details. Attributes include User Login, User Type, OIM User Type, and Designation

All UsersRole: Role2

Management Chain of User = TRUE

Assignee must be a member of the User's Organization = FALSE


In this example:

  • Org1 has Org1Child1 and Org1Child2 as child organizations.

  • Org1Child1 has Org1Child1_Child1 as the child organization.

  • Org3 has Org3Child1 and Org3Child2 as child organizations.

Consider the following scenarios:

Scenario I:

User1 has Role1 only and belongs to the Org1Child1 organization. The user can:

  • Search for users who are members of Org1Child1 organization. The search can be performed on the basis of First Name, Last Name, and Middle Name, and Display Name user attributes and also the search result can contain a subset of the set of these attributes.

  • Modify the First Name, Last Name, and Middle Name user attributes from the Org1Child1 organization.

Scenario II:

User2 has Role1 and Role2 and belongs to the Org2 organization. User2 has direct reports DR1 and DR2 belonging to the Org2 organization. The user can:

  • View the User Login, User Type, and OIM User Type user attributes from the Org3 organization because of Policy2.

  • Modify the User Type attribute from the Org3 organization because of Policy2.

  • View the First Name, Last Name, and Middle Name user attributes from the Org2 organization, because of Policy1.

  • Modify the First Name, Last Name, and Middle Name user attributes from the Org2 organization, because of Policy1.

  • View the User Login, User Type, OIM User Type, and Designation user attributes of all the user's direct reports because of Policy3.

  • Modify the Designation attribute of all the user's direct reports because of Policy3.

If the user being tried to modify is DR1, then the list of modifiable attributes are First Name, Last Name, Middle Name because of Policy1, and Designation because of Policy3.

The user cannot view, modify, and search users from child organizations of Org3, which are Org3Child1 and Org3Child2.

Based on these scenarios, for the search operation, a union of the viewable attributes from all the three authorization policies are displayed to the user. In other words, the user is able to see User Login, User Type, OIM User Type, First Name, Last Name, Middle Name, Display Name, and Designation attributes in the search results irrespective of the authorization policy. Here, the Designation attribute is displayed not only for DR1 and DR2, who are direct reports of User2, but are displayed for all the users in the results.

11.5 Username Reservation

A request for creating a user can be raised from Oracle Identity Manager Self Service or Oracle Identity Manager Administration. When the request is submitted, the following scenarios are possible:

  • While the request is pending, another create user request is submitted with the same username. If the second request is approved and the user is created, then the first request, when approved, fails because the username already exists in Oracle Identity Manager.

  • While the request is pending, another user with the same username is directly created in the LDAP identity store. When the create user request is approved, it fails while provisioning the user entity to LDAP because an entry already exists in LDAP with the same username.

To avoid these problems, you can reserve the username in both Oracle Identity Manager and LDAP while the create user request is pending for approval. If a request is created to create a user with the same username, then an error message is displayed and the create user request is not created.


See Also:

"Creating a Request To Create a User" for information about creating requests to create a user

For reserving the username:

If user attribute reservation is enabled, the reservation happens in two phases:

In the first phase, an entry is created in Oracle Identity Manager database and a user is created in reservation container. This entry in Oracle Identity Manager database is removed after successful creation of user, rejection by approver, or request failure.

In the second phase, in LDAP, on successful creation, the user is moved to the reservation container. In other cases such as rejection by approver or request failure, the user is removed from the reservation container.

After the request-level and operation-level approvals are obtained for the create user request, the username is no longer reserved in the username container in LDAP. The username is moved to the container in which the existing users are stored. The user is also created in Oracle Identity Manager.

This section consists of the following topics:

11.5.2 Configuring the Username Policy

Username Policy is a plugin implementation for username operations such as username generation and username validation. The policies follow Oracle Identity Manager plug-in framework. You can add your own policies by adding new plug-ins and changing the default policies from the System Configuration section in Oracle Identity Administration.


See Also:

"Developing Plug-ins" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the plug-in framework

In case of create user request, the plugins are invoked only if the user login is not provided. In such a case, the plugin to be invoked is picked up from the system property, "Default policy for username generation".

Table 11-8 lists the predefined username policies provided by Oracle Identity Manager. In this table, the dollar ($) sign in the username generation indicates random alphabet:

Table 11-8 Predefined Username Policies

Policy NameExpected InformationUsername Generated

oracle.iam.identity.usermgmt.impl.plugins.EmailUserNamePolicy

E-mail

If e-mail is provided, then e-mail is generated as username.

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstInitialLocalePolicy

First name, last name, and locale

last name + first initial_locale, last name + middle initial + first initial_locale, last name + $ + first initial_locale (all possibilities of single random alphabets), last name + $$ + first initial_locale

oracle.iam.identity.usermgmt.impl.plugins.FirstInitialLastNameLocalePolicy

Firstname, Lastname, Locale

first initial + lastname_locale, first initial + middle initial + first name_locale, first initial + $ + lastname_locale, first initial + $$ + lastname_locale

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstInitialPolicy

Firstname, Lastname

lastname+firstInitial, lastname+middleinitial+firstInitial, lastname+$+firstInitial ( all possibilities of single random alphabets) , lastname+$$+firstInitial

oracle.iam.identity.usermgmt.impl.plugins.FirstInitialLastNamePolicy

Firstname, Lastname

firstInitial+lastname, firstInitial+middleInitial+firstname, firstInitial+$+lastname, firstInitial+$$+lastname

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicy

Firstname, Lastname

lastname.firstname, lastname.middleinitial.firstname, lastname.$.firstname ( all possibilities of single random alphabets) , lastname.$$.firstname

oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicy

Firstname, Lastname

firstname.lastname, firstname.middleinitial.lastname, firstname.$.lastname (all possibilities of single random alphabets) , firstname.$$.lastname

oracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicy

E-mail

If e-mail is provided, then username is generated based on the e-mail. If e-mail is not available, then it generates username based on firstname and lastname by appending a user domain to it. The user domain is configured as the Default user name domain system property, and the default value is @oracle.com

oracle.iam.identity.usermgmt.impl.plugins.LastNamePolicy,

Lastname

lastname, middle initial + lastname , $ + lastname, $$ + lastname

oracle.iam.identity.usermgmt.impl.plugins.LastNameLocalePolicy

Lastname, Locale

lastname_locale, middle initial + lastname_locale , $ + lastname_locale, $$ + lastname_locale

oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyForAD

Firstname, Lastname

firstname+lastname, substring of firstname+lastname+$, substring of firstname+ substring of lastname+$

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicyForAD

Lastname, Firstname

lastname+firstname, lastname+substring of firstname+$, substring of lastname+ substring of firstname+$


Values must be provided for all the parameters of the username generation format. If any of the parameters are not provided, then Oracle Identity Manager generates an error. For example, If the firstname.lastname policy is configured and the firstname is not provided, then the error would be "An error occurred while generating the Username. Please provide firstname as expected by the firstname.lastname policy".

The UserManager exposes APIs for username operations. The APIs take the user data as input and return a generated username. The APIs make a call to plug-ins that return the username. This allows you to replace the default policies with custom plug-ins with your implementation for username operations.


Note:


You can plug-in your own username policies by implementing the plug-in interface, as shown:

package oracle.iam.identity.usermgmt.api;
public interface UsernamePolicy {
           public String getUserNameFromPolicy(HashMap<String, String> reqData) throws UserNameGenerationException;
        
          public boolean isUserNameValid(String userName, HashMap<String, String> reqData);
          public String getDescription(Locale locale);
}

This plug-in point is exposed as a kernel plug-in that takes request data as input and returns the username. Each plug-in expects some information and generates username based on that information provided. The policy implementations generate the username, check for its availability, and if the username is not available, then generate other username based on the policy in the order mentioned in Table 11-8, and repeat the procedure. The dollar ($) sign in the username generation indicates random alphabet. If any of the expected information is missing, then the policies generate errors.

The username generation is exposed as public APIs in User Manager. Oracle Identity Manager provides an utility class for accessing the functionality of generating user names. The class that contains utility methods is as shown:

oracle.iam.identity.usermgmt.api.UserManager

This class exposes the following main methods:

//Method that will generate username based on default policy
        public String generateUserName(HashMap<String, String> requestData) 
                                    throws UserNameGenerationException

//Method that will generate username based on policy
        public String generateUserName(String policyID, HashMap requestData)                                    throws UserNameGenerationException

//Method that will check whether username is valid against default policy
        public boolean isUserNameValid(String userName,                          HashMap<String, String> reqData)

//Method that will check whether username is valid against given policy
        public boolean isUserNameValid(String userName, String userNamePolicyPluginID, HashMap<String, String> requestData)

//Method to return all policies (including customer written)
        public List<Map<String, String>> getAllUserNamePolicies(Locale locale)

//Method that will return policy description in given locale
        public String getPolicyDescription(String policyID, Locale locale)

Table 11-9 lists the constants defined in the UserManager class to represent the policy ID of the default username policies:

When called to generate username, the policy classes expect the attribute values to be set in a map by using the key constants defined in the oracle.iam.identity.utils class.Constants. This means that a proper parameter value must be passed to call the method by using the appropriate constant defined for it, for example, the FirstName parameter has a constant defined for it.

The default username policy can be configured by using Oracle Identity Manager Administration. To do so:

  1. Navigate to the System Configuration section.

  2. Search for all the system properties.

  3. Click Default policy for username generation. The System Property Detail page for the selected property is displayed, as shown in Figure 11-8:

    The XL.DefaultUserNameImpl system property is provided for picking up the default policy implementation. By default, it points to the default username policy, which is oracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicy displayed in the Value field.

  4. In the Value field, enter oracle.iam.identity.usermgmt.impl.plugins.POLICY. Here, POLICY is one of the policy implementations.


    Note:

    All the plug-ins must be registered with Oracle Identity Manager by using the /identity/metadata/plugin.xml file. A sample plugin.xml file is as shown:
    <plugins pluginpoint="oracle.iam.identity.usermgmt.api.UserNamePolicy">        <plugin
    pluginclass="oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicy"
    version="1.0" name="LastNameFirstNamePolicy"/>
    </plugins>
    

  5. Click Save.

11.5.4 Configuring Username Generation to Support Microsoft Active Directory

In Oracle Identity Manager deployment with LDAP synchronization is enabled, where Microsoft Active Directory (AD) is the data store, the User Login attribute in Oracle Identity Manager is mapped to the uid attribute in LDAP, which in turn is mapped to the sAMAccountName attribute. The sAMAccountName attribute is used as login for all AD-based applications. There is limitation on the maximum length supported for value contained in the sAMAccountName attribute in AD. It cannot exceed 20 characters.

Oracle Identity Manager accepts user name as an input at the time of user creation and it can be more than 20 characters. Because AD does not support user name of more than 20 characters, Oracle Identity Manager can be configured to generate the user name, which consists of less than 20 characters.

When AD is used as data store, you can configure the autogeneration of user name by setting the value of the XL.DefaultUserNamePolicyImpl system property to any one of the following:

  • FirstNameLastNamePolicyForAD: Generates the user login by prefixing a substring from the first name to that of the last name

  • LastNameFirstNamePolicyForAD: Generates the user login by prefixing a substring from last name to that of the first name

See "Administering System Properties" for information about the XL.DefaultUserNamePolicyImpl system property and setting values of system properties.


Note:

If AD is the data store, then any one of the FirstNameLastNamePolicyForAD or LastNameFirstNamePolicyForAD policies must be used. Any other user name generation policy will fail to generate the user name.

11.6 Common Name Generation

The generation of the Common Name user attribute value in Oracle Identity Manager is described in the following sections:

11.6.1 Common Name Generation for Create User Operation

In an LDAP-enabled deployment of Oracle Identity Manager, Fusion applications such as Human Capability Management (HCM) does not pass the common name via SPML request. Given that the common name is a mandatory attribute in LDAP and Oracle Identity Manager is setup to use it as the RDN, Oracle Identity Manager must generate a unique common name.

Based on the description on Common Name, it is the user's display name consisting of first name and last name. Therefore, Oracle Identity Manager generates the Common Name with the help of a common name generation policy that specifies the Common Name in the "firstname lastname" format.

To configure common name generation in Oracle Identity Manager, set the value of the XL. DefaultCommonNamePolicyImpl system property to oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicy. For information about the XL. DefaultCommonNamePolicyImpl system property and setting the value of a system property, see "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

The following are the details of the FirstNameLastNamePolicy:

  • Expected information: Firstname, Lastname

  • Common Name generated: firstname.lastname, firstname.$.lastname (all possibilities of single random alphabets), firstname.$$.lastname and so on until a unique common name is generated


    Note:

    The common name must be reserved until the user is created by the request so that multiple requests generated simultaneously having same first and last names do not generate the same common name.

11.6.2 Common Name Generation for Modify User Operation

When the user profile ?is modified, one or more attributes can change. HCM cannot filter out and send only the modified data to Oracle Identity Manager because it does not have the old user attributes and cannot determine which ones are modified. Therefore, all attributes including the common name (CN) are passed to Oracle Identity Manager by the SPML request. Because the CN changed, Oracle Identity Manager attempts a modify operation (modrdn) in the directory resulting in DN change. Because of this unintended DN change, the group membership DN becomes stale resulting in the user loosing membership in that group. This subsequently results in authorization failure. This happens when referential integrity is turned off in the LDAP server, and therefore, the referenced groups are not updated when the RDN of the user changes. Therefore, referential integrity must be turned on in the target LDAP server. Otherwise, the group memberships become stale. The referential integrity issue is also applicable to roles. Groups are also members of other groups and any RDN changes must be reflected as well.

You can turn on the referential integrity by setting the value of the XL.IsReferentialIntegrityEnabled system property to TRUE. For information about this system property, see "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Table 11-10 lists the possible scenarios when RDN is modified:

PKi*PKj?OEBPS/workingrep.htm Using Reporting Features

20 Using Reporting Features

This chapter includes the following sections:

20.1 Reporting Features

The following are Oracle Identity Manager reporting features:

  • Select and view reports from a predefined list in the BI Publisher.

  • Filter report information.

  • View reports on-screen in the desired format.

  • Provide interactive reports.

20.2 Starting Oracle Identity Manager Reports

To start BI Publisher:

  1. Navigate to Start, Oracle BI Publisher Desktop, Oracle - BIPHome10134, and then click Start BI Publisher.

    The Oracle BI Publisher Home page appears.

  2. Enter the user name and password.

  3. Click Sign In.

20.3 Running Oracle Identity Manager Reports

To run a report:


Note:

BI Publisher cannot be accessed through the Oracle Identity Manager Administrative and User Console. You must open BI publisher explicitly to access the Oracle Identity Manager 11g reports.

  1. Start Oracle Identity Manager Reports. See Section 20.2, "Starting Oracle Identity Manager Reports" for more information.

  2. Click the more... link under Shared Folders.

  3. Do one of the following to access the reports.

    • Click Oracle Identity Manager Reports.

    • Click the more... link under Oracle Identity Manager Reports.

    The resulting page displays Oracle Identity Manager Reports classified according to their functional areas.

  4. To view a report:

    1. Select the report by clicking its name.

    2. Click View.

    The Report Input Parameters page is displayed. This page displays the input parameters that must be provided to run a report. The report input parameters act as a filter criterion.

    In some cases, at least one or more parameter fields are required fields. Some reports do not require any input parameter. If this is not the case, then you must populate at least one of the fields to run a report.


    Note:

    If you leave the input parameter field blank, and then click View, all the information associated with the report is displayed.

  5. Enter the information required to identify what information the report contains.

  6. Click View to run the report.

    The report is displayed.

20.4 Supported Output Formats

BI Publisher supports multiple report output formats. All reports are generated in a native XML format which can be transformed into different other output formats. The following formats are supported:

  • HTML

  • PDF

  • RTF

  • MHTML

20.5 Reports for Oracle Identity Manager

All the reports containing Date type input parameters, have the following default date range in the date type input parameters:

Date Range is : Sysdate-30 To Sysdate.

If you want to run the reports for different date range, then please change the date type input parameters with your date ranges.

Oracle Identity Manager Reports are now classified based on the functional areas. For instance, Access Policy Reports, Attestation, Request and Approval Reports, Password Policy Reports, and so on. It is no longer named Operational and Historical.

Oracle Identity Manager Reports are classified into the following categories based on their functional areas:

20.5.1 Access Policy Reports

Oracle Identity Manager BI Publisher Reports provides the following access policy reports for Oracle Identity Manager:

20.5.1.1 Access Policy Details

It provides administrators or auditors the ability to view a current snapshot of all the policies defined in Oracle Identity Manager system, along with key information about each policy, and the number of instances in which each policy has been activated.

Input Parameters

The following table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Access Policy NameName of the Access Policy

Fields

The following table lists the fields of the report:

Report FieldDescription
DescriptionDescription of the policy
Approval RequiredApproval required for the policy
Creation DateDate when the policy is created
Retrofit Access PolicyRetrofit of the access policy
Created ByName of the person who created the policy
PriorityPriority of the policy

Columns

The following table lists the columns of the report:

Report ColumnDescription
Resource NameName of the resource

20.5.1.2 Access Policy List by Role

It lists all policies defined in Oracle Identity Manager system by role. This report can be used for operational and compliance purposes.

Input Parameters

The following table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Role NameName of the role

Fields

The following table lists the fields of the report:

Report FieldDescription
DescriptionDescription of the policy
Approval RequiredApproval required for the policy
Creation DateDate when the policy is created
Retrofit Access PolicyRetrofit of the access policy
Created ByName of the person who created the policy
PriorityPriority of the policy

Columns

The following table lists the columns of the report:

Report ColumnDescription
Role NameName of the role

20.5.2 Attestation, Request, and Approval Reports

Oracle Identity Manager BI Publisher Reports provides the following attestation, request, and approval reports for Oracle Identity Manager:

20.5.2.1 Approval Activity

This report provides the administrators the ability to view the approval activity including requests that are approved, rejected, or pending.Z

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Approver's First NameFirst name of the approver
Approver's Last NameLast name of the approver
Approver's User IDUser ID of the approver
OrganizationName of the organization

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
Approver's First NameFirst name of the approver
Approver's Last NameLast name of the approver
Approver's User IDUser ID of the approver
OrganizationOrganization of the approver
Approval AcceptedCount of the accepted approval
Approval RejectedCount of the rejected approval
Approvals PendingCount of the pending approval
Approval Requests TotalTotal number of approval requests

20.5.2.2 Attestation Process List

This report displays details of all the attestation process. The security model is implemented in this report.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Attestation Process NameName of the attestation process
Attestation Process OwnerOwner of the attestation process

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
Attestation Process NameName of the attestation process
Owner User IDID of the owner of attestation process
Date of Current RequestData on which the request was made
Date of Last CompletionData on which the request was completed
CertifiedAttestation process certified
RejectedAttestation process rejected
DeclinedAttestation process declined
DelegatedAttestation process delegated
TotalSum of certified, rejected, and declined

20.5.2.3 Attestation Request Details

It lists details of selected Oracle Identity Manager attestation requests.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Attestation Process NameName of the attestation process
Attestation Request IDID of the attestation process
Request Initiation Date Range FromStart date of the attestation request
Request Initiation Date Range ToEnd date of the attestation request

Fields

The following table lists the fields of the report:

Report FieldDescription
Attestation Process NameName of the attestation process
Attestation Request IDID of the attestation request
Request Initiation DateDate on which the request is initiated
CompletionDate on which the request is completed
CertifiedAttestation process certified
RejectedAttestation process rejected
DelegatedAttestation process delegated
No ActionNumber of attestation processes on which no action is taken

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user who initiated the attestation request
Last NameLast name of the user who initiated the attestation request
User IDID of the user who initiated the attestation request
ResourceName of the resource
Descriptive DataDate on which the request is completed
Reviewer's First NameFirst name of the reviewer
Reviewer's Last NameLast name of the reviewer
Reviewer's User IDID of the reviewer
ActionAction taken by the reviewer

20.5.2.4 Attestation Requests by Process

This report displays details of all the attestation process and the request for each process, where the logged in user is a member of the administrator or the owner role of the attestation process.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Attestation Process NameName of the attestation process
Attestation Process OwnerOwner of the attestation process

Fields

The following table lists the fields of the report:

Report FieldDescription
Attestation OwnerName of the attestation process owner
Total Number of RequestsTotal number of requests
Last Completion DateDate by which attestation should be completed
Current Request Initiation DateDate on which attestation is initiated

Columns

The following table lists the columns of the report:

Report ColumnDescription
Request IDID of the attestation request
Initiation DateDate on which attestation is initiated
Completion DateDate by which attestation should be completed
CertifiedAttestation process certified
RejectedAttestation process rejected
DeclinedAttestation process declined
DelegatedAttestation process delegated
Total AttestedSum of certified records, rejected records and declined records

20.5.2.5 Attestation Requests by Reviewer

It displays list of attestation requests by reviewer. The report includes the number of requests associated with each reviewer and information about each request. In addition, it displays the time at which the request is created and completed.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Reviewer First NameFirst name of the reviewer
Reviewer Last NameLast name of the reviewer
Reviewer User IDUser ID of the reviewer

Fields

The following table lists the fields of the report:

Report FieldDescription
Reviewer 's First NameFirst name of the reviewer
Reviewer 's Last NameLast name of the reviewer
Reviewer 's User IDUser ID of the reviewer
Total Number of RequestsCount of requests to review

Columns

The following table lists the columns of the report:

Report ColumnDescription
Request IDID of the attestation request
Process NameName of the process
Initiation DateDate on which attestation is initiated
Completion DateDate by which attestation should be completed
CertifiedAttestation process certified
RejectedAttestation process rejected
DeclinedAttestation process declined
DelegatedAttestation process delegated
Total AttestedCount of requests to attest

20.5.2.6 Request Details

This report provides administrators the ability to view the details (requestor, current approver and so on) of all requests with the input current status. Additionally, this report displays the details of all users (user name, organization, manager details, user status and so on) that will be provisioned as a result of the request approval. This helps administrators in planning and prioritizing operational activities so that they may expedite the closure of pending requests.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Requestor User First NameFirst name of the requestor
Requestor User Last NameLast name of the requestor
Request User IDID of the requestor
Request IDRequest ID
Request Parent IDParent ID of the request
Request StatusStatus of the request
Request TypeType of the request
Request Date FromStart date of the request
Request Date ToEnd date of the request
Beneficiary User First NameFirst name of the beneficiary
Beneficiary User Last NameLast name of the beneficiary
Beneficiary User IDID of the beneficiary

Fields

The following table lists the fields of the report:

Report FieldDescription
Request IDRequest ID
Request TypeType of the request
Requester User IDID of the requester
Request DateDate on which request is initiated
Approver User IDID of the approver
Current StatusStatus of the request
Parent Request IDID of the parent Requester

Columns

The following table lists the columns of the report, if a beneficiary is present:

Report ColumnDescription
First NameFirst name of the beneficiary
Last NameLast name of the beneficiary
User IDID of the beneficiary
User TypeType of user
User StatusStatus of the beneficiary
OrganizationOrganization of the beneficiary
Request ValueRequest value of the resource

The following table lists the columns of the report, if a beneficiary is not present:

Report ColumnDescription
Request NameName of the request
Request ValueValue of the request

20.5.2.7 Request Summary

This report provides administrators the ability to view the current status of all requests raised in the specified time interval. This helps administrators in planning and prioritizing operational activities so that they may expedite the closure of pending requests.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Request TypeType of request
Request Date FromStart date of the request
Request Date ToEnd date of the request
OrganizationDetails of the organization

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
Request IDRequest ID
Parent Request IDID of the parent Requester
Request TypeType of request
Request StatusStatus of request
Requestor User IDID of the requestor
Beneficiary User IDID of the beneficiary
Request DetailsDetails of the request
Approver User IDID of the approver
Request DateDate of request

20.5.2.8 Task Assignment History

It lists the history of all task assignments.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:


Report ColumnDescription
User IDID of the beneficiary
Assignee First NameFirst name of the assignee
Assignee Last NameLast name of the assignee
Assignee User IDID of the assignee
Assignee Role NameRole name of the assignee
Assignee User NameUser name of the assignee
Employee TypeType of employee

20.5.3 Role and Organization Reports

Oracle Identity Manager BI Publisher Reports provides the following role and organization reports for Oracle Identity Manager:

20.5.3.1 Role Membership History

This report displays membership history of all the roles. The report will not show indirect memberships.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Role NameName of the role
Role CategoryCategory of the role
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor
Employee StatusStatus of the employee: Active, Disabled, Deleted, Disabled Until Start Date
Membership StatusStatus of membership: Revoked, Active
Effective FromRole membership effective from date
Effective ToRole membership effective to date

Fields

The following table lists the fields of the report:

Report FieldDescription
Created ByName of the person who created the role
Creation DateDate on which the role was created

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Employee TypeType of employee
Employee StatusStatus of the employee
Membership StatusMembership date of the user
Effective FromMembership start date of the user
Effective ToMembership end date of the user
Manager's First NameFirst name of the manager
Manager's Last NameLast name of the manager
Manager's User IDID of the manager

20.5.3.2 Role Membership Profile

This report shows number of users present for number of roles and the details of users belonging to count number of roles.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
OrganizationOrganization of the user

Fields

The following table lists the fields of the report:

Report FieldDescription
Membership in Number of RolesNumber of members in number of roles
Number of UsersNumber of users in the role

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

20.5.3.3 Role Membership

This report displays membership details of all roles.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Role NameName of the role
Role CategoryCategory of the role
OrganizationName of the organization
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor
Employee StatusStatus of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Fields

The following table lists the fields of the report:

Report FieldDescription
Created ByName of the person who created the user
Creation DateDate on which the user is created

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of user
Employee StatusStatus of the user
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor
Member SinceJoining date of the user
Manager's First NameFirst name of the manager
Manager's Last NameLast name of the manager
Manager's User IDID of the manager

20.5.3.4 Organization Details

It lists the hierarchical organization structure and details about users in the organization.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Organization NameName of the organization

Fields

The following table lists the fields of the report:

Report FieldDescription
Parent Organization NameName of the parent organization

Columns

The following table lists the columns of the report:

Report ColumnDescription
RoleName of Administrator User roles
First NameFirst name of the user in the organization
Last NameLast name of the user in the organization
User IDID of the user
User StatusStatus of the user
User TypeType of user
Start DateJoining date of the user
End DateLeaving date of the user

20.5.3.5 User Membership History

This report lists the logged in users with their membership history.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Last NameFirst name of the user
First NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee StatusStatus of the employee: Active, Disabled, Deleted, Disabled Until Start Date
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
User First NameFirst name of the user
User Last NameLast name of the user
OrganizationOrganization of the user
Employee StatusStatus of the employee: Active, Disabled, Deleted, Disabled Until Start Date
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Columns

The following table lists the columns of the report:

Report ColumnDescription
User RoleName of the user role
Membership StatusStatus of membership
Effective FromDate from which the membership is effective

20.5.4 Password Reports

Oracle Identity Manager BI Publisher Reports provides the following password reports for Oracle Identity Manager:

20.5.4.1 Password Expiration Summary

This report shows the list of all active users whose Oracle Identity Manager passwords are about to expire within a specified period.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Last NameLast name of the user
First NameFirst name of the user
User IDID of the user
OrganizationOrganization of the user
Expiration Date Range FromStart date of the expiration date
Expiration Date Range ToEnd date of the expiration date

Fields

N/A

Columns

The following table lists the columns of the report:

Report FieldDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Employee TypeType of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor
Employee StatusStatus of the employee: Active, Disabled, Deleted, Disabled Until Start Date
OrganizationOrganization of the user
Password Expiration DateDate on which the password expires

20.5.4.2 Password Reset Summary

This report provides the ability to view the aggregated metrics around password change attempts done by users themselves or on behalf of them. The metrics include all password change attempts, successful or failure outcome of password change attempt, users locked due to multiple concurrent unsuccessful password change attempts.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Aggregation FrequencyThe frequency of the report generated
Date Range FromStart date of the report generated
Date Range ToEnd date of the report generated
OrganizationName of the organization

Fields

The following table lists the fields of the report:

Report FieldDescription
Aggregation FrequencyThe frequency of the report generated

Columns

The following table lists the columns of the report:

Report ColumnDescription
Time PeriodDate and time of reset attempts performed
Reset AttemptsNumber of reset attempts
Failed Reset AttemptsNumber of failed reset attempts
Locked Users due to Failed Reset AttemptsNumber of users locked due to a failed reset attempt
Resets by non-beneficiaryNumber of resets by non-beneficiary

20.5.4.3 Resource Password Expiration

It lists users whose resource passwords will expire in a specified time period.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
User StatusStatus of the user
Password Expiration Date FromThe password expiry starting date
Password Expiration Date ToThe password expiry ending date

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report FieldDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
User StatusStatus of the user: Active, Disabled, Deleted, Disabled Until Start Date
User TypeType of the user: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor
Password Expiration DateDate on which the password expires

20.5.5 Resource and Entitlement Reports

Oracle Identity Manager BI Publisher Reports provides the following resource and entitlement reports for Oracle Identity Manager:

20.5.5.1 Account Activity In Resource

It lists all account activities in each resource. It also provides information on how each user is associated with a specific activity of that resource.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
Date Range FromDate from which reports are displayed
Date Range ToDate to which reports are displayed

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource NameName of the resource
Activity TypeThe type of activity
Resource Authorizer User Role(s)Name of the role which authorize the role
Resource Administrator User Role(s)Name of the role which authorize the resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
User StatusStatus of the user: Active, Disabled, Deleted, Disabled Until Start Date
OrganizationOrganization of the user
Manager's User IDID of the manager
TimestampDate when the report is created

20.5.5.2 Delegated Admins and Permissions by Resource

This report displays the list of user roles with write and delete access that are administrators of the resource.

Input Parameters

The table lists the report parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
Administrator Role NameName of the Administrator role
Administrator Role InformationInformation about the Administrator role
Read AccessIndicates whether the resource has read access
Write AccessIndicates whether the resource has write access
Delete AccessIndicates whether the resource has delete access
Authorizer RoleAuthorizer role name
Name PriorityPriority of the resource
Created ByName of the person who created the resource
Creation DateResource creation date

20.5.5.3 Delegated Admins by Resource

The report displays the list of user roles that are the administrators or authorizers of the resource and members of those roles.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
Resource TypeType of resource
Resource Audit ObjectiveObjective to carry out the audit for the resource

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource
TargetIndicates whether the resource is a target for organization or user
Write AccessIndicates whether the resource has write access
Delete AccessIndicates whether the resource has delete access
Creation ByResource creation source
Creation DateDate on which resource is created

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
User StatusStatus of the user
Member SinceJoining date of the user
Manager's First NameFirst name of the manager
Manager's Last NameLast name of the manager
Manager's User IDID of the manager

20.5.5.4 Entitlement Access List

This report provides administrators or auditors the ability to query all existing users, who have a specified entitlement. This report can be used for operational and compliance purposes.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Entitlement CodeCode of the entitlement
Resource NameName of the resource
OrganizationOrganization of the user
Role NameName of the role
User StatusStatus of the user: Active, Disabled, Deleted, Disabled Until Start Date
User TypeType of user
Provisioning Date FromDate from which the resource is provisioned to the user
Provisioning Date ToDate to which the resource is provisioned to the user

Fields

The following table lists the fields of the report:

Report FieldDescription
Entitlement CodeCode of the entitlement
Entitlement NameName of the entitlement
Entitlement statusStatus of the entitlement.
Resource NameName of the resource
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
User IdID of the user
First NameFirst name of the user
Last NameLast name of the user
User StatusUser Status
User TypeType of the user
OrganizationOrganization of the user
Valid To DateEntitlement valid from date
Valid From DateEntitlement valid to date

20.5.5.5 Entitlement Access List History

This report provides administrators or auditors the ability to query all existing users provisioned to a entitlement over its lifecycle. This is a lifetime report showing entire history of resource's access list or entitlements.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Entitlement CodeCode of the entitlement
Resource NameName of the resource
OrganizationOrganization of the user
Role NameName of the role
User StatusStatus of the user: Active, Disabled, Deleted, Disabled Until Start Date
User TypeType of user
Effective From DateEntitlement effective from date
Effective To DateEntitlement effective to date

Fields

The following table lists the fields of the report:

Report FieldDescription
Entitlement CodeCode of the entitlement
Entitlement NameName of the entitlement
Resource NameName of the resource
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
User IdID of the user
First NameFirst name of the user
Last NameLast name of the user
User StatusStatus of the user
User TypeType of user
Effective FromEntitlement effective from date
Effective ToEntitlement effective to date

20.5.5.6 Financially Significant Resource Details

This report provides Administrators to get a list of financially significant resources to prioritize various administrative and cleanup activities. It also helps Compliance or Privacy and Security officers assessing effectiveness of preventive and detective controls in financial significant resources and Auditors to understand the IT resources that host financial data.

Input Parameters

The table lists the report parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
User RolesLists the resource administrator user roles

20.5.5.7 Fine Grained Entitlement Exceptions By Resource

This report enables administrators, signing officers, internal and external auditors to analyze discrepancies in various process forms and related child tables of various resources and mitigate material weaknesses in the resources through remediation activities.

Input Parameters

The table lists the report parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Employee TypeType of the employee such as fulltime, part time
Organization NameName of the organization
Role NameName of the role

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource NameName of the resource
User IDID of the user

Columns

The following table lists the columns of the report:

Report ColumnDescription
Form NameName of the form
Form TypeType of the form


Note:

Before running this report, you must populate data for account audit and reconciliation exceptions.

To populate the data for account audit and reconciliation exceptions:

  1. Set the value of the system property, XL.EnableExceptionReports, to True.

  2. Provision an user to any target.

  3. Modify any of the user's attribute in the target and reconcile the user.

  4. Find data in UPA_UD_FORMFIELDS and UPA_UD_FORMS tables.

  5. Go to Oracle Identity Manger server and run RefreshMaterializedViewScheduler Task.

  6. Log in to BIP and view the report.

20.5.5.8 Offline Resource Provisioning Messages

Offline provisioning enhancement enables Oracle Identity Manager to do offline provisioning, enable, disable and revoke on resource instances that will improve the performance by parallel execution and also overcome transaction time-outs. This is achieved by submitting the JMS message when a specific action happens, the actual execution happens as a part of message processing. Such JMS message might be failed while processing due to some reasons. This report lists all the details of such failed off-line messages.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
User's First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Resource NameName of the resource
ActionAction taken by the resource
Date Range FromStart date
Date Range ToEnd date

Fields

The following table lists the fields of the report:

Report FieldDescription
User's First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Resource NameName of the resource
Resource DescriptionDescription of the resource
ActionAction taken by the resource
Request KeyKey of the request
Create DateProvisioning creation date

Columns

The following table lists the columns of the report:

Report ColumnDescription
ReasonReason of the offline resource provisioning
ExceptionException in the offline resource provisioning

20.5.5.9 Orphaned Account Summary

It lists the rogue accounts for the input resource for which a user existed in the target system, but the associated user to whom the account is provisioned never existed in Oracle Identity Manager.

Input Parameters

The table lists the report parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
Reconciliation Date Range FromStart date of reconciliation
Reconciliation Date Range ToEnd date of reconciliation

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
ResourceName of the resource
Account InformationInformation of the orphaned account
Reconciliation DateDate of reconciliation

20.5.5.10 Resource Access List History

This report provides administrators or auditors the ability to query all existing users provisioned to a resource over its lifecycle. This is a lifetime report showing entire history of resource's access list or entitlements.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
User StatusStatus of the user
User TypeType of the user
Snapshot Date FromEffective start date of resource access to the user
Snapshot Date ToEffective end date of resource access to the user
Changes Date FromResource changed from date to user
Changes Date ToResource changed to date to user

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Resource Descriptive dataDescription of the resource
User StatusStatus of the user
Resource StatusStatus of the resource
Effective FromEffective start date
Effective ToEffective end date

20.5.5.11 Resource Access List

This report provides administrators or auditors the ability to query all existing users provisioned to a specified resource. This report can be used for operational and compliance purposes.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
User StatusStatus of the user
User TypeType of the user
Provisioning Date FromResource provision start date
Provisioning Date ToResource provision end date

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
User TypeType of the user
User StatusStatus of the user
OrganizationOrganization of the user
Provisioning DateDate on which the resource is provisioned

20.5.5.12 Resource Account Summary

This report lists the number of users for each status within each resource.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
Resource TypeType of resource
Account StatusStatus of the account

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource
Total Number of UsersTotal number of users associated with the account

Columns

The following table lists the columns of the report:

Report ColumnDescription
Account StatusStatus of the account
Number of UsersNumber of users with that account status

20.5.5.13 Resource Activity Summary

It lists the history of all provisioning and approval activities for a resource.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
Date Range FromStart date
Date Range ToEnd date

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
Accounts ProvisionedNumber of accounts provisioned
Accounts De-ProvisionedNumber of accounts de-provisioned
Approval RequestsNumber of approval requests
Approval AcceptedNumber of approved requests
Approval RejectedNumber of rejected requests

20.5.5.14 Rogue Accounts By Resource

This report includes all rogue accounts for the input resource. This report also includes the corresponding attestation data to analyze if the rogue accounts represent outstanding or accepted exceptions in the system. This enables administrators, signing officers, internal and external auditors to identify material weaknesses in the resources and plan their mitigation through remediation activities.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
Resource NameName of the resource
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Organization NameOrganization of the user
User StatusStatus of the user
User TypeType of the user

Fields

The following table lists the fields of the report:

Report FieldDescription
Resource TypeType of resource

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
User StatusStatus of the user
User TypeType of the user
Exception TypeType of exception
Exception Approved in AttestationIndicates whether the exception is approved or not
Reviewer First NameFirst name of the reviewer
Reviewer Last NameLast name of the reviewer
Reviewer User IDUser ID of the reviewer

20.5.5.15 User Resource Access History

This report provides administrators or auditors the ability to view user's resource access history over user's lifecycle. This report can be used for compliance and forensic auditing purposes. This is not a user access profile snapshot report. This is a lifetime report showing entire history of user's entitlements.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
StatusStatus of the user
Employee TypeType of employee

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
User First NameFirst name of the user
User Last NameLast name of the user
Manager User IDID of the reporting Manager
Manager First NameFirst name of the reporting Manager
Manager Last NameLast name of the reporting Manager
OrganizationOrganization of the user
Employee StatusStatus of employee
Employee TypeType of employee
Identity Creation DateUser creation date

Columns

The following table lists the columns of the report:

Report ColumnDescription
Resource NameName of the resource
Resource Descriptive DataDescription of the resource
Provisioned DateDate on which the resource is provisioned
Provisioned ByName of the person who provisioned the resource
Effective FromEffective start date of resource access to the user
Effective ToEffective end date of resource access to the user

20.5.5.16 User Resource Access

This report provides administrators or auditors the ability to query all existing users provisioned to a specified resource. This report can be used for operational and compliance purposes.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee StatusStatus of employee
Employee TypeType of employee

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
User First NameFirst name of the user
User Last NameLast name of the user
Manager User IDID of the reporting Manager
Manager First NameFirst name of the reporting Manager
Manager Last NameLast name of the reporting Manager
OrganizationOrganization of the user
Employee StatusStatus of employee
Employee TypeType of employee
Identity Creation DateUser creation date

Columns

The following table lists the columns of the report:

Report ColumnDescription
Resource NameName of the resource
Resource Descriptive DataDescription of the resource
Resource StatusStatus of the resource
Provisioned DateDate on which the resource is provisioned

20.5.5.17 User Resource Entitlement

This report provides administrators or auditors the ability to query all existing entitlements provisioned to specific users. This report can be used for operational and compliance purposes.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
User IDID of the user
First NameFirst name of the user
Last NameLast name of the user
EmailEmail of the user
Resource NameName of the resource
OrganizationOrganization of the user
Role NameName of the role
User StatusStatus of the user
User TypeType of the user

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
First NameFirst name of the user
Middle NameMiddle name of the user
Last NameLast name of the user
EmailEmail of the user
OrganizationOrganization of the user
User StatusStatus of the user
User TypeType of the user
Manager First NameFirst name of the manager
Manager Last NameLast name of the manager
Start DateEntitlement of resource start date
End DateEntitlement of resource end date

Columns

The following table lists the columns of the report:

Report ColumnDescription
Entitlement CodeCode of the entitlement
Entitlement NameName of the entitlement
Entitlement StatusStatus of the entitlement
ResourceType of the resource
Provisioning StartDate from which the resource is provisioned to the user
Valid From DateEntitlement of resource valid start date

20.5.5.18 User Resource Entitlement History

This report provides administrators or auditors the ability to view user's resource entitlement history over user's lifecycle. This report can be used for compliance and forensic auditing purposes. This is not a user access profile snapshot report. This is a lifetime report showing entire history of user's entitlements.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
User IDID of the user
First NameFirst name of the user
Last NameLast name of the user
EmailEmail of the user
Resource NameName of the resource
OrganizationOrganization of the user
Role NameName of the role
User StatusStatus of the user
User TypeType of the user
Effective From DateResource entitlement effective start date
Effective To DateResource entitlement effective end date

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
First NameFirst name of the user
Last NameLast name of the user
User StatusStatus of the user
User TypeType of the user
OrganizationOrganization of the user
EmailEmail of the user
Start DateStart date of resource entitlement
End DateEnd date of resource entitlement
Identity Creation DateDate of identity creation
Manager First NameFirst name of the manager
Manager Last NameLast name of the manager

Columns

The following table lists the columns of the report:

Report ColumnDescription
Entitlement CodeCode of the entitlement
Entitlement NameName of the entitlement
ResourceType of the resource
Effective From DateResource entitlement effective start date
Effective To DateResource entitlement effective end date

20.5.6 User Reports

Oracle Identity Manager BI Publisher Reports provides the following user reports for Oracle Identity Manager:

20.5.6.1 User Profile History

This report shows all the users and their details based on the input parameters.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Role NameRole of the user
Manager User IDID of the Manager to whom the user reports
Employee StatusStatus of the user
Employee TypeType of employee
Changes Date Range FromEffective start date of the changes
Changes Date Range ToEffective end date of the changes
Snapshot Date Range FromEffective start date of resource access to the user
Snapshot Date Range ToEffective end date of resource access to the user

Fields

The following table lists the fields of the report:

Report FieldDescription
User IDID of the user
User First NameFirst name of the user
User Last NameLast name of the user
Manager User IDID of the reporting Manager
Manager First NameFirst name of the reporting Manager
Manager Last NameLast name of the reporting Manager
OrganizationOrganization of the user
Employee StatusStatus of employee
Employee TypeType of employee
Identity Creation DateUser creation date

Columns

The following table lists the columns of the report:

Report ColumnDescription
Profile ParameterName of user profile
ValueValue of user profile
Date Effective FromEffective from date
Time Effective FromEffective from time

20.5.6.2 User Summary

It lists all Oracle Identity Manager users created in a specified time period. In addition, it provides information on whether the users were created manually or through trusted reconciliation.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
Employee StatusStatus of the user
Employee TypeType of employee
Creation Date FromStart date of user summary
Creation Date ToEnd date of user summary

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee StatusStatus of the user
Employee TypeType of employee
Manager IDID of the Manager to whom the user reports
SourceUser creation source
Creation DateDate at which the user is created

20.5.6.3 Users Deleted

This report shows all the deleted users and their details based on input parameters.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee TypeType of employee
Deletion Date FromStart date of summary of deleted users
Deletion Date ToEnd date of summary of deleted users

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee TypeType of employee
Manager IDID of the Manager to whom the user reports
SourceUser creation source
Deletion DateDate at which the user is deleted

20.5.6.4 Users Disabled

This report provides the ability to view the details of users whose accounts are disabled. The account may be disabled for various reasons. For example, rejection in attestation, unsuccessful login or password reset attempts failure and so on.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee TypeType of employee
Disabled Date FromStart date of user disabled
Disabled Date ToEnd date of user disabled

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee StatusCurrent status of the employee
Employee TypeType of employee
Manager IDID of the Manager to whom the user reports
SourceUser creation source
Disabled DateDate at which the user is disabled

20.5.6.5 Users Unlocked

This report provides the ability to view the details of users whose disabled accounts are unlocked by administrators. Delegated administrators of the organizations to whom the user belongs may enable the accounts.

Input Parameters

The table lists the report input parameters used to specify a criterion for subsetting data:

Report ParameterDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee TypeType of employee
Unlocked Date FromStart date of user unlocked
Unlocked Date ToEnd date of user unlocked

Fields

N/A

Columns

The following table lists the columns of the report:

Report ColumnDescription
First NameFirst name of the user
Last NameLast name of the user
User IDID of the user
OrganizationOrganization of the user
Employee StatusStatus of the user
Employee TypeType of employee
Manager IDID of the Manager to whom the user reports
SourceUser creation source
Unlocked DateDate at which the user is unlocked

20.6 Exception Reports

In Oracle Identity Manager, exception refers to the difference between accounts that a user is entitled to and the accounts that are actually assigned to a user. The user is assigned these accounts as a result of access policies, provisioning of resources, approval requests, and reconciliation events. Any difference of these accounts assigned to a user in the target system and the ones assigned to the user in Oracle Identity Manager comprises an exception.

To populate the data for account audit and reconciliation exceptions report:

  1. Set the value of the XL.EnableExceptionReports system property to True. See "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about system properties.

  2. Verify that the Object Initial Reconciliation Date field of the resource object is earlier than the sysdate.

The following exception reports have been introduced in this release:

20.7 Creating Reports Using Third-Party Software

Oracle Identity Manager supports the creation of reports by using third-party tools such as Crystal Reports. You can use a third-party tool to create the reports listed in Section 20.5, "Reports for Oracle Identity Manager".


Note:

To learn how to create reports by using third-party software, see the third-party software documentation.

20.8 Required Scheduled Tasks for BI Publisher Reports

Table 20-1 lists the scheduled tasks required for Oracle Identity Manager BI Publisher reports:

PKcXPKj?OEBPS/partpage_con.htm Concepts

Part I

Concepts

This part introduces Oracle Identity Manager and describes the concepts related to Oracle Identity Manager.

It contains the following chapters:

PK3ٺPKj?OEBPS/idntmngr.htmYa Feature Overview

1 Feature Overview

Oracle Identity Manager is a user provisioning and administration solution, which automates the process of adding, updating, and deleting user accounts from applications and directories. It also improves regulatory compliance by providing granular reports that attest to who has access to what. Oracle Identity Manager is available as a stand-alone product or as part of Oracle Identity and Access Management Suite.

Automating user identity provisioning can reduce Information Technology (IT) administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Key features of Oracle Identity Manager include password management, workflow and policy management, identity reconciliation, reporting and auditing, and extensibility.

1.1 Features of Oracle Identity Manager

The features of Oracle Identity Manager can be divided into the following categories:

1.1.1 User Administration

By deploying self-service features and delegating administrative functions, an organization can increase user productivity, user satisfaction, and operational efficiency.

Oracle Identity Manager Self Service Profile Management

Users can view and edit their own profiles by using the self-service interface of Oracle Identity Manager. This reduces administrative overhead and provides users with control over their identity profiles.

Administrative Profile Management

You can view and manage the profiles of other users subject to access permissions by using the user interface for Oracle Identity Manager administration. This allows you to create and edit user profiles, change passwords of users, and perform other delegated administration tasks.

Request Management

The self-service interface also enables users to create provisioning requests for resources with fine-grained entitlements, profile management requests, and role membership requests. Business approvers, such as team leaders, line managers, and department heads, can use the same Web-based interface to examine and approve incoming requests. This helps organizations in reducing effort and cost.

Delegated Administration

Oracle Identity Manager features a highly flexible security framework that supports delegation of most administrative functions to any group or user. By moving administration points as close to the user as possible, an organization can achieve tighter control and better security, increasing productivity at the same time.

1.1.2 Workflow and Policy

The use of workflow and policy to automate business and IT processes can lead to improved operational efficiency, enhanced security, and more cost-effective compliance tracking. Oracle Identity Manager provides the following features in this category:

Policy Management

Oracle Identity Manager enables policy-based automated provisioning of resources with fine-grained entitlements. For any set of users, administrators can specify access levels for each resource to be provisioned, granting each user only the exact level of access required to complete the job. These policies can be driven by user roles or attributes, enabling implementation of role-based access control as well as attribute-based access control. Effective blending of role-based and attribute-based policies is key to a scalable and manageable organization provisioning solution.

A request goes through multiple approvals before it is executed. When the request is submitted, it must acquire approvals at different levels. An approval in the system can be configured by using an approval policy. An approval policy defines the approval process to be invoked and the approval rules associated with the policy. These approval rules help the request engine to select the approval process. Business analysts can define approval policies and approval rules.

Workflow Management

Oracle Identity Manager supports the separation of approval and provisioning workflows. An approval workflow enables an organization to model its preferred approval processes for managing resource access requests. A provisioning workflow enables an organization to automate IT tasks for provisioning resources with the most complex of provisioning procedures.

The separation of these two workflows empowers business and IT process owners to manage work efficiently with minimum cross-process interferences. It also enables an organization to leverage existing workflows already deployed in systems such as a help desk and HRMS. Oracle Identity Manager provides the Workflow Visualizer that allows business users, administrators, and auditors to visualize task sequences and dependencies to understand process flow and the Workflow Designer to edit and manage the process flow.

Dynamic Error Handling

The error-handling capability of Oracle Identity Manager enables you to handle exceptions that occur during provisioning. Frequent problems, for example, absence of resources, do not stop the entire provisioning transaction or cause it to fail. Business logic defined within the provisioning workflow offers customized fail-safe capabilities within an Oracle Identity Manager implementation.

Transaction Integrity

Based on embedded state management capabilities, Oracle Identity Manager provides the high level of transaction integrity required by other mission-critical organization systems. Oracle Identity Manager features a state engine with rollback and recovery capabilities. When a provisioning transaction fails or is stopped, the system is able to recover and roll back to the last successful state or reroute to a different path, in accordance with predefined rules.

Real-Time Request Tracking

To maintain better control and provide improved visibility into all provisioning processes, Oracle Identity Manager enables users and administrators to track request status in real time, at any point during a provisioning transaction.

1.1.3 Password Management

Password management is one of the foremost issues in organizations nowadays. Implementing a password management solution reduces cost and overhead related to raising tickets or calling help desks. The password management features of Oracle Identity Manager discussed in this section aim to help organizations in this area.

Self-Service Password Management

Users can manage their own enterprise passwords, which might then be synchronized with their managed accounts depending on how the managed accounts are individually configured. The enterprise passwords are managed by using the self-service capabilities of Oracle Identity Manager. If a user forgets the password, Oracle Identity Manager can present customizable challenge questions to enable self-service identity verification and password reset. Research shows that the bulk of help desk calls are related to password reset and account lockout. By reducing the need for help desk calls, this self-service capability lowers costs.

Advanced Password Policy Management

Most best practices are supported out of the box and are configurable through an intuitive user interface. Supported password complexity requirements include: password length, alphanumeric and special characters usage, uppercase and lowercase usage, full or partial exclusion of user name, minimum password age, and historical passwords. Oracle Identity Manager lets you define complex password policies that control the passwords set by users. In addition, Oracle Identity Manager allows the application of multiple policies for each resource. For instance, users with fewer privileges can be subjected to a more relaxed password policy, whereas privileged administrators can be subjected to a more stringent policy.

Password Synchronization

Oracle Identity Manager can synchronize or map passwords across managed resources and enforce differences in password policies among these resources. In addition, if an organization is using the desktop-based password reset feature of Microsoft Windows, the Active Directory (AD) connector of Oracle Identity Manager can intercept password changes at the AD server and subsequently propagate these changes to other managed resources in accordance with policies. Similar bidirectional password synchronization capability is offered in most Oracle Identity Manager connectors for directory servers and mainframes.

1.1.4 Audit and Compliance Management

Identity management forms a key component in any audit compliance solution of an organization. Oracle Identity Manager helps an organization to minimize risk and reduces the cost of meeting internal and external governance and security audits. This section discusses the features of Oracle Identity Manager that are listed in the audit and compliance management category.

Identity Reconciliation

Reconciliation is one of the significant capabilities of Oracle Identity Manager that enables it to monitor and track the creation, updation, and deletion of account across all managed resources. The process of reconciliation is performed by the reconciliation engine. If Oracle Identity Manager detects any accounts or changes to user access privileges are affected beyond its control, then the reconciliation engine can immediately take corrective action, such as undo the change or notify you. Oracle Identity Manager also helps you to detect and map existing accounts in target resources. This helps in the creation of an organization-wide identity and access profile for each employee, partner, or customer user.

Rogue and Orphan Account Management

A rogue account is an account created "out of process" or beyond the control of the provisioning system. An orphan account is an operational account without a valid owner. These accounts represent serious security risks to an organization. Oracle Identity Manager can monitor rogue and orphan accounts continuously. By combining denial access policies, workflows, and reconciliation, an organization can perform the required corrective actions when such accounts are discovered, in accordance with security and governance policies.

Service Accounts

Oracle Identity Manager can also manage the life cycle of special service accounts, also known as administrator accounts. These accounts have special life cycle requirements that extend beyond the life cycle of an assigned user and across the life cycles of multiple assigned users. Proper management of service accounts can help to eliminate another source of potential orphan accounts.

Comprehensive Reporting and Auditing

Oracle Identity Manager reports on both the history and the current state of the provisioning environment. Some of the identity data captured by Oracle Identity Manager includes user identity profile history, role membership history, user resource access, and fine-grained entitlement history. Oracle Identity Manager also captures data generated by its workflow, policy, and reconciliation engines. By combining this data along with identity data, an organization has all the required data to address any identity and access-related audit inquiry.

Attestation

Attestation, also referred to as recertification, is a key part of Sarbanes-Oxley compliance and a highly recommended security best practice. Organizations meet these attestation requirements mostly through manual processes based on spreadsheet reports and e-mails. These manual processes tend to be fragmented, are difficult and expensive to manage, and have little data integrity and auditability.

Oracle Identity Manager offers an attestation feature that can be deployed quickly to enable an organization-wide attestation process that provides automated report generation, delivery, and notification. Attestation reviewers can review fine-grained access reports within an interactive user interface that supports fine-grained certify, reject, decline, and delegate actions. All report data and reviewer actions are captured for future auditing needs. Reviewer actions can optionally trigger corrective action by configuring the workflow engine of Oracle Identity Manager.

1.1.5 Integration Solutions

A scalable and flexible integration architecture is critical for the successful deployment of organization provisioning solutions. Oracle Identity Manager offers a proven integration architecture and predefined connectors for fast and low-cost deployments.

Adapter Factory

Integrating most provisioning systems with managed resources is not easy. Connecting to proprietary systems might be difficult. The Adapter Factory eliminates the complexity associated with creating and maintaining these connections. The Adapter Factory provided by Oracle Identity Manager is a code-generation tool that enables you to create Java classes.

The Adapter Factory provides rapid integration with commercial or custom systems. Users can create or modify integrations by using the graphical user interface of the Adapter Factory, without programming or scripting. When connectors are created, Oracle Identity Manager repository maintains their definitions, creating self-documenting views. You use these views to extend, maintain, and upgrade connectors.

Predefined Connectors

Oracle Identity Manager offers an extensive library of predefined connectors for commercial applications and other identity-aware systems that are used widely. By using these connectors, an organization can get a head start on application integration. Each connector supports a wide range of identity management functions. These connectors use the most appropriate integration technology recommended for the target resource, whether it is proprietary or based on open standards. These connectors enable out-of-the-box integration between a set of heterogeneous target systems and Oracle Identity Manager. Because the connectors provide a set of components that were originally developed by using the Adapter Factory, you can further modify them with the Adapter Factory to enable the unique integration requirements of each organization.

Generic Technology Connectors

If you do not need the customization features of the Adapter Factory to create your custom connector, you can use the Generic Technology Connector (GTC) feature of Oracle Identity Manager to create the connector. For detailed information about GTC, see "Generic Technology Connectors".


See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for more information about generic technology connectors

1.1.6 User Provisioning

Provisioning provides outward flow of user information from Oracle Identity Manager to a target system. Provisioning is the process by which an action to create, modify, or delete user information in a resource is started from Oracle Identity Manager and passed into the resource. The provisioning system communicates with the resource and specifies changes to be made to the account.

Provisioning includes the following:

PK˛YYPKj? OEBPS/req.htm Managing Request Templates

17 Managing Request Templates

A request template lets you customize a request type for a purpose. In other words, it allows you to control the attributes of the request by controlling the various capabilities in the UI. For instance, if you want to create requests for user creation for all contract employees and specify an attribute to have a particular value, then you can customize the Create User request type to create a request template that allows customization of the request. By creating the request template, you can specify that the organization for all employees must be XYZ Inc. or the user type of all contract employees must be Part-time Employee.

Access to templates for request creation is based on the role assignment defined in the template. After creation of a request template, it is available only to the users with the roles that are assigned to the template.

A default template is shipped predefined for each of the request type. These predefined templates can not be deleted or renamed. Names of these predefined templates is same as corresponding models.

You can use a request template for the following purposes:

To summarize, the following are achieved by using the request template:

The template management service internally uses Oracle Entitlements Server (OES) for determining who can perform what operations. The OES policy for request template authorization specifies that only users with the REQUEST TEMPLATE ADMINISTRATORS role are authorized to create or clone, search, modify, and delete request templates. See ""Request Creation By Using Request Templates"" for information about the authorization policy for request templates.

This section discusses the following topics:

17.1 Creating Request Templates

As a user belonging to the REQUEST TEMPLATE ADMINISTRATORS role, you can create a request template by using the Create Request Template wizard in the UI for request management. Steps in the wizard are dynamically generated based on the selection of the request type in the first step and the selection of resource for resource-based request types.

Creation of request templates is described with the help of the following scenarios:

17.1.1 Creating a Request Template Based on the Create User Request Type

To create a request template based on the Create User request type:

  1. Log in to Oracle Identity Manager Administrative and User Console with credentials that have the permission to create a request template.


    Note:

    The user who is a member of the REQUEST TEMPLATE ADMINISTRATORS role is allowed to create a request template. If the appropriate role is not assigned to the user, then the required UI options for creating a request template will not be available to the user.

  2. Click Advanced to open Oracle Identity Manager Advanced Administration.

  3. Click the Configuration tab, and then click Request Templates. Alternatively, you click the Search Request Templates link under Configuration in the Welcome page.

  4. On the left pane, from the Actions menu, select Create. Alternatively, you can click the Create Request Template icon on the toolbar. The Set request template details page of the Create Request Template wizard is displayed.

  5. Enter values for the following fields, and then click Next.

  6. On the Select Attributes to Restrict page, select the attributes of the Create User type for which you want the user to enter values. Attributes that are restricted by the request templates are either not shown to the user, or the user is only allowed to select from predefined LOVs. User cannot enter any values. Figure 17-2 shows the Select Attributes to Restrict page:

    This page displays the attributes based on the dataset for Create User request type. If a request is created by using the Create User request template, then you can specify values for all these default attributes. If you want to restrict some of these attributes and want the requester to enter values for a few attributes, then you can select those attributes in this page. For example, you can select Middle Name because a value for this attribute must be specified. In this example, you can select the Middle Name, Organization, User Type, User Manager, and Country attributes.


    Note:

    • Even if a dataset attribute is configured with a PrePopulationAdapter, it can be restricted in a request template. In such case, pre-population will not happen and the values restricted in template will be shown in Request creation UI. Hence, if pre-population is required for an attribute, it should not be restricted in the template.

    • As mentioned earlier in this section, the steps in the wizard are dynamically generated based on the request type and the resource selection for resource-based request types. The steps are indicated on the top of the tab.


  7. On the Set Attribute Restrictions page, specify restrictions on the attributes that you selected in the Select Attributes to Restrict page. To specify restrictions:


    Note:

    This step is generated only if there are any attributes specified in the corresponding request data set.

    1. For the User Login attribute, select any one of the following:

      - Do not allow users to enter values for this attribute: Select this option if you do not want the user to specify a value for the attribute. On selecting this option, the attribute will not be displayed in the UI when creating the user. This option is not displayed for a mandatory attribute because a value must be specified for a mandatory attribute.

      - Restrict this attribute to the following values: Select this option if you want to specify one or more values for the attribute. For example, if you specify a value for the Department Number attribute, such as Software Engineering, then the default value of the attribute is set to Software Engineering, and the attribute is not displayed in the UI when creating a request by using this template. You can also specify multiple values for the attribute by using the + (plus) icon. On specifying multiple values, the values are available to the user as LOVs when creating a request by using this template, from which the user can select a value.


      Tip:

      These options are displayed for the Department Number attribute because the attribute is specified as a text box in the request dataset. For information about request datasets, see "Step 1: Creating a Request Dataset for the Resources" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

    2. Specify one or more values for the Organization attribute. To do so, click the search icon next to the Organization field, select one or more organization names from the Available Organizations list, and clicking the Move button.


      Tip:

      The Organization attribute is displayed as a field for which you must select a value by searching the existing organization names because this attribute is specified as an entity in the request dataset. This is a dynamic LOV because organizations can be created in Oracle Identity Manager. For information about request datasets, see "Request Dataset" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

    3. Specify a value for the User Type attribute. To do so, select one or more values from the Available User Type list, and click the Move button.


      Tip:

      The User Type attribute is displayed as a static LOV because this attribute is specified as a static LOV in the request dataset. This is a static LOV because the user must select from the available user types and cannot create new user types. For information about request datasets, see "Step 1: Creating a Request Dataset for the Resources" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

    4. Specify values for the User Manager and Country attributes, and click Next.

      Figure 17-3 shows the Set Attribute Restrictions page:


    Note:

    Steps 5, 6, and 7 are common for all request templates creation.

  8. On the Set Additional Attributes page, you can specify additional information about attributes, which need to be collected based on the template that you are creating but are not used for the purpose of entity mapping.


    Note:

    The Additional Attribute Data is not used during request execution. This data is also not displayed to the approver.

    In this example, specify date of birth as the additional attribute name. Select the Data Type as Number and Display Type as Text Field, and then click Add. You can specify multiple attributes by clicking the Add button. When finished, click Next.


    See Also:

    "Step 1: Creating a Request Dataset for the Resources" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for more information about the additional attributes that are not mapped to the underlying Oracle Identity Manager entity

    Figure 17-4 shows the Set Additional Attributes page:

  9. On the Set Template User Roles page, you can select one or more roles, for example, AD Administrators, whose members are allowed to create requests by using the template that is being created. In this example, from the Available Roles list, select a role such as Contractor Administrators. Click Move to include the selected roles in the Selected Roles list, and then click Next.


    Note:

    Only members of the selected roles are allowed to create requests using the request template. This is governed by the authorization policy for creating requests by using request templates. See ""Request Creation By Using Request Templates" for information about creating a request by using request templates.

    Figure 17-5 shows the Set Template User Roles page:

  10. On the Review Request Template Summary page, as shows in Figure 17-6, review the data that have been entered for Request Template Name, Request Type, Description, and Template Level Approval Process, and then click Finish.

  11. Click OK to confirm the template creation.

In the Create Request Template wizard, the following steps are common irrespective of the request type that you select or the request dataset that you define:

  • Request details to be specified in the Set request template details page. See step 5 in the create request templates.

  • Setting additional attributes in the Set Additional Attributes page. See step 8.

  • Setting roles for the template in the Set Template User Roles page. See step 9.

  • Request template information in the Review Request Template Summary page. See step 10.

17.1.2 Creating a Request Template Based on the Provisioning Resource Request Type

The Provision Resource default request template that is based on the Provision Resource request type can be used for provisioning resources to users. But if you want to customize the request creation for provisioning specific resources to users, then you can create a request template, which is based on the Provision Resource request type.

To create a request template based on the Provisioning Resource request type:

  1. In Oracle Identity Manager Advanced Administration, click the Configuration tab, and then click the Request Templates tab. Alternatively, you click the Search Request Templates link under Configuration in the Welcome page.


    Note:

    The user who is a member of the REQUEST TEMPLATE ADMINISTRATORS role is allowed to create a request template. If the appropriate role is not assigned to the user, then the required UI options for creating a request template will not be available to the user.

  2. On the left pane, from the Actions menu, select Create. Alternatively, you can click the Create a Request Template icon on the toolbar. The Set request template details page of the Create Request Template wizard is displayed.

  3. Enter values for the following fields, and then click Next.

  4. In the Select Allowed Resources page, click Search to search for all the available resources.

  5. From the Available Resources list, select one or more resources, and then click Move to include the selected resources in the Selected Resources list. In this example, select the E-Business RO resource, and then click Next.


    Note:

    • Only the resources that you select in this step are displayed to the requester during request creation by using this template. If you do not select a resource here, then all the resources in Oracle Identity Manager are displayed while creating the request.

    • If no entity type is restricted in the template, then all the available entity types are shown to the requester while creating request using this template.


  6. In the Select Attributes to Restrict page, select the attributes associated with the E-Business resource that you want to restrict. These attributes are defined in the request dataset for provisioning the E-Business resource. See "Step 1: Creating a Request Dataset for the Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for more information about attributes.

    If you select multiple resources in the Select Allowed Resources page, then the attributes associated with all the resources are displayed in the Select Attributes to Restrict page. Select the attributes for all the resources that you want to restrict, and then click Next.

  7. In the Set Attribute Restrictions page, specify values for the attributes whose values you want to restrict. For example, for the Fax attribute, select the Do not allow users to enter values for this attribute option if you do not want the user to specify a value for the attribute. Otherwise, select the Restrict the attribute to the following values option and specify one or more values for the Fax attribute. For information about these options and setting restrictions for attributes, see "Creating a Request Template Based on the Create User Request Type".

    Note that the Do not allow users to enter values for this attribute option is not available for the Server and Life Span Type attributes. This is because these attributes are specified as required in the request dataset. For information about the required property, see "Creating a Request Template Based on the Create User Request Type" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

    Select restriction values for all the attributes, and then click Next.


    Tip:

    If you are creating a request template for a request to provision multiple resources to users, click the Next Resource and Previous Resource buttons to set attribute restrictions fYbor all the resources.


    Note:

    Attributes coming up as shuttle on attribute restrictions page will show upto 200 results at a time. You need to provide appropriate search pattern to get relevant search results.

  8. Perform steps 8 through 10 of the procedure in "Creating a Request Template Based on the Create User Request Type" to complete the wizard.


    Note:

    In the Create Request Template wizard, the steps to select resources and set attribute restrictions vary based on the request type. The rest of the steps are similar.

While creating a request template, if you select a resource that does not have a request dataset defined, then you are not allowed to restrict the attributes to collect from the user. This is because there is no information specified about the data that is to be collected from the user for the selected resource. As a result, the Step 3: Attributes and Step 4: Restrictions in the Create Request Template wizard are not applicable because the attributes in these steps are defined by the request dataset, in the absence of which, there is no data to restrict. However, when you select a resource that does not have a request dataset, the Service Account attribute is displayed in the Step 3: Attributes because this attribute is defined by the common request dataset. See "Common Request Dataset" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about common request dataset.

17.2 Searching and Modifying Request Templates

Oracle Identity Manager Administration allows you to perform simple and advanced search for request templates, if you have the privileges of the REQUEST TEMPLATE ADMINISTRATOR'S role.

To perform a simple search for request templates:

  1. In Oracle Identity Manager Advanced Administration, click the Configuration tab, and then click the Request Templates tab. Alternatively, you click the Search Request Templates link under Configuration in the Welcome page.

  2. In the left pane of the Request Templates section, enter a search criteria in the Search field. You can use the asterisk (*) wildcard character in the Search field.


    Note:

    In simple and advanced search for request templates, searching with translated request template name is not supported. For default request templates, you can search only with English template names as stored in the database. However, if you create a request template by specifying its name in another language, then you can search it using the same string, and not in any other language.

  3. Click the icon next to the Search field to display a list of default and nondefault request templates.

    All the default request templates are blank templates without any customization on top of the request types. Table 17-1 lists the default request templates:


    Note:

    Each request template mentioned in Table 17-1 has a default callback policy which are used by SPML webservice.

To perform an advanced search for request templates:

  1. In the left pane of the Request Templates section, click Advanced Search. The Advanced Search: Request Templates page is displayed.

  2. Select any one of the following matching options:

    • All: On selecting this option, the search is performed with the AND condition. This means that the search result shows request templates when all the search criteria specified are matched.

    • Any: On selecting this option, the search is performed with the OR condition. This means that the search result shows request templates when any search criteria specified is matched.

  3. Specify values in the fields as search criteria. For each field, select an operator, such as Equals, Contains, or Begins with.

  4. Click Search. The search results table is displayed with details about the request template name, request type, approval process, and description.

To modify a request template:

  1. Select a template name in the search results table. From the Actions menu, select Open. The Template Details page is displayed with the details about the template.

  2. In the Template Details section, the details of the template are displayed in the fields, as shown in Table 17-2:


    Note:

    Modification of Request Template Name and Request Type are not supported, and therefore, these fields are shown as non-editable in the template details.

After you create a request template, and search for the request templates, the template that you created is also displayed in the search results table on the left pane. You can view the details of the template that you created. For example, if you select the Create Contractor request template and select Open from the Actions menu, then the Template Details page for the Create Contractor request template is displayed.

Note that the tabs that are displayed in the Template Details section correspond to the steps in the Create Template wizard. Similar to the steps in the wizard, the tabs in the Template Details page are dynamically generated, and each tab correspond to a step in the Create Template wizard. In general, the Request Template Details page has the following tabs:


Note:

These tabs are dynamically generated based on the request type that is associated with the request template. In other words, each tab that is displayed in the Request Template Details page corresponds to a step in the Create Request Template wizard.

17.3 Cloning Templates

Cloning a request template is the procedure to create a new request template by inheriting all the properties of an existing request template.


Note:

The Request Type field cannot be modified while cloning a template. The Request Type of the new template will be the same as the existing template.

To clone a request template:

  1. Go to Oracle Identity Manager Advanced Administration.

  2. From the advanced search results in the Template Details page, select a request template that you want to clone.

  3. From the Actions menu, select Clone. The Clone Template page is displayed with the details of the request template that you have selected for cloning.

  4. Modify the required details of the request template for creating the new request template.

  5. Click Save to create the new request template.

17.4 Deleting Templates

To delete a template as a member of the Templates Administrators role:

  1. In the Request Templates tab in Oracle Identity Manager Advanced Administration, search for the existing request templates.

  2. From the search results table, select the template that you want to delete.

  3. From the Actions list, select Delete. A message box is displayed that asks for confirmation.

  4. Click Yes to confirm.


Note:

If the template to be deleted is referred by any existing request, then it cannot be deleted. Attempting deletion of such template displays an error message in the UI.

PKcYPKj?OEBPS/part_rep.htmf Reporting

Part V

Reporting

This part describes Oracle Identity Manager delegated administration functionalities by using the reporting features in the following chapter:

PK|ƸkfPKj?OEBPS/req_mangmnt_user.htm Managing Requests

10 Managing Requests

In Oracle Identity Manager, various operations, such as creating a user or provisioning a resource, can be performed through requests. A request is an entity created by the users or administrators performing a specific action that requires a discretionary permission to be gained by someone or some process before the action can be performed. For example, a user can create a request to gain access to a laptop computer and a manager can create an open requisition based on the request.

A request has a requester, a beneficiary (optional), and a target entity. A requester is an entity that creates or raises a request. A requester can be a user or the system itself. The functional component decides on the requester for system-generated requests. An example of a system-generated request is a request created by the system based on access policy. Here, the functional component is access policy. For unauthenticated requests, the requester is not authenticated to Oracle Identity Manager and is therefore, not present in the system.

A beneficiary is an entity that benefits from the action performed after the request is completed and the request is completed only if it is executed successfully.

In Oracle Identity Manager, terms such as user, organization, roles, and resources are defined as entities. Each one of these entities maintains a list of attributes belonging to this entity. Each entity also defines a list of operations that it supports. Along with an operation, a subset of the entity attributes is specified as operational parameters to carry out that particular operation. Target entity is the resource that is requested for the beneficiary.

For instance, you create a request to provision a UNIX account for the user John Doe. Here, you are the requester, John Doe is the beneficiary, and the UNIX account is the target entity that is requested for John Doe.

Each request goes through a specific lifecycle after it is created in the system. This lifecycle is managed and controlled by the Request Service. The lifecycle transitions the request through various stages. The stage that a request is in determines what action the controller takes in that step, what operations are available on the request, and what possible stage the transitions are in at that time. Figure 10-1 outlines the process flow of a request:

Figure 10-1 Request Process Flow

Description of Figure 10-1 follows

The request process flow is described with the help of an example of provisioning a laptop computer to a user through a request. The steps are:

  1. The requester raises a request to assign a laptop computer to a user by using the Request UI.


    Note:

    Requests can be raised by using Oracle Identity Manager Self Service or Oracle Identity Manager Identity Administration.

  2. The request is submitted to the request service.

  3. The request is also stored in Oracle Identity Manager database.

  4. Template-Level Approval workflow is initiated by request service in Service-Oriented Architecture (SOA).

  5. If the template has approval process, then approval workflow at the template level gets initiated. If the template has no approval process, then the request gets auto approved.

  6. Request-Level Approval workflow is initiated by request service in Service-Oriented Architecture (SOA). Based on the workflow configuration, associated tasks are assigned to the corresponding approvers.


    See Also:

    "Approval Workflows" for information about approval levels and approval workflows in the Oracle identity Manager Developer's Guide

  7. The request-level approver approves the request by using the TaskList in Oracle Identity Manager Self Service. In this example, the requester's manager (Approver 1) is the request-level approver who decides whether to assign a laptop to user 1. If the request-level approver rejects the request, the request goes to a Rejected stage.

  8. If the Approver1 has designated his role to Approver 2 then Approver 2 is the request-level approver who decides whether to assign a laptop to user 1. If Approver 2 rejects the request, the request goes to a Rejected stage.

  9. The operation-level approver approves the request by using the TaskList. In this example, the IT admin for the organization is the operation-level approver (Approver 2) who is responsible for issuing a laptop to the user. If the operation-level approver rejects the request, then the request goes to a Rejected stage.


    Note:

    Operation-level request is not initiated if the request is rejected at the request level.

  10. The request operation is initiated in the request service, and the request is executed.

  11. The request operation is completed. At this stage, the request operation has the Completed status.

  12. The request status is updated in Oracle Identity Manager database.

This chapter describes request management in the following sections:

10.1 Request Stages

Each request goes through a specific lifecycle after it is created in the system. This lifecycle is managed and controlled by the request service. The lifecycle transits the request through various stages. The stage a request is in determines what action the controller takes in that step, what operations are available on the request at that time, and what the possible stage transitions are. Figure 10-2 outlines the lifecycle flow of a request in the request service:

Figure 10-2 shows all the stages that a request can go through. This diagram specifies stages for a simple request. For information about bulk request, refer to Figure 10-3, "Bulk Request and Child Request Stages".

Each stage represents the logical next step in the request lifecycle. Only the successful execution of an operation can take the request from one stage to the next.

Table 10-1 describes how a request functions at various stages through its life cycle and how a request attains these stages:

Table 10-1 Request Stages

Request StageDescription

Created

After successful submission of the request, the request moves to the Created stage.

Obtaining Approval

After the request attains the Submitted stage, request engine moves the request to "Obtaining Approval" stage automatically if there are approvals defined for this request. At this stage, the request engine looks at the request template first to find if there are any approvals defined. If it finds any, then the corresponding approvals are initiated through the request service. Upon completion of the same, the request engine looks at the model defined for this request to find out the approval selection methodology to find out the exact approval process to instantiate.

When the request engine finds out the approvals that are required to be initiated, it again calls request service to instantiate the workflow.

If a request is withdrawn or closed at this stage, then the request engine calls cancel workflow on each workflow instance. Notifications are sent to approvers about the withdrawn tasks.

Note: Configuration of notification can be done in the human task of a SOA composite.

The following request statuses are associated with Obtaining Approval stage:

  • Obtaining Template Approval

  • Obtaining Request Approval

  • Obtaining Operation Approval

For information about these request statuses, refer "Bulk Requests and Child Requests".

After the request successfully completes these statuses, it will attain the Request Approved stage.

If a validation check is plugged-in after the request has been successfully created, the request is associated with the following statuses.

  • SoD check not initiated

    A request attains this stage, if the SoD validation is not initiated for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check initiated

    A request attains this stage, if the SoD validation is initiated asynchronously for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check completed

    A request attains this stage, if the SoD validation is completed for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

Note: These request statuses are possible in case the request is provision resource request or modify provision resource request.

Approved

Only after an Operation Approval is approved, the request is moved to the next stage and the request engine is updated with the current status. The outcome that the request engine finds is Approved, Rejected, or Pending.

The following request statuses are associated with this stage:

  • Template Approval Approved

  • Request Approval Approved

  • Operation Approval Approved

Rejected

Each time a workflow instance is updated, request service updates the request engine with the current status of that instance. The outcome that the request engine expects from request service is Approved or Rejected. If any of the workflow instances that are instantiated are rejected, then request engine moves the request to Rejected stage. If any workflow instance is rejected, then the controller calls cancel on all the pending workflows and moves the request to Rejected stage.

The following request statuses are associated with this stage:

  • Template Approval Rejected

  • Request Approval Rejected

  • Operation Approval Rejected

Operation Initiated

After the request is approved, the request engine moves the request to the Operation Initiated stage and initiates the operation.

The following request statuses are associated with this stage:

  • Operation Completed

    After completing the actual requested operation, the request engine moves the request to the Operation Completed stage. This happens after Operation Initiated status and is associated with Completed stage.

  • Post Operation Processing Initiated

    After the actual requested operation is completed, if there exists any additional operation that needs to be executed as post-processing, the request engine moves the request to the Post Operation Processing Initiated stage, before initiating those operations. This happens after Operation Completed status.

Failed

When the associated operations specified in the request fails to execute, the request cancels any pending operations and moves the request to the Request Failed stage. The request statuses associated with this stage are Request Failed and Request Partially Failed, which is set based on the failing of all or any of the associated operations specified in the request respectively.

Withdrawn

A request can be withdrawn by the requester. At this stage, the request is associated to the Request Withdrawn status, and the initiation of all approvals are canceled, as indicated by multiple entry point in Figure 10-2.

Note:

  • A request can be withdrawn before Operation Initiated stage. Once the request attains the Operation Initiated stage, the request cannot be withdrawn.

  • A request can always be withdrawn from Oracle Identity Manager Self Service and cannot be withdrawn from Advanced Administration.

Completed

After the execution of all operations specified in the request are completed, the request engine moves the request to the Request Completed stage.

The following request statuses are associated with this stage:

  • Request Completed with Errors

    A request attains this status, when an actual requested operation executes fine, but fails to execute any of the post-processing operations. The Request Completed with Errors stage is associated with the Failed stage.

  • Request Completed

    A request attains this status, when an actual requested operation executes fine without any errors.

  • Request Awaiting Completion

    When a request is scheduled to be executed on a future date, the request attains Request Awaiting Completion status till the operation is completed on an effective date.


The successful attainment of a stage also results in the status of the request being updated to the corresponding status.

Operations can be executed manually or automatically by the system in response to an event. Examples of manual operations are:

  • Submit request

  • Close/cancel (withdraw) request

  • Approve request when the service is notified that the approval workflow is successfully approved

Examples of automatic operations are:

  • Start approvals when the request is submitted

  • Execute request when the request is approved and execution date is in the past or not specified

10.2 Bulk Requests and Child Requests

A bulk request is a request with multiple beneficiaries, multiple target entities, or both. For example, a request to assign multiple roles to user John Doe generates a bulk request. Provisioning requests to provision a resource, such as AD User, to users John Doe and Jane Doe also generates a bulk request. A bulk request has two parts:

The entity data in bulk requests must be same for different beneficiaries specified in the request. For example, for a deprovisioning bulk request, the requester can select different resource instances to be deprovisioned for different beneficiaries. In such a situation, the association between the resource instances and their beneficiaries is maintained.

The number of child requests generated depends on the number of target entities associated with each beneficiary. For each beneficiary, one of its associated target entities is used to generate for each child request. A child request contains only one beneficiary and one target entity.

For a request with no beneficiaries, each child request is spawned for each target entity. Consider the following example:

For a modify-user bulk request, two user instances are to be modified. For this request, two child requests are spawned addressing one user instance each.

Consider another example. For a deprovisioning bulk request, there are two beneficiaries. Two resource instances are to be deprovisioned for each beneficiary. In this scenario, there are two child requests for the first beneficiary and two child requests for the second beneficiary. Each resource instance and its associated beneficiary are present in each child request. Therefore, for this bulk request, there are a total of one parent request and four child requests.

Template-level approval is performed as a part of parent request. If the request template used to create the request has an associated approval process, then request will move to "Obtaining Template Approval" stage. If the template has no approval process, request will be auto-approved at template level and is moved to "Obtaining Request Approval" stage.

Request-level approval is performed as a part of parent request. After the parent request spawns child requests, the parent request goes to the Operation Initiated stage, where in the request awaits for the child requests to complete the operation-level approval. After all the child requests completes, the parent request moves to the Completed stage, provided the requester is the same for both parent request and child requests.

Operation-level approval is performed for child requests only. Approvers can approve or reject child requests individually. If all the child requests are approved or rejected, then the parent request attains the Completed stage. If one of the child requests fails, then the parent request attains the Partially Failed stage. If all the child requests fail, the parent request attains the Failed stage.

Figure 10-3 outlines the lifecycle flow of a request in the request service:


See Also:


10.3 Request Models

A request model is a specification that instructs the request management engine to behave in a specific way for a particular request type. Each request must have a request model associated with it. There is a one-to-one relation between a request model and a request type. A request model dictates what information to collect, how to get the approvals, and what action to perform. For example, the information defined for the Create User and Modify User request models are different, and as a result, the actions for each request type are different.


Note:

Oracle Identity Manager provides the request models by default. Request models cannot be modified.

Oracle Identity Manager provides a set of predefined request models. Table 10-2 lists the operations and request models that Oracle Identity Manager supports by default.


Note:

For the Create Role, Delete Role, and Modify Role request models, request creation is supported only by using APIs and not from the UI.

In Table 10-2, the Bulk column indicates the request models for which bulk operations are supported. A bulk request is a request with multiple beneficiaries, multiple target entities, or both. For example, a request to provision multiple roles to user John Doe generates a bulk request. A provisioning request to add users John Doe and Jane Doe to the Managers group also generates a bulk request.

A request model is an XML file that specifies how the request must flow after submission, what approvals are required, and what data is required from the requester. It contains the following information:

10.4 Creating Requests for Self and Others

A user logged in to Oracle Identity Manager can create requests from Self Service and Advanced Administration . This section describes how to create requests by using Oracle Identity Manager Self Service in the following topics:


See Also:

"Creating Requests by Using Oracle Identity Manager Advanced Administration" for information about creating requests as a request administrator by using the Advanced Administration UI

10.4.1 Creating a Request to Register Yourself in Oracle Identity Manager

Using the login page of Oracle Identity Manager Self Service, you can create a request to register yourself in Oracle Identity Manager. This is called a Self-registration request and can be raised by users not present in Oracle Identity Manager (anonymous users).

To create a Self-registration request:

  1. In the login page of Oracle Identity Manager Self Service, click Register. The Step 1: Basic Information page of the User Registration wizard is displayed.

  2. Enter first name, last name, and e-mail ID in the respective fields, and then click Next. The Step 2: Login Information and Security Information page is displayed.

  3. In the Select a User ID and Password section, enter login ID and password, and confirm the password in the respective fields.

  4. In the Set your Challenge Questions and Answers section, select challenge questions and enter answers for the questions. These questions and answers are used if you forget your password and need to reset it.

  5. Click Register. A confirmation page is displayed stating that the registration request is created. This page displays a request tracking number that you can use to check the status of your request.

  6. Click Track Registration to track the self registration requests.

10.4.2 Creating a Request from Oracle Identity Manager Self Service

Oracle Identity Manager Self Service allows you to create requests from the Welcome page, the My Requests page, and the My Profile page, as described in the following sections:

10.4.2.1 Creating a Request From Welcome Page of Oracle Identity Manager Self Service

Using the Welcome page of Oracle Identity Manager Self Service console, a logged in user can create requests for self or for others if authorized.

To create a request from the Welcome Page of Oracle Identity Manager Self Service:

  1. In the Welcome page of Oracle Identity Manager Self Service, click Create Request. The Request Beneficiary Selection page is displayed.

  2. Select Request for Me or Request for Others and click Next. The Select Request Template page is displayed.


    Note:

    • If the Request for Me option is selected, then all templates related to self request types that are accessible to you are displayed.

    • If the Request for Others option is selected, then all templates related to non-self request types that are accessible to you are displayed. If there are no such templates, then you cannot create request with this option.


  3. In the Request Template box, enter the request template name. Alternatively, select the request template from the table. Then, click Next.

    After the template selection, the steps in the request creation are dynamically generated. The subsequent steps are shown if you select the Create User request template.

  4. From the available details list, enter last name and select Organization, Design Console Access, and User Type and then click Next. The Enter Justification page is displayed.

  5. Enter the date and the justification for creating the request and then click Finish. The Request ID is created and displayed.

  6. Click on the Request ID. The request details are displayed.

10.4.2.2 Creating a Request From the My Requests Page

When you click Requests on the top of Oracle Identity Manager Self Service, the My Requests page is displayed.

In the Search My Requests section of the My Requests page, you can search for requests by using the fields in the Search Requests section. A table is displayed in the page that lists the requests raised by you or the requests raised for you.

Table 10-3 lists the columns in the table that shows request information:

To create a request:

  1. From the Actions list, select Create Request. The Request Beneficiary page is displayed.

  2. Select Request for Me or Request for Others and click Next. The Select Request Template page is displayed.


    Note:

    • If "Request for Me" option is selected, all templates related to self request types which are accessible to you are displayed.

    • If "Request for Others" option is selected, all templates related to non-self request types which are accessible to you are displayed. If there are no such templates, you cannot create request using this option.


  3. In the Request Template box, enter the request template name. Alternatively, select the request template from the table. Then, click Next.

    After the template selection, the steps in the request creation are dynamically generated. The subsequent steps are shown if you select the Create User request template.

  4. From the available details list, enter last name and select Organization, Design Console Access, and User Type and then click Next. The Enter Justification page is displayed.

  5. Enter the date and the justification for creating the request and then click Finish. The Request ID is created and displayed.

  6. Click on the Request ID. The request details are displayed.

In the My Requests page, you can also withdraw a request by selecting the request, and then selecting Withdraw Request. For more information about withdrawing requests, see "Withdrawing a Request"".

In the My Requests page, when you click the link in the "Request ID" column, the request details are displayed for that request. For information about the Request Details page and the operations that you can perform in this page, see "Searching for Requests".

10.5 Searching for Requests

Using Oracle Identity Manager Self Service, various roles perform request searching and tracking:


See Also:

"Searching Requests" for information about searching requests in the Advanced Administration UI

10.5.1 Request Search as a Requester

As an authenticated user, you can view the requests raised by you in the Requests tab of Oracle Identity Manager Self Service. When you click Requests, the My Requests page is displayed with a search facility and a list of requests that you raised. You can search for the following:

  • Requests Raised By Me: Returns requests created by logged-in user

  • Requests Raised For Me: Returns requests where login user exists as beneficiary or target user

In the Search Requests section of the Requests page, you can search for requests based on request ID, request type, status, start date, and end date. You can also sort the requests based on request ID, request type, status, date requested, and requester.


Note:

Sorting on Request ID is string based and not number based.

The search results are displayed in a table. From the Show list, you can select Requests Raised By Me to display the requests for which you are the requester. Otherwise, select Requests Raised for Me to display the requests for which you are the beneficiary.


Note:

In the My Requests page, you cannot perform any action on the requests as a beneficiary. As a requester, you can withdraw the request. See "Withdrawing a Request" for more information about withdrawing requests.

When you select a request in the table, the Request Details tab is displayed with detailed information about the request, as shown in Figure 10-4:

The Request Details page displays the details of the request in the Request Information section. The Status field displays the current request status. A link is shown if the status is Request Failed or Request Completed with Errors, as shown in Figure 10-4, which can be clicked to see the reason for the failure.

In addition, the following tabs display details associated to the request:

10.5.1.2 Request Comments

This tab shows the comments associated with the request, if any. You can see all the comments that might be added at various stages of the request life cycle and also add new comments. For example, the requester may add a comment before withdrawing the request, an administrator may add a comment before closing the request, an approver or requester may add comments as a part of attaining approvals.

10.5.1.4 Approval Tasks

This tab shows all Approval Tasks (pending or completed) that are associated with the request.

10.5.1.5 Child Requests

This tab is displayed only for a bulk/parent request. It displays the child requests that are created for the bulk/parent request.

10.5.3 Request Searching by Approver

As an approver, you can view the requests waiting for your approval in the My Tasks section of Oracle Identity Manager Self Service. Figure 10-10 shows the Approvals tab of the MyTasks section:

In the Search Tasks section of the Approvals tab, you can search for requests based on request ID, task name, start date, and end date. The search results are displayed in a table, as shown in Figure 10-10. From the View Tasks Assigned To list, you can select the following:

  • You Only: To sort only the requests assigned to you

  • Roles You Have: To sort the requests assigned to the roles of which you are a member

  • You and Roles You Have: To sort the requests assigned to you and to the roles of which you are a member

  • Users You Manage: To sort the requests assigned to the users you manage

When you select a request from the search results table, the Task Details page is displayed with detailed information about the request, as shown in Figure 10-11:

The request details are displayed in the Basic Details and Request Information sections.

If some attributes are marked as approver-only in the request type/dataset, then there will be an additional section called "Additional Data From Approver". It is in this section, where approver can provide data, without which the approver will not be allowed to approve a request (if the field is marked as mandatory). In the next level of approval, the approver can modify the data, if required.Similarly, if the approver send a task to a user for additional information, then task details of the received user will have an additional section called "Additional Request Information". It is in this section, where a received user can provide the information requested.

In addition, the following tabs display details associated to the request:

  • Requested Resources or Users or Requested Roles: The Resources @tab is dynamically generated based on the request type. It displays a list of beneficiaries, name of the target resources, and links to view the details about the target resources.

    The User tab shows the user details that is part of a request. For example, in case of CreateUser, User tab displays the user name and "View Details" link will provide the attributes of the user provided during the request creation.

    The Role tab shows the role details that is part of a request. For example, it can be a role name that you want to add or remove.

  • Request Comments: This tab displays any comment or justification provided with the request.

  • Request History: The various changes the request has already been through in the process of execution.

From the My Tasks and the Request Details tabs, you can perform request operations, such as approving, claiming, rejecting, and reassigning requests, and to request for more information. For detailed information about these procedures, see "Chapter 9, "Managing Tasks".

10.5.4 Request Search by Unauthenticated User

As an unauthenticated user, you can only track the request for self-registration. After you create and submit a self-registration request, a request ID is displayed. You can use this request ID to track the request.


See Also:

"Tracking Registration Requests" in the "Unauthenticated User Self Service" chapter for information about tracking a self-registration request

10.6 Withdrawing a Request

A request can be withdrawn by the requester and only the requests that have not started the execution phase can be withdrawn. Also, beneficiaries cannot withdraw requests. Requests having the following stages can be withdrawn:

  • Obtaining Approval

  • Approved

To withdraw a request:

  1. In Oracle Identity Manager Self Service, click Requests.

  2. In the My Requests page of Oracle Identity Manager Self Service, select the request that you want to withdraw.

  3. From the Actions list, select Withdraw Request.

  4. Click OK in the confirmation message box. The request is withdrawn and a notification is sent to the beneficiary and requester of the request. If the withdrawal is successful, then request moves to the Request Withdrawn stage. Any pending approval tasks associated with the request are canceled.


    Note:

    Configuration of notification can be done in the human task of a SOA composite.

10.7 Performing Request-Related Tasks by Using the Task List

For more information about request-related tasks, such as approving a request, claiming a task, requesting for more information, submitting information, rejecting a task, and reassigning a task using the Task List, see "Viewing Task Details" in the "Authenticated User Self Service" chapter.

10.8 Closing Requests

Request Administrators (users with Request Administrators role) can prematurely close any request that has not started the execution phase. This includes all requests waiting for approvals or has completed approvals but no operation has been started. Requests with the following state can be closed:

  • Obtaining Approval

  • Approved


Note:

  • The requester or the beneficiary of a request cannot close the request.

  • If a request is closed while the request is in the Obtaining Approval stage, then all the approvals that are still pending in the approver task list are removed.


To close a request:

  1. Go to Oracle Identity Manager Advanced Administration.

  2. In the left pane of the Requests section, search for the request that you want to close.

  3. From the search results table, select the request.

  4. From the Actions list, select Close Request. The Close Request dialog box is displayed.

  5. Enter a reason for closing the request, and then click Close Request. A message box is displayed stating that the request closing is successful.

  6. Click OK. If the request is closed successfully, then the request moves to the Request Closed stage. A notification that the request is closed is sent to the requestor and target user for this request.


    Note:

    Configuration of notification can be done in the human task of a SOA composite.

PKh]3PKj?OEBPS/oimarchtcture.htm Architecture

2 Architecture

The architecture of Oracle Identity Manager provides a number of compelling technical benefits for deploying a provisioning solution as part of the identity and access management architecture.

Oracle Identity Manager platform automates access rights management, security, and provisioning of IT resources. Oracle Identity Manager connects users to resources and revokes and restricts unauthorized access to protect sensitive corporate information.

This chapter consists of the following sections:

2.1 Key Features and Benefits

Oracle Identity Manager architecture is flexible and scalable, and provides the following features:

2.1.6 Modular and Scalable Architecture

Oracle Identity Manager simplifies the change management required in a dynamic organization. This provides an iterative provisioning approach that allows IT to implement a provisioning system to fit existing requirements and to ensure that this system can evolve to meet future business needs. As user needs and business policies evolve, outdated execution logic can be "unplugged" from the provisioning instance for replacement with new execution logic. This provides the most cost-effective mechanism for handling change management and supporting the ongoing evolution of processes and systems for the organization.

The J2EE application server model of Oracle Identity Manager provides scalability, fail over, load-balancing, and Web deployment. It is based on an open, standards-based technology and has a three-tier architecture (the client application, an Oracle Identity Manager supported J2EE-compliant Application Server, and an ANSI SQL-compliant database). Oracle Identity Manager can provision LDAP-enabled and non-LDAP-enabled applications.

2.1.7 Based on Leading Software Development Standards

Oracle Identity Manager incorporates leading industry standards. For example, Oracle Identity Manager components are fully based on a J2EE architecture, so customers can run them from within their standard application server environments. Complete J2EE support results in performance and scalability benefits while aligning with existing customer environments to leverage in-house expertise.

Oracle develops its identity management products on a foundation of current and emerging standards. For example, Oracle is a Management Board member of Liberty Alliance, and incorporates Liberty Alliance developments in its solutions. Oracle participates in the Provisioning Services Technical Committee (PSTC), which operates under the auspices of the Organization for the Advancement of Structured Information Standards (OASIS).

2.1.10 Built-In Change Management

Oracle Identity Manager enables you to package new processes, import and export existing ones, and move packages from one system to another.

2.2 How Oracle Identity Manager Works: The Tiers of Oracle Identity Manager

Oracle Identity Manager is based on the n-tier J2EE application architecture. Oracle Identity Manager architecture contains the following tiers:

Figure 2-1 illustrates Oracle Identity Manager architecture.

2.2.1 Presentation Tier

The Presentation tier consists of two clients, Oracle Identity Manager Administrative and User Console and Oracle Identity Manager Design Console.

Oracle Identity Manager Administrative and User Console is a Web-based thin client that can be accessed from any Web browser. This client provides user self-service and delegated administration features that serve most of the users of Oracle Identity Manager.

Oracle Identity Manager Design Console provides the full range of Oracle Identity Manager system configuration and development capabilities, including Form Designer, Workflow Designer, and the Adapter Factory. You can access Oracle Identity Manager Design Console by using a desktop Java client.

Oracle Identity Manager Design Console is implemented as a Java Swing client that communicates directly with the Business Services layer in the application. It also supports a highly sophisticated delegated administration model, guaranteeing that users can only work on those parts of the application configuration that they have been given privileges to.


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager and Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for details about using Oracle Identity Manager Administrative and User Console and Oracle Identity Manager Design Console

In many enterprises, there is a requirement for the provisioning system to support a custom developed client. Some of the requirements that drive this are:

  • Integration of the client into an existing enterprise portal and adherence to enterprise portal standards

  • Creation of custom flows for user interaction

  • Creation of custom pages built around unique requirements from the provisioning system

To support customization, Oracle Identity Manager exposes the bulk of the necessary functionality via its published public APIs. The client environment for Oracle Identity Manager is customizable via Java APIs.

2.2.2 Business Services Tier

The Business Services Tier is implemented as an Enterprise JavaBeans (EJB) application. The core functionality for Oracle Identity Manager platform is implemented in Java using a highly modular, object-oriented methodology. This makes Oracle Identity Manager flexible and extensible. The Business Services Tier for Oracle Identity Manager includes the following services and capabilities:

  • The Core Services that comprise the core of the business features offered by Oracle Identity Manager, such as the User Management Service, the Policy Management Services, and the Provisioning and Reconciliation Services.

  • The API Services that describe the APIs supported by Oracle Identity Manager that allow custom clients to integrate with Oracle Identity Manager. This includes a rich set of APIs that expose the business functionality of Oracle Identity Manager for use by custom clients, in product customization, and in plug-in and adapter development.

  • The Integration Services based on the Adapter Factory and Connector Framework, which dynamically generates integration code based on the metadata definition of the adapters.

  • The Platform Services that are crucial to the business features offered by Oracle Identity Manager, such as the Request Management Service, the Entity Manager Service, and the Scheduler Service.

2.2.2.2 Integration Services

A scalable and flexible integration architecture is critical for the successful deployment of provisioning solutions. Oracle Identity Manager offers an integration architecture for fast and low-cost deployments.

Oracle Identity Manager integration services provide all the components required to support the development, deployment, and maintenance of connectors. The integration services includes:

2.2.2.2.1 Connector Framework

Oracle Identity Manager connectors are packaged solutions that are used to integrate with target applications for the purposes of managing identities in those applications. Examples of such target applications are Microsoft Active Directory or Oracle E-Business Suite. A connector can be predefined by Oracle for particular target systems or can be custom developed.

Because a predefined connector is designed specifically for the target application, it offers the quickest integration method. These connectors support popular business applications such as Oracle eBusiness Suite, PeopleSoft, Siebel, JD Edward and SAP, as well as technology applications such as Active Directory, Java Directory Server, UNIX, databases, and RSA ClearTrust. Predefined connectors offer the quickest integration alternative because they are designed specifically for the target application. They use integration technologies recommended by target and are preconfigured with application specific attributes.

If predefined connectors does not use integration technologies recommended by target, then a custom connector can be developed. The Adapter Factory tool in Oracle Identity Manager Design Console provides a definitional user interface that facilitates such custom development efforts without coding or scripting.

A connector contains:

  • Multiple connector-specific Oracle Identity Manager entities such as resource objects, data forms, provisioning workflows, and adapters

  • Target-specific Java libraries that provide the underlying functions such as connectivity, authentication and user account management

  • Event triggers that wire provisioning operations to both identity profile changes and policy operations

The connector framework combines all of these components together into a functional connector that is run at appropriate times, either manually based on user interaction or based on system triggering. It defines the various operational triggers, policy triggers, and hooks that allow the connector operation to be tailored to specific requirements.

2.2.2.2.2 Identity Connectors

Connectors are deployed with Oracle Identity Manager, which affects the portability of the connectors across various Oracle Identity Manager releases. The Identity Connector Framework (ICF) decouples the connectors from Oracle Identity Manager. As a result, connectors can be used with any product. Identity connectors are designed to separate the implementation of an application from the dependencies of the system that the application is attempting to connect to.

Identity connectors have the following components:

  • The identity connector framework: Provides a container that separates the connector bundle from the application. The framework provides many common features that developers would otherwise need to implement on their own. For example, the framework can provide connection pooling, buffering, timeouts, and filtering. The identity connector framework is separated into two parts:

    • The API: Applications use the API to call connectors

    • The SPI: Developers can create connectors by implementing the SPI

  • Identity connector bundle: The specific implementation for a given resource target

  • The connector server (optional): Allows an application to remotely run one or more connector bundles that are deployed on another system. Connector servers are available in both Java™ and .NET. The .NET connector server is needed only if you are using .NET connector bundles, whereas the Java connector server is available for connector bundles written in Java.

Figure 2-2 shows the ICF architecture:

Connector SPI

Connector SPI interfaces represent operations supported on a connector. A connector developer can choose to implement one or more operation interfaces for framing target system calls. Extension on existing interfaces or creating new interfaces is not supported. The SPI is broken up into required interfaces, feature-based interfaces, and operation interfaces such as create, update, delete, and search.

For information about developing an identity connector by implementing connector SPI, see "Identity Connector Framework" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

Connector API

The connector API is responsible for presenting a consistent view of a connector regardless of the operations it has implemented. For the convenience of the SPI developer, there are several common features that are provided by default. For most of these features there is no need for the application developer to handle the APIs, only configure them. Following is a list of API features:

  • Provide connection pooling to those connectors that require it and avoid the need for the API to see it, because not all connectors have connections. In addition, if the connector uses connection pooling, it is not the responsibility of the API developer to handle the connections, nor dispose of them during error conditions.

  • Provide timeouts to all operations. The API consumer should only configure the appropriate timeout if the default is unacceptable. Each SPI developer should not have to implement such a common service and, for this reason, it is implemented in the framework.

  • Provide search filtering by way of a simple interface that accepts a large variety of filters. The connector developer only needs to implement whichever filters the resource natively supports. The rest is handled by the framework.

  • Provide search/sync buffering, allowing queries and updates to be handled in chunks if need be. The application need not worry about this, as it is handled within the framework.

  • Provide scripting via Groovy and Boo .NET for connectors. This allows for great flexibility within a connector, because the framework can run scripts both on the connector and on the target resource (if supported).

  • The SPI developer has the ability to choose different implementations of an operation. For instance there are two types of updates. This is hidden from the API consumer because there is no need for the application developer to call two different operations that essentially do the same thing. Instead the framework will figure out which operation the connector supports and make the appropriate calls.

2.2.2.2.4 Generic Technology Connector

To integrate Oracle Identity Manager with a target system that has no corresponding predefined connector, you can create a custom connector to link the target system and Oracle Identity Manager. If you do not need the customization features of the Adapter Factory, then you can create the connector by using the Generic Technology Connector (GTC) feature of Oracle Identity Manager.

You can quickly and easily build a basic connector without advanced features and customized behavior by using generic connectivity technologies such as SPML and JDBC. GTC is a wizard that provides an alternative environment for connector development to rapidly create all the necessary functional components that make up a target system connector in Oracle Identity Manager.

The reconciliation and provisioning modules of a generic technology connector are composed of reusable components that you select. Each component performs a specific function during provisioning or reconciliation.

The components that constitute a generic technology connector are called providers. Each provider performs a transport, format change, validation, or transformation function on the data that it receives as input. In other words, data items processed by a provider are moved to a new location, validated against specified criteria, or undergo modification in structure or value. Data sets describe data structures arranged in the form of layers, with data flowing from one layer to another during provisioning and reconciliation.

The GTC employs a Web-based graphical wizard that displays the data flows being defined within the connector. It stores in metadata all the configuration information about the connector so that it can reload the GTC view of the connector and enable ongoing maintenance of the connector in the same graphical environment. Because the GTC builds the connector by using the standard connector framework, the application developer can access the standard Oracle Identity Manager development environment and make further modifications to the generated connector. However, after the GTC-based connector has been customized in this manner, it can no longer be managed or maintained using the GTC.


See Also:

"Generic Technology Connectors" for detailed information about the functional architecture and features of GTC

2.2.2.3 Platform Services

The Platform Services include:

2.2.2.3.1 Request Service

Oracle Identity Manager architecture includes a request service that allows you to configure approval workflows. To deliver this functionality, Oracle Identity Manager uses Oracle Service Oriented Architecture (SOA) Suite.

Oracle SOA Suite enables you to build service-oriented applications and deploy them to your choice of middleware platform. It consists of a number of components, but for the purposes of delivering comprehensive workflow capabilities, Oracle Identity Manager relies on the following components:

  • BPEL Process Manager: Oracle BPEL Process Manager provides a comprehensive solution for creating, deploying, and managing cross-application business processes with both automated and human workflow steps. It also provides audit trails for both completed and running processes, and process history that enables process improvement.

  • Human Request Service: Although the BPEL standard does not cover manual tasks, it supports asynchronous services. Therefore, the Oracle SOA Suite supports the Human Request Service, which is a manual task service, so that manual steps can be included in standard BPEL processes. Oracle Identity Manager Administration and User Console includes a task list that allows users to view and interact with assigned tasks being managed within the Human Request Service.

  • BPEL Designer: The Oracle BPEL Designer is available as a plug-in for JDeveloper and offers a visual design paradigm for creating and deploying BPEL-based processes.

Oracle Identity Manager provides an abstraction service on top of the SOA suite that optimizes and simplifies the interaction of users with the SOA suite. This service includes capabilities to register BPEL composites for use in Oracle Identity Manager, define parameterized variables for use in the BPEL and Human Workflow modules, and APIs that are used by the task list and custom development.


See Also:

"Approval Workflows" in Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about workflows and BPEL composites.

The Request Service also provides the services used to raise and track requests in Oracle Identity Manager. A request allows a user to ask that an action be taken after obtaining the necessary approvals, and that a tracking record of the entire process and its status be maintained. The request can be for various types of actions that are defined as request types. The request types can be:

  • Creating, modifying, or deleting an entity

  • Enabling or disabling an entity

  • Provisioning a resource to a user or a set of users

  • Adding or removing an identity as a member of a role

The request service supports various types of requests and has the ability to accommodate multiple request types. Oracle Identity Manager provides a number of predefined request types that cover the most common use cases. The request service also provides support for request templates, that allow you to customize the request types for a specific requirement.

The request service defines the flow models by which data provided in a request flows through the various services in Oracle Identity Manager. This includes invoking approval workflows at the correct time, monitoring the status of the workflows, and running the request if approval is received.

Both transaction data and history data for requests is maintained, which supports audit and compliance requirements.


See Also:

"Managing Requests"" for information about creating requests and perform request-related operations in the task list of Oracle Identity Manager Self Service

2.2.2.3.2 Authorization Service

Oracle Identity Manager is a security product and requires a strong level of access control over what users can view and change in the application. To meet this requirement, Oracle Identity Manager lets you define authorization policies that determine at runtime whether or not a particular action is allowed. This is controlled by the authorization service embedded within Oracle Identity Manager. The authorization service is based on Oracle Entitlements Server (OES), which is a sophisticated authorization product. OES enables centralized management of entitlements and authorization policies to granularly determine access to both application components and application business objects.

The OES architecture is made up of two major components. The administration application acts as the policy administration point (PAP) and is used to manage policy, configuration, roles, and entitlements. The second major component is the use of one or more Security Modules (SMs) that are stored in the application container. The SMs evaluate fine-grain access control polices at the policy decision point (PDP) and enforce it at the policy enforcement point (PEP).

Figure 2-4 shows the architecture of OES-based authorization service:

Each time a privilege check is requested, the following takes place:

  • Oracle Identity Manager connects to the authorization service to prepare access decision for the operations performed on protected entities.

  • The service then finds and evaluates the policy or policies that apply to the resource.

  • All information required to evaluate a policy is collected by the Security Modules at run time.

  • If the policy references subject by role, all roles are evaluated and the access decision is made.

Oracle Identity Manager provides an abstraction service on top of OES that optimizes and simplifies the definition of policies in Oracle Identity Manager. This service includes a policy definition UI that allows the definition of authorization policies that are feature specific and support fine-grained controls for attributes and functions on entities such as users and roles. For information about the structural components of authorization policies and how to create and manage authorization policies, refer "Creating and Managing Authorization Policies".

2.2.2.3.4 SoD Engine Framework

An attempt to enforce good compliance practices is through the definition of Segregation of Duties (SoD) policies. SoD is broadly defined as a way of preventing a user from acquiring a conflicting set of entitlements. This conflicting set is also referred to as a toxic combination. An example of a toxic combination is that a person should not have the ability to create and approve the same purchase order. Enterprises often have business application-specific SoD engines that define and enforce SoD policies on the entitlements users have within those business applications. Examples of such SoD engines are OAACG and SAP GRC.

The SoD Engine Framework allows customers to integrate Oracle Identity Manager with their choice of SoD Engine to enable SoD checks at appropriate points in the request and provisioning process. Oracle Identity Manager can send a request for an SoD check to the SoD Engine through the SoD Invocation Library (SIL). SIL provides a common service interface to all supported SoD engines. The common service interface provides an abstraction on the business components within Oracle Identity Manager. As a result, SoD checks do not have to take care of the correct data formats required by the SoD Engine and also the interpretation of the results returned.

SoD checks can be run at various times in the provisioning lifecycle, such as during an access request, during the approval workflow execution, or during the provisioning execution. If a violation is detected, then the request or resource is marked as being in violation, and the approver or administrator is responsible for deciding whether to proceed or not. If violations are detected during request processing, then various approval workflows can be invoked that allow for higher levels of approval.

2.2.2.3.5 Scheduler Service

Business systems frequently make use of scheduling systems, which are configured to run other programs at specified times. Scheduling systems run applications that generate reports, reformat data, or perform audits at regular intervals of time. Scheduling systems often run batch jobs or scheduled jobs that perform routine work automatically at a prescribed time.Scheduling systems are an integral part of any enterprise provisioning solution. Provisioning often involves tasks to be performed in a time-based manner. Some examples are:

  • Running a nightly job to reconcile all changes made directly on a managed application

  • Do escalations of assigned tasks that have not been handled within a specified time period

  • Execute requests at a specific time

Oracle Identity Manager platform includes the Scheduler to provide the scheduling capabilities necessary for enterprise provisioning requirements. This Service is managed as part of Oracle Identity Manager platform and not as an independent product. Figure 2-5 provides an overview of Oracle Identity Manager Scheduler architecture.

Key capabilities provided by the Scheduler service are:

  • The ability to create simple or complex schedules for running thousands of jobs

  • The ability to run the scheduling service as a clustered service to provide the necessary high availability capabilities including fail-over and load balancing

  • The ability to persist the job definitions for management and fail-over support

  • The ability to create, modify, enable, disable, and delete jobs and manage individual job runs by using an administrative UI

  • The ability to run a job in an ad-hoc fashion outside of regularly scheduled runs

  • The ability to manage errors and failures

  • The ability to maintain history of job runs, including statistics and results of these runs

  • The ability to manage the Scheduler service itself


See Also:

  • "Managing Scheduled Tasks" chapter detailed information about the Scheduler service and creating and implementing custom scheduled tasks in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager


2.2.3 The Data Tier

Oracle Identity Manager is driven by data and metadata, which provides flexibility and adaptability to Oracle Identity Manager functionalities. Oracle Identity Manager data tier consists of Oracle Identity Manager repository or database, which manages and stores Oracle Identity Manager data and metadata in an ANSI SQL 92-compliant relational database, and an optional LDAP Identity Store.

This section describes the data tier in the following topics:

2.2.3.1 Oracle Identity Manager Database

Oracle Identity Manager repository is the authoritative store for the Who Has What, When, How, and Why data that is the core value of the identity administration and provisioning system. The data stored in Oracle Identity Manager database falls into the following broad categories:

  • Entity Data: Users, organizations, roles, role memberships, resources, provisioned resources

  • Transactional Data: Requests, approval and provisioning workflow instances, human tasks

  • Audit Data: Request history, user profile history

High Availability

The database provides a scalable and redundant data layer to avoid downtime and performance issues. Reliability, recoverability, timely error detection, and continuous operations are primary characteristics of a highly available solution.

Oracle Identity Manager architecture relies on the corresponding capabilities provided by the Database Management System that is used with the product. These capabilities must:

  • Encompass redundancy across all components

  • Provide protection and tolerance from computer failures, storage failures, human errors, data corruption, lost writes, system hangs or slowdown, and site disasters

  • Recover from outages as quickly and transparently as possible

  • Provide solutions to eliminate or reduce planned downtime

  • Provide consistent high performance

  • Be easy to deploy, manage, and scale

  • Achieve Service Level Agreements (SLAs) at the lowest possible total cost of ownership

A broad range of high availability and business continuity solutions are available. You can find out more about maximizing database availability by using technologies such as Oracle Real Application Clusters (Oracle RAC) and Oracle Data Guard at the following Web site:

http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

Reporting

The rich set of data stored in Oracle Identity Manager repository can be viewed through detailed reports that support management and compliance requirements. Oracle Identity Manager provides support for data reporting through the use of Oracle BI Publisher, which is an enterprise reporting solution and provides a single reporting environment to author, manage, and deliver all of your reports and business documents. Utilizing a set of familiar desktop tools, such as Microsoft Word, Microsoft Excel, or Adobe Acrobat, you can create and maintain report layouts based on data from diverse sources, including Oracle Identity Management products.

Oracle Identity Manager provides a set of standard Oracle BI Publisher report templates. However, you can customize each template to change its look and feel. in addition, you can create your own custom reports by leveraging Oracle Identity Manager database schema.

2.2.3.2 The Metadata Store

The logic underlying Oracle Identity Manager is metadata driven. The structural and behavioral aspects are described by using metadata. Oracle Identity Manager architecture relies on Oracle Metadata Services (MDS) to provide a unified store for metadata. This ensures consistent and reliable access to the metadata for Oracle Identity Manager and for the other Fusion Middleware components that it is built on. The same metadata that is used during the design phase of an application is used at application runtime through the metadata services layer. This ensures consistency through the lifecycle of Oracle Identity Manager. MDS also provides common administrative tooling for the metadata that can be used across various types of metadata stored in the common repository.

Key features and architectural principles of the MDS include:

  • Simplified resource management through a single, unified repository for all artifacts used by various Fusion Middleware components

  • Management of the metadata lifecycle for each artifact as it moves through the various stages of development, testing, staging, and production

  • Sharing and reuse of metadata across components

  • Categorization and reuse of artifacts, encouraging reuse, and promoting consistency

  • Versioning capabilities, which form the basis for various features

  • An upgrade-safe and layered customization mechanism through which metadata and application logic can be tailored per usage of the metadata

  • Advanced caching and assembling techniques coupled with configurable tuning options to optimize performance

Metadata accessed and managed via MDS can be in a file-based repository or a database-based repository. In Oracle Identity Manager architecture, the metadata is in Oracle Identity Manager database to take advantage of some of the advanced performance and availability features that this mode provides.

2.2.3.3 The Identity Store

Oracle Identity Manager 11g Release 1 (11.1.1) provides the ability to integrate an LDAP-based identity store into Oracle Identity Manager architecture. In 9.x releases, Oracle Identity Manager identity store is in Oracle Identity Manager database. Therefore, Oracle Identity Manager integrates with LDAP as a provisioning target, or you can build custom integration between Oracle Identity Manager users and LDAP users. However, in 11g Release 1 (11.1.1), you can connect and manage an LDAP-based identity store directly from Oracle Identity Manager. Using this feature, you can use advanced user management capabilities of Oracle Identity Manager, including request-based creation and management of identities, to manage the identities within the corporate identity store.

In this deployment architecture, user identity information is stored in Oracle Identity Manager database to support the relational functionality necessary for Oracle Identity Manager to function, as well as in the LDAP store. All data is kept in sync transparently without the need for provisioning actions and setting up policies and rules. Identity operations started within Oracle Identity Manager, such as user creation or modification, are run on both the stores in a manner that maintains transactional integrity. In addition, any changes in the LDAP store made outside of Oracle Identity Manager is pulled into Oracle Identity Manager and made available as a part of the identity context.


See Also:

""Integration Between LDAP Identity Store and Oracle Identity Manager"" for more information about LDAP store integration and configuration

2.3 System Components

Oracle Identity Manager is built on an enterprise-class, modular architecture that is both open and scalable. Each module plays a critical role in the overall functionality of the system. Figure 2-6 illustrates the system components of Oracle Identity Manager.

Oracle Identity Manager user interfaces define and administer the provisioning environment. Oracle Identity Manager offers two user interfaces to satisfy both administrator and user requirements:

  • Powerful Java-based Oracle Identity Manager Design Console for developers and system administrators

  • Web-based Administration and Oracle Identity Manager Self Service interfaces for identity administrators and users respectively

This section describes the following Oracle Identity Manager components:

Identity Administration

Identity administration includes creation and management of identities in Oracle Identity Manager. Identities include users, organizations, and roles. Identity administration also enables password management and user Oracle Identity Manager Self Service operations. Identity administration is performed by using Oracle Identity Manager Administration and Oracle Identity Manager Self Service Web clients, and the SPML Web service.


Note:

The identity administration tasks include, managing users, managing roles, managing organizations and managing authorization policies, which are explained in detail in this guide.

Provisioning

The provisioning transactions are assembled and modified in the provisioning module. This module maintains the "who" and "what" of provisioning. User profiles, access policies, and resources are defined in the provisioning module, as are business process workflows and business rules.

The Provisioning Server is the run-time engine for Oracle Identity Manager. It runs the provisioning process transactions as defined through Oracle Identity Manager Administration and Oracle Identity Manager Design Console and maintained within the provisioning module.

Audit and Reports

The audit and compliance functions include evaluating a person, organization, system, process, project, or product. This occurs by capturing data generated by the suite's workflow, policy, and reconciliation engines. By combining this data with identity data, an enterprise has all the information it requires to address any identity and to access a related audit inquiry. Audits are performed to ascertain the validity and reliability of information, and also provide an assessment of a system's internal control.

Reporting is the process of generating a formal document, which is created as a result of an audit. The report is subsequently provided to a user, such as an individual, a group of persons, a company, a government, or even the general public, as an assurance service so that the user can make decisions, based on the results of the audit. An enterprise can create reports on both the history and the current state of its provisioning environment. Some captured identity data includes user identity profile history, role membership history, user resource access, and fine-grained entitlement history.

Reconciliation and Bulk Load

The reconciliation engine ensures consistency between the provisioning environment of Oracle Identity Manager and Oracle Identity Manager managed resources within the organization. The reconciliation engine discovers illegal accounts created outside Oracle Identity Manager. The reconciliation engine also synchronizes business roles located inside and outside the provisioning system to ensure consistency.


See Also:


If you want to load a large amount of data from other repositories in your organization into Oracle Identity Manager, then you can use the Bulk Load utility. The Bulk Load utility reduces the downtime in loading the data. In addition, Bulk Load utility import Oracle Identity Manager users, roles, role memberships, and accounts provisioned to users.


See Also:

"Bulk Load Utility" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for detailed information about Bulk Load utility

Common Services

Various services are grouped together that are shared and used by other Oracle Identity Manager components. These services are:

Workflow and Request Management

Various operations in Oracle Identity Manager cannot be performed directly. Instead, the operations must be requested. The request management service provides a mechanism to create, approve, and manage requests. A request is an entity created by the users or administrators who want to perform a specific action, which requires a discretionary permission to be obtained from someone or some process before the action can be performed. For example, a user can create a request to gain access to a laptop computer, a manager can approve the request and create an open requisition, and an IT resource administrator can approve the request.

The primary goal of a provisioning solution is to manage requests and provision resources. Request service provides an abstraction layer on the Business Process Execution Language (BPEL) 11g workflow engine. Functional components such as request, provisioning, and attestation interacts with the workflow engine for human approvals. Request service caters to the various functional components in Oracle Identity Manager by managing workflow instances and categories, and provides an abstraction layer on BPEL. For information about registering workflows with Oracle Identity Manager, see, Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

Infrastructure and Middleware Integration

The Adapter Factory, Kernel Orchestration mechanism, Context Manager, and Plug-in Framework are designed to eliminate the need for hard-coding integrations with these systems.

For more information about the integration of Oracle Identity Manager with middleware applications, see "Integration Solutions".

Connector Framework

A description of the Connector Framework is provided in the "Integration Services".

PK3PKj?OEBPS/audit.htm Auditing

6 Auditing

Oracle Identity Manager provides a powerful audit engine to collect extensive data for audit and compliance purposes. You can use the audit functionality together to capture, archive, and view entity and transactional data for compliance monitoring and IT-centric processes and forensic auditing. Therefore, with the audit and compliance modules, Oracle Identity Manager provides profile auditing, reporting, and attestation features. You can capture, transport, store, retrieve, and remove historical data over its life cycle. Security is maintained at every stage of the data life cycle. For information about attestation processes, see "Managing Attestation Processes".

This chapter consists of the following topics:

6.1 Overview

This section provides an overview of auditing in the following sections:

6.2 Audit Engine

User profile audits cover changes to user profile attributes, user membership, resource provisioning, access policies, and resource forms.

The audit engine collects auditing information in Oracle Identity Manager. Whenever a profile is modified, the audit engine captures the changes (the delta) and updates (or generates, if missing) the snapshots of the user and role profiles and stores these snapshots and deltas in XML format. The audit engine also contains post-processors, which, based on the generated XML, populate the reporting tables with relevant data. To maintain high performance, by default the audit engine performs these tasks in an asynchronous and offline manner by using the underlying Java Messaging Service (JMS) provided by the application server.

This section discusses the following topics:

6.2.1 Audit Levels

As mentioned earlier in this chapter, When you install Oracle Identity Manager user profile auditing is enabled by default and the auditing level is set to Resource Form. If you change the auditing level, then you must run the GenerateSnapshot.sh script (on UNIX) or the GenerateSnapshot.bat script (on Microsoft Windows). This script is in the IDM_HOME/server/bin directory. The script examines all users in Oracle Identity Manager database and generates new snapshots based on the new auditing level.


Note:

If you change the auditing level, then you must run the GenerateSnapshot script before allowing users to access the system.

You can configure the "level of detail for auditing" aspect of the auditing engine and specify the audit level as the value of the XL.UserProfileAuditDataCollection system property in the Advanced Administration.


See Also:

"System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrators Guide for Oracle Identity Manager for information about this system property

The supported audit levels are:

  • Process Task: Audits the entire user profile snapshot together with the resource lifecycle process.

  • Resource Form: Audits user record, role membership, resource provisioned, and any form data associated to the resource.

  • Resource: Audits the user record, role membership, and resource provisioning.

  • Membership: Only audits the user record and role membership.

  • Core: Only audits the user record.

  • None: No audit is stored.


Note:

When you specify a particular audit level, all audit levels that are at a lower priority level are automatically enabled. For example, if you specify the Membership audit level, then the Core audit level is automatically enabled.

Audit level specifications are case-sensitive. When you specify an audit level, ensure that you do not change the case (uppercase and lowercase) of the audit level.


6.3 User Profile Auditing

User profile audits cover changes to user profile attributes, user membership, resource provisioning, access policies, and resource forms.

This section discusses the following topics:

6.3.1 Data Collected for Audits

By default, user profile auditing is enabled and the auditing level is set to Resource Form when you install Oracle Identity Manager. This auditing level specifies the minimum level required for attestation of form data.

You configure the audit level in the System Configuration part of the Advanced Administration by using the XL.UserProfileAuditDataCollection system property.


See Also:

"Audit Levels" for more information about audit levels

"System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the XL.UserProfileAuditDataCollection system property


This section discusses the following topics:

6.3.1.1 Capture of User Profile Audit Data

Each time a user profile changes, Oracle Identity Manager takes a snapshot of the user profile and stores the snapshot in an audit table in the database.

A snapshot is also generated when there is a change in a user profile that must be audited, even if an initial snapshot is missing. The current snapshot is treated as the initial snapshot.

The following are the components of a user profile and the tables that store these components:


Note:

For more information about the User Profile tables, such as the column names and how to use them, refer to the Schema Javadoc provided with Oracle Identity Manager.