Oracle Fusion Middleware User's Guide for Oracle Identity Manager, 11g Release 1 (11.1.1)

11g Release 1 (11.1.1)

E14316-09

Contents

List of Figures

List of Tables

Title and Copyright Information

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

Part I Concepts

1 Feature Overview

- 1.1 Features of Oracle Identity Manager

- 1.1.1 User Administration

- 1.1.2 Workflow and Policy

- 1.1.3 Password Management

- 1.1.4 Audit and Compliance Management

- 1.1.5 Integration Solutions

- 1.1.6 User Provisioning

- 1.1.7 Organization and Role Management

2 Architecture

- 2.1 Key Features and Benefits

- 2.1.1 Ease of Deployment

- 2.1.2 Flexibility and Resilience

- 2.1.3 Maximum Reuse of Existing Infrastructure

- 2.1.4 Extensive User Management

- 2.1.5 Web-Based User Self-Service

- 2.1.6 Modular and Scalable Architecture

- 2.1.7 Based on Leading Software Development Standards

- 2.1.8 Powerful and Flexible Process Engine

- 2.1.9 Built-In Change Management

- 2.2 How Oracle Identity Manager Works: The Tiers of Oracle Identity Manager

- 2.2.1 Presentation Tier

- 2.2.2 Business Services Tier

- 2.2.2.1 The API Services

- 2.2.2.2 Integration Services

- 2.2.2.3 Platform Services

- 2.2.3 The Data Tier

- 2.2.3.1 Oracle Identity Manager Database

- 2.2.3.2 The Metadata Store

- 2.2.3.3 The Identity Store

- 2.3 System Components

3 User Interfaces

- 3.1 Overview of Oracle Identity Manager Administrative and User Console

- 3.1.1 User Self Service

- 3.1.1.1 Features of the User Self Service

- 3.1.2 Oracle Identity Administration

- 3.1.2.1 Features of Oracle Identity Administration

- 3.1.3 Oracle Identity Manager Advanced Administration

- 3.1.3.1 Features of Oracle Identity Manager Advanced Administration

- 3.1.4 Customizing Oracle Identity Manager Administrative and User Console

- 3.1.5 Localizing User Interfaces

- 3.2 Overview of Oracle Identity Manager Design Console

- 3.2.1 Features of Oracle Identity Manager Design Console

- 3.3 SPML Web Service

4 Deployment Configurations

- 4.1 Provisioning Configuration

- 4.2 Reconciliation Configuration

- 4.2.1 Types of Reconciliation

- 4.2.1.1 Reconciliation Based on the Object Being Reconciled

- 4.2.1.2 Mode of Reconciliation

- 4.2.1.3 Approach Used for Reconciliation

- 4.2.2 Reconciliation Architecture

- 4.2.2.1 Reconciliation Profile

- 4.2.2.2 Reconciliation Metadata

- 4.2.2.3 Reconciliation Target

- 4.2.2.4 Reconciliation Run

- 4.2.2.5 Reconciliation APIs

- 4.2.2.6 Reconciliation Schema

- 4.2.2.7 Reconciliation Engine

- 4.2.2.8 Reconciliation Best Practices

- 4.2.2.9 Connector for Reconciliation

- 4.2.2.10 Archival

- 4.2.2.11 Backward Compatibility

- 4.2.2.12 Reconciliation Manager

- 4.3 Integration Between LDAP Identity Store and Oracle Identity Manager

- 4.3.1 Configuring the Integration with LDAP

- 4.3.2 Provisioning Data From Oracle Identity Manager to LDAP Identity Store

- 4.3.2.1 Managing Users

- 4.3.2.2 Managing Roles

- 4.3.3 Reconciliation From LDAP Identity Store to Oracle Identity Manager

- 4.3.3.1 Consolidated LDAP Sync Full Reconciliation

5 Integration Solutions

- 5.1 Predefined Connectors

- 5.2 Generic Technology Connectors

- 5.3 Custom Connectors

- 5.4 Components Common to All Connectors

- 5.4.1 Provisioning Process Tasks

- 5.4.2 Reconciliation-Related Provisioning Process Tasks

- 5.5 Connector Installation

6 Auditing

- 6.1 Overview

- 6.1.1 Auditing Design Components

- 6.1.2 Profile Auditing

- 6.1.3 Standard and Customized Reports

- 6.2 Audit Engine

- 6.2.1 Audit Levels

- 6.2.2 Tables Used for Storing Information About Auditors

- 6.2.3 Issuing Audit Messages

- 6.3 User Profile Auditing

- 6.3.1 Data Collected for Audits

- 6.3.1.1 Capture of User Profile Audit Data

- 6.3.1.2 Storage of Snapshots

- 6.3.1.3 Trigger for Taking Snapshots

- 6.3.2 Post-Processor Used for User Profile Auditing

- 6.3.3 Tables Used for User Profile Auditing

- 6.3.4 Archival

- 6.4 Role Profile Auditing

- 6.4.1 Data Collected for Audits

- 6.4.1.1 Capture and Archiving of Role Profile Audit Data

- 6.4.1.2 Storage of Snapshots

- 6.4.1.3 Trigger for Taking Snapshots

- 6.5 Enabling and Disabling Auditing

- 6.5.1 Disabling Auditing

- 6.5.2 Enabling Auditing

Part II Oracle Identity Manager Self Service

7 Configuring and Using Self-Service Registration

- 7.1 Using Self-Service Registration

- 7.1.1 Logging In to Oracle Identity Manager Administrative and User Console

- 7.1.2 Submitting Registration Requests

- 7.1.3 Tracking Registration Requests

- 7.2 Configuring Auto-Approval for Self-Registration

8 Managing Profile

- 8.1 Managing Profile Attributes

- 8.2 Managing Role Assignments

- 8.2.1 Requesting Roles

- 8.2.2 Removing Roles

- 8.3 Managing Resource Profile

- 8.3.1 Requesting a Resource

- 8.3.2 Modifying a Resource

- 8.3.3 Displaying Resource Details

- 8.4 Managing Proxies

- 8.4.1 Adding a Proxy

- 8.4.2 Editing a Proxy

- 8.4.3 Removing a Proxy

- 8.5 Managing Security

- 8.5.1 Changing Password

- 8.5.2 Setting Challenge Questions and Response

- 8.5.2.1 Localizing Challenge Questions and Responses

- 8.6 Resetting Forgotten Password

9 Managing Tasks

- 9.1 Managing Approval Tasks

- 9.1.1 Searching Approval Tasks

- 9.1.2 Viewing Task Details

- 9.1.3 Claiming a Task

- 9.1.4 Approving a Task

- 9.1.5 Rejecting a Task

- 9.1.6 Reassigning a Task

- 9.1.7 Requesting for More Information

- 9.1.8 Submitting Information

- 9.2 Managing Provisioning Tasks

- 9.2.1 Searching Provisioning Tasks

- 9.2.2 Viewing Provisioning Task Details

- 9.2.3 Setting Response for a Task

- 9.2.4 Adding Notes to a Task

- 9.2.5 Reassigning a Task

- 9.2.6 Viewing Task Assignment History

- 9.2.7 Viewing Form Details

- 9.2.8 Modifying Form Details

- 9.2.9 Retrying a Task

- 9.3 Managing Attestation Tasks

- 9.3.1 Searching Attestation Tasks

- 9.3.2 Viewing Attestation Request Detail

10 Managing Requests

- 10.1 Request Stages

- 10.2 Bulk Requests and Child Requests

- 10.3 Request Models

- 10.4 Creating Requests for Self and Others

- 10.4.1 Creating a Request to Register Yourself in Oracle Identity Manager

- 10.4.2 Creating a Request from Oracle Identity Manager Self Service

- 10.4.2.1 Creating a Request From Welcome Page of Oracle Identity Manager Self Service

- 10.4.2.2 Creating a Request From the My Requests Page

- 10.4.2.3 Creating a Request From the My Profile Page

- 10.5 Searching for Requests

- 10.5.1 Request Search as a Requester

- 10.5.1.1 Requested Roles/Requested Resources/Users

- 10.5.1.2 Request Comments

- 10.5.1.3 Request History

- 10.5.1.4 Approval Tasks

- 10.5.1.5 Child Requests

- 10.5.2 Request Search as a Beneficiary

- 10.5.3 Request Searching by Approver

- 10.5.4 Request Search by Unauthenticated User

- 10.6 Withdrawing a Request

- 10.7 Performing Request-Related Tasks by Using the Task List

- 10.8 Closing Requests

Part III Identity Administration

11 Managing Users

- 11.1 User Lifecycle

- 11.1.1 OIM Account

- 11.1.2 Organization

- 11.1.3 Role

- 11.2 User Entity Definition

- 11.3 User Management Tasks

- 11.3.1 Searching Users

- 11.3.1.1 Simple Search

- 11.3.1.2 Advanced Search

- 11.3.2 Creating Users

- 11.3.3 Viewing and Modifying User Information

- 11.3.3.1 User Details Page

- 11.3.3.2 User Modifications

- 11.3.3.3 Single User Operations

- 11.3.3.4 Bulk User Modifications

- 11.4 User Management Authorization

- 11.4.1 Privileges

- 11.4.2 Attributes

- 11.4.3 Data Constraints

- 11.4.4 Authorization with Multiple Policies

- 11.4.4.1 Search Operation Authorization with Multiple Authorization Policies

- 11.4.4.2 Modify Operation Authorization with Multiple Authorization Policies

- 11.5 Username Reservation

- 11.5.1 Enabling and Disabling Username Reservation

- 11.5.2 Configuring the Username Policy

- 11.5.3 Releasing the Username

- 11.5.4 Configuring Username Generation to Support Microsoft Active Directory

- 11.6 Common Name Generation

- 11.6.1 Common Name Generation for Create User Operation

- 11.6.2 Common Name Generation for Modify User Operation

12 Managing Roles

- 12.1 Role Membership Inheritance

- 12.2 Role Permission Inheritance

- 12.3 Role Entity Definition

- 12.3.1 Role Entity

- 12.3.2 Role Category Entity

- 12.3.3 Role Grant Relationship

- 12.3.4 Role Parent Relationship

- 12.4 Default Roles

- 12.5 Role Management Tasks

- 12.5.1 Creating Roles

- 12.5.2 Managing Roles

- 12.5.2.1 Browsing Roles

- 12.5.2.2 Searching for Roles

- 12.5.2.3 Deleting Roles

- 12.5.2.4 Viewing and Administering Roles

- 12.5.2.5 Viewing Menu Items

- 12.5.2.6 Viewing, Assigning, and Revoking Access Policies

- 12.5.2.7 Viewing, Assigning, and Revoking Membership Rules

- 12.5.2.8 Updating Data Object Permissions

- 12.5.3 Creating and Managing Role Categories

- 12.5.3.1 Creating a Role Category

- 12.5.3.2 Searching Role Categories

- 12.5.3.3 Modifying a Role Category

- 12.5.3.4 Deleting a Role Category

- 12.6 Managing Authorization for Roles

- 12.7 Request-Based Role Grants

13 Managing Organizations

- 13.1 Organization Entity Definition

- 13.2 Organization Management Tasks

- 13.2.1 Searching Organizations

- 13.2.1.1 Performing Simple Search

- 13.2.1.2 Performing Advanced Search

- 13.2.2 Browsing Organizations

- 13.2.3 Creating an Organization

- 13.2.4 Viewing and Modifying Organizations

- 13.2.4.1 Modifying Organization Attributes

- 13.2.4.2 Viewing Child Organizations

- 13.2.4.3 Viewing User Information

- 13.2.4.4 Modifying Resources

- 13.2.5 Disabling and Enabling Organizations

- 13.2.6 Managing Administrative Roles

- 13.2.7 Managing Permitted Resources

- 13.2.8 Deleting an Organization

- 13.3 Organization Management Authorization

14 Creating and Searching Requests

- 14.1 Creating Requests by Using Oracle Identity Manager Advanced Administration

- 14.1.1 Creating a Request To Create a User

- 14.1.2 Creating a Request to Provision a Resource to Users

- 14.1.3 Creating a Request to Deprovision Resources

- 14.2 Searching and Tracking Requests

- 14.2.1 Searching Requests

- 14.2.2 Viewing Request Details

- 14.2.2.1 The Requested Resources or Users or Requested Roles Tab

- 14.2.2.2 The Request Comments Tab

- 14.2.2.3 The Request History Tab

- 14.2.2.4 The Approval Tasks Tab

- 14.2.2.5 The Child Requests Tab

Part IV Policy Administration

15 Managing Authorization Policies

- 15.1 Authorization Policy

- 15.2 Creating and Managing Authorization Policies

- 15.2.1 Searching Authorization Policies

- 15.2.1.1 Simple Search

- 15.2.1.2 Advanced Search

- 15.2.2 Creating Custom Authorization Policies

- 15.2.2.1 Creating an Authorization Policy for User Management

- 15.2.2.2 Creating an Authorization Policy for Role Management

- 15.2.2.3 Creating an Authorization Policy for Authenticated User Self Service

- 15.2.3 Creating Authorization Policies Based on Existing Policies

- 15.2.4 Viewing and Modifying Authorization Policies

- 15.2.5 Deleting Authorization Policies

- 15.3 Authorization Policies for Oracle Identity Manager Features

- 15.3.1 User Management

- 15.3.1.1 Assignee

- 15.3.1.2 Functional Security

- 15.3.1.3 Data Security

- 15.3.1.4 Default Authorization Policies

- 15.3.2 Authenticated User Self Service

- 15.3.2.1 Authorization for Profile Attributes

- 15.3.2.2 Authorization for Role Requests

- 15.3.2.3 Authorization for Resource Requests

- 15.3.2.4 Authorization for Proxies

- 15.3.2.5 Default Authorization Policies

- 15.3.3 Role Management

- 15.3.3.1 Assignee

- 15.3.3.2 Functional Security

- 15.3.3.3 Data Security

- 15.3.3.4 Default Authorization Policies

- 15.3.4 Authorization Policy Management

- 15.3.5 User Management Configuration

- 15.3.6 Reconciliation Management

- 15.3.6.1 Assignee

- 15.3.6.2 Functional Security

- 15.3.6.3 Data Security

- 15.3.6.4 Default Authorization Policy

- 15.3.7 Scheduler

- 15.3.8 Request Template Management

- 15.3.9 Request Creation By Using Request Templates

- 15.3.10 Approval Policy Management

- 15.3.11 Notification Management

- 15.3.12 System Properties

- 15.3.13 Diagnostic Dashboard

- 15.3.14 Plug In

16 Managing Access Policies

- 16.1 Terminologies Used in Access Policies

- 16.2 Features of Access Policies

- 16.2.1 Provisioning Options

- 16.2.2 Revoking the Policy

- 16.2.3 Denying a Resource

- 16.2.4 Evaluating Policies

- 16.2.5 Access Policy Priority

- 16.2.6 Access Policy Data

- 16.2.7 Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator

- 16.3 Creating Access Policies

- 16.4 Managing Access Policies

- 16.5 Provisioning Multiple Instances of the Same Resource via Access Policy

- 16.5.1 Creating Separate Accounts for the Same User and Same Resource on a Single Target System

- 16.5.2 Enabling Multiple Account Provisioning

- 16.5.3 Provisioning Multiple Instances of a Resource to Multiple Target Systems

- 16.5.4 Limitation of Provisioning Multiple Instances of a Resource via Access Policy

17 Managing Request Templates

- 17.1 Creating Request Templates

- 17.1.1 Creating a Request Template Based on the Create User Request Type

- 17.1.2 Creating a Request Template Based on the Provisioning Resource Request Type

- 17.2 Searching and Modifying Request Templates

- 17.2.1 Allowed Resources or Allowed Roles

- 17.2.2 Attribute Restrictions

- 17.2.3 Additional Attributes

- 17.2.4 Template User Roles

- 17.3 Cloning Templates

- 17.4 Deleting Templates

18 Managing Approval Policies

- 18.1 Approval Selection Methodologies

- 18.1.1 Request-Level Methodology

- 18.1.2 Operation-Level Methodology: Organization-Based Selection

- 18.1.3 Operation-Level Methodology: Resource-Based Selection

- 18.1.4 Operation-Level Methodology: Role-Based Selection

- 18.2 Creating Approval Policies

- 18.3 Searching Approval Policies

- 18.4 Modifying Approval Policies

- 18.5 Modifying the Priority of an Approval Policy

- 18.6 Deleting Approval Policies

19 Managing Attestation Processes

- 19.1 About Attestation

- 19.1.1 Definition of an Attestation Process

- 19.1.1.1 Attestation Process Control

- 19.1.2 Components of Attestation Tasks

- 19.1.2.1 Attestation Inbox

- 19.1.3 Attestation Request

- 19.1.4 Delegation

- 19.1.5 Attestation Lifecycle Process

- 19.1.5.1 Stage 1: Creation of an Attestation Task

- 19.1.5.2 Stage 2: Acting on an Attestation Task

- 19.1.5.3 Stage 3: Processing a Submitted Attestation Task

- 19.1.6 Attestation Engine

- 19.1.7 Attestation Scheduled Task

- 19.1.8 Attestation-Driven Workflow Capability

- 19.1.9 Attestation E-Mail

- 19.1.9.1 Notify Attestation Reviewer

- 19.1.9.2 Notify Delegated Reviewers

- 19.1.9.3 Notify Process Owner About Declined Attestation Entitlements

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

- 19.2 Attestation Process Configuration

- 19.2.1 Menu Structure

- 19.2.2 System Control

- 19.3 Creating Attestation Processes

- 19.4 Managing Attestation Processes

- 19.4.1 Editing Attestation Processes

- 19.4.2 Disabling Attestation Processes

- 19.4.3 Enabling Attestation Processes

- 19.4.4 Deleting Attestation Processes

- 19.4.5 Running Attestation Processes

- 19.4.6 Managing Attestation Process Administrators

- 19.4.7 Viewing Attestation Process Execution History

- 19.5 Using the Attestation Dashboard

- 19.5.1 Viewing Attestation Request Details

- 19.5.2 E-Mail Notification

- 19.5.3 Attestation Grace Period Checker Scheduled Task

Part V Reporting

20 Using Reporting Features

- 20.1 Reporting Features

- 20.2 Starting Oracle Identity Manager Reports

- 20.3 Running Oracle Identity Manager Reports

- 20.4 Supported Output Formats

- 20.5 Reports for Oracle Identity Manager

- 20.5.1 Access Policy Reports

- 20.5.1.1 Access Policy Details

- 20.5.1.2 Access Policy List by Role

- 20.5.2 Attestation, Request, and Approval Reports

- 20.5.2.1 Approval Activity

- 20.5.2.2 Attestation Process List

- 20.5.2.3 Attestation Request Details

- 20.5.2.4 Attestation Requests by Process

- 20.5.2.5 Attestation Requests by Reviewer

- 20.5.2.6 Request Details

- 20.5.2.7 Request Summary

- 20.5.2.8 Task Assignment History

- 20.5.3 Role and Organization Reports

- 20.5.3.1 Role Membership History

- 20.5.3.2 Role Membership Profile

- 20.5.3.3 Role Membership

- 20.5.3.4 Organization Details

- 20.5.3.5 User Membership History

- 20.5.4 Password Reports

- 20.5.4.1 Password Expiration Summary

- 20.5.4.2 Password Reset Summary

- 20.5.4.3 Resource Password Expiration

- 20.5.5 Resource and Entitlement Reports

- 20.5.5.1 Account Activity In Resource

- 20.5.5.2 Delegated Admins and Permissions by Resource

- 20.5.5.3 Delegated Admins by Resource

- 20.5.5.4 Entitlement Access List

- 20.5.5.5 Entitlement Access List History

- 20.5.5.6 Financially Significant Resource Details

- 20.5.5.7 Fine Grained Entitlement Exceptions By Resource

- 20.5.5.8 Offline Resource Provisioning Messages

- 20.5.5.9 Orphaned Account Summary

- 20.5.5.10 Resource Access List History

- 20.5.5.11 Resource Access List

- 20.5.5.12 Resource Account Summary

- 20.5.5.13 Resource Activity Summary

- 20.5.5.14 Rogue Accounts By Resource

- 20.5.5.15 User Resource Access History

- 20.5.5.16 User Resource Access

- 20.5.5.17 User Resource Entitlement

- 20.5.5.18 User Resource Entitlement History

- 20.5.6 User Reports

- 20.5.6.1 User Profile History

- 20.5.6.2 User Summary

- 20.5.6.3 Users Deleted

- 20.5.6.4 Users Disabled

- 20.5.6.5 Users Unlocked

- 20.6 Exception Reports

- 20.7 Creating Reports Using Third-Party Software

- 20.8 Required Scheduled Tasks for BI Publisher Reports

Index

List of Figures

- 2-1 Oracle Identity Manager Architecture

- 2-2 ICF Architecture

- 2-3 Remote Manager Architecture

- 2-4 OES-Based Authorization Service

- 2-5 Oracle Identity Manager Scheduler Architecture

- 2-6 System Components of Oracle Identity Manager

- 4-1 Provisioning Configuration

- 4-2 Provisioning and Reconciliation

- 4-3 Trusted Source Reconciliation from Single and Multiple Authoritative Sources

- 4-4 Account Reconciliation From a Target System

- 4-5 Identity and Account Reconciliation

- 4-6 Reconciliation Process Flow

- 4-7 Reconciliation Architecture

- 4-8 Oracle Identity Manager and LDAP

- 5-1 Three-Tier Integration Solutions Strategy of Oracle Identity Manager

- 5-2 Functional Architecture of a Generic Technology Connector

- 6-1 Design Components of the Auditing Process

- 9-1 The RFI Task

- 9-2 Available Option for an RFI Task

- 9-3 RFI Task Details

- 9-4 The Add Notes for Task Window

- 9-5 The Select User Assignee for Task Window

- 9-6 The Task History Window

- 9-7 The Attestation Request Detail Window

- 10-1 Request Process Flow

- 10-2 Request Stages

- 10-3 Bulk Request and Child Request Stages

- 10-4 The Request Details Tab

- 10-5 The Requested Roles Tab

- 10-6 The Users Tab

- 10-7 The User Details Window

- 10-8 The Request History Tab

- 10-9 Requests Raised For You

- 11-1 User Life Cycle

- 11-2 Advanced Search Result with Hidden Columns

- 11-3 Sample Process Data

- 11-4 The Reset Password Dialog Box

- 11-5 The System Property Detail Page

- 11-6 The Default Username Policy Configuration

- 12-1 Role Membership and Permission Inheritance

- 13-1 Recursive Organization Membership

- 13-2 Organization Search Result

- 13-3 Advanced Search

- 13-4 Organization Browse List

- 13-5 The Create Organization Page

- 13-6 The Search: Organizations Dialog Box

- 13-7 The Organization Details Page

- 13-8 Assign Administrative Roles

- 13-9 Assign Permitted Resources

- 14-1 Advanced Search Results

- 14-2 The Requested Roles Tab

- 14-3 The Resource Details Window

- 14-4 The Request Comments Tab

- 14-5 The Request History Tab

- 14-6 The Approval Tasks Tab

- 15-1 Authorization Policy Simple Search

- 15-2 Authorization Policy Advanced Search

- 15-3 The Basic Policy Information Page

- 15-4 The Permissions Page

- 15-5 The Data Constraints Page

- 15-6 The Policy Assignment Page

- 17-1 The Set Request Template Details Page

- 17-2 The Select Attributes to Restrict Page

- 17-3 The Set Attribute Restrictions Page

- 17-4 The Set Additional Attributes Page

- 17-5 The Set Template User Roles Page

- 17-6 The Review Request Template Summary Page

- 17-7 Advanced Search Result for Request Templates

- 17-8 The Allowed Resources Tab

- 17-9 The Attribute Restrictions Tab

- 17-10 The Additional Attributes Tab

- 17-11 The Template User Roles Tab

- 18-1 Approval Policy Search Results

- 18-2 Approval Policy Advanced Search

- 19-1 Delegate Attestation

- 19-2 Creating an Attestation Task: Workflow

- 19-3 Flow of Events When Reviewer Responds to Entitlement

- 19-4 Flow of Events After Attestation Task Response Is Submitted

- 19-5 Follow-Up Action Sub-Flow

List of Tables

- 4-1 Types of Reconciliation

- 4-2 Regular and Changelog Reconciliation Modes

- 4-3 Reconciliation Status Events

- 4-4 Action Rules

- 5-1 Connector Components

- 5-2 Provisioning Process Tasks

- 5-3 Reconciliation-Related Provisioning Process Tasks

- 6-1 User Group Membership Tables

- 6-2 User Resource Instance Tables

- 6-3 Resource Lifecycle Process Tables

- 6-4 Definition of the UPA Table

- 6-5 User Profile Audit Tables

- 6-6 Definition of the GPA Table

- 8-1 Profile Management Privileges

- 9-1 Columns in the Full Tasklist View Table

- 9-2 Fields in the Provisioning Tasks Search Results Table

- 9-3 Fields in the Task Details Window

- 9-4 Fields in the Task History Window

- 9-5 Fields in the Attestation Task Search Results Table

- 9-6 Fields in the Attestation Request Detail Window

- 10-1 Request Stages

- 10-2 Default Operations and Request Models

- 10-3 Columns in the Table Showing Request Information

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

- 11-2 Attributes Defined for User Entity

- 11-3 Advanced Search Comparators

- 11-4 Default Search Attributes

- 11-5 Fields in the Create User Page

- 11-6 Fields in the Bulk Modify Page

- 11-7 Authorization Privileges for User Management

- 11-8 Predefined Username Policies

- 11-9 Constants Representing Policy IDs

- 11-10 RDN Modification Scenarios

- 12-1 Default Attributes for the Role Entity

- 12-2 Default Attributes for the Role Category Entity

- 12-3 Default Attributes for Role Grant Relationship

- 12-4 Default Attributes for Role Parent Relationship

- 12-5 Default Roles in Oracle Identity Manager

- 12-6 Fields in the Create Role Page

- 12-7 Data Objects Requiring Explicit Insert/Update/Delete Permissions

- 12-8 Role Management Permissions

- 13-1 Default Attributes of the Organization Entity

- 13-2 Fields in the Create Organization Page

- 14-1 Fields in the Request Details page

- 17-1 Default Request Templates

- 17-2 Fields in the Template Details Section

- 20-1 Scheduled Tasks for BI Publisher Reports

Oracle® Fusion Middleware

User's Guide for Oracle Identity Manager

11g Release 1 (11.1.1)

E14316-09

March 2013

Oracle Fusion Middleware User's Guide for Oracle Identity Manager, 11g Release 1 (11.1.1)

E14316-09

Copyright © 1991, 2013, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Debapriya Datta

Contributing Author:  Prakash Hulikere

Contributor:

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

The Oracle Fusion Middleware User's Guide for Oracle Identity Manager introduces you to Oracle Identity Manager Self Service tasks, and delegated administration functionalities.

Audience

This guide is intended for users who can log in to Oracle Identity Manager and perform Oracle Identity Manager Self Service operations, request for roles and resources, and manage various approval, provisioning, and attestation tasks. This guide is also intended for delegated administrators who can perform identity administration tasks and define authorization policies to delegate administration privileges. In addition, a user with any role can refer to this guide for an introduction and conceptual information about Oracle Identity Manager.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the other documents in the Oracle Identity Management documentation set for this release.

- Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

- Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager

- Oracle Fusion Middleware Installation Guide for Oracle Identity Management

- Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management

- Oracle Fusion Middleware Suite Integration Overview

- Oracle Fusion Middleware User Reference for Oracle Identity Management

- Oracle Fusion Middleware High Availability Guide

- Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager

- Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager

- Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager

- Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator

- Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Part I

Concepts

This part introduces Oracle Identity Manager and describes the concepts related to Oracle Identity Manager.

It contains the following chapters:

- Chapter 1, "Feature Overview"

- Chapter 2, "Architecture"

- Chapter 3, "User Interfaces"

- Chapter 4, "Deployment Configurations"

- Chapter 5, "Integration Solutions"

- Chapter 6, "Auditing"

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:

- User Administration

- Workflow and Policy

- Password Management

- Audit and Compliance Management

- Integration Solutions

- User Provisioning

- Organization and Role Management

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

- Workflow Management

- Dynamic Error Handling

- Transaction Integrity

- Real-Time Request Tracking

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:

- Automated user identity and account provisioning: This manages user identities and accounts in multiple systems and applications. For example, when an employee working in the payroll department is created in the human resources system, accounts are also automatically created for this user in the e-mail, telephone, accounting, and payroll reports systems.

- Workflow and policy management: This enables identity provisioning. Administrators can use interfaces provided by provisioning tools to create provisioning processes based on security policies.

- Reporting and auditing: This enables creating documentation of provisioning processes and their enforcement. This documentation is essential for audit, regulatory, and compliance purposes.

- Attestation: This enables administrators to confirm users' access rights on a periodic basis.

- Access deprovisioning: When the access for a user is no longer required or valid in an organization, Oracle Identity Manager revokes access on demand or automatically, as dictated by role or attribute-based access policies. This ensures that a user's access is promptly terminated where is it no longer required. This is done to minimize security risks and prevent paying for access to costly resources, such as data services.

1.1.7 Organization and Role Management

An organization entity represents a logical container of other entities such as users, roles, and policies in Oracle Identity Manager. In other words, organizations are containers that can be used for delegated administrative model. In addition, organizations define the scope of other Oracle Identity Manager entities, such as users. Oracle Identity Manager supports a flat organization structure or a hierarchical structure, which means that an organization can contain other organizations. The hierarchy can represent departments, geographical areas, or other logical divisions for easier management of entities.

Roles are logical groupings of users to whom you can assign access rights within Oracle Identity Manager, provision resources automatically, or use in common tasks such as approval and attestation. Roles can be independent of organizations, span multiple organizations, or can contain users from a single organization.

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:

- Key Features and Benefits

- How Oracle Identity Manager Works: The Tiers of Oracle Identity Manager

- System Components

2.1 Key Features and Benefits

Oracle Identity Manager architecture is flexible and scalable, and provides the following features:

- Ease of Deployment

- Flexibility and Resilience

- Maximum Reuse of Existing Infrastructure

- Extensive User Management

- Web-Based User Self-Service

- Modular and Scalable Architecture

- Based on Leading Software Development Standards

- Powerful and Flexible Process Engine

- Built-In Change Management

2.1.1 Ease of Deployment

Oracle Identity Manager provides a flexible Deployment Manager utility to assist in the migration of integration and configuration information between environments. The utility exports integration and configuration information as XML files. These files are then imported into the destination environment, which can be staging or production. You can use the XML files to archive configurations and maintain versions, as well as replicate integrations.

The Deployment Manager provides you with the flexibility to select what to import and export. It also helps you to identify data object dependencies during both import and export steps. This flexibility enables you to merge integration work done by multiple people and to ensure the integrity of any migration.

2.1.2 Flexibility and Resilience

You can deploy Oracle Identity Manager in single or multiple server instances. Multiple server instances provide optimal configuration options, supporting geographically dispersed users and resources for increased flexibility, performance, and control. The Java 2 Enterprise Edition (J2EE) application server model of Oracle Identity Manager also provides scalability, fault tolerance, redundancy, failover, and system load balancing. As deployments grow, moving from a single server to a multiserver implementation is a seamless operation.

2.1.3 Maximum Reuse of Existing Infrastructure

To lower cost, minimize complexity, and leverage existing investments, Oracle Identity Manager is built on an open architecture. This allows Oracle Identity Manager to integrate with and leverage existing software and middleware already implemented within the IT infrastructure of an organization. For example, if an implementation requires integrating with an existing customer portal, then the advanced APIs of Oracle Identity Manager offer programmatic access to a comprehensive set of system functions. This allows IT staff to customize any part of its Oracle Identity Manager provisioning implementation to meet the specific needs of the organization.

2.1.4 Extensive User Management

Oracle Identity Manager enables you to define unlimited user organizational hierarchies and roles. It supports inheritance, customizable user ID policy management, password policy management, and user access policies that reflect customers' changing business needs. It also helps you to manage application parameters and entitlements, and to view a history of resource allocations. In addition, it provides delegated administration with comprehensive permission settings for user management.

Oracle Identity Manager contains a Web-based customizable Oracle Identity Manager Self Service that helps you extensively in user management.

2.1.5 Web-Based User Self-Service

Oracle Identity Manager contains a customizable Web-based, user self-service portal. This portal enables management of user information, changing and synchronizing passwords, resetting forgotten passwords, requesting available applications, reviewing and editing available entitlements, and initiating or reacting to workflow tasks.

2.1.6 Modular and Scalable Architecture

Oracle Identity Manager is built on Java EE architecture. 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.

Java EE is a standard, robust, scalable, and secure platform that forms the basis for many enterprise applications. Oracle Identity Manager runs on leading Java EE compliant application server platforms, including Oracle WebLogic, to take advantage of the performance and scalability features inherent in these servers. Java EE defines a set of standardized, modular components, provides a complete set of services to those components, and handles many details of the application behavior.

The application server, on which Oracle Identity Manager runs, provides the life-cycle management, security, deployment, and run-time services to the logical components that constitute the Oracle Identity Manager application. These services include:

- Scalable management of resources through clustering and failover: A cluster in Java EE architecture is defined as a group of two or more Java EE compliant Web or application servers that cooperate with each other through transparent object replication mechanisms to ensure that each server in the group presents the same content. Each server or node in the cluster is identical in configuration and acts as a single virtual server. Any Java EE server in the cluster can handle client requests directed to this virtual server independently, which gives the impression of a single entity hosting the Java EE application in the cluster.
High availability refers to the capability to ensure that applications hosted in the middle tier remain consistently accessible and operational to the clients. This is achieved through the redundancy of multiple Web and application servers within the cluster, and is implemented by the failover mechanisms of the cluster. If an application component fails to process its task, then the cluster's failover mechanism reroutes the task and any supporting information to a copy of the object on another server to continue the task. Oracle Identity Manager supports a clustered environment. This includes ensuring that the EJBs and the Value Objects used to store data support serialization for the object replication to work.

- Transaction management through load balancing: Load balancing refers to the capability to optimally partition inbound client processing requests across all the Java EE servers that constitute a cluster based on certain factors, such as capacity, availability, response time, current load, historical performance, and administrative priorities placed on the clustered servers. A load balancer, which can be based on software or hardware, sits between the Internet and the physical server cluster, acting as a virtual server. When each client request arrives, the load balancer decides how the Java EE server satisfies that request.

- Security management: Oracle Identity Manager architecture relies on the application server for certain security services as part of its overall security infrastructure. In addition, Oracle Identity Manager leverages the Java EE security framework to provide a secure application environment. It also has a flexible permission model to provide control over the various functions within the application

- Messaging: The basic concept behind messaging is that distributed applications can communicate by using a self-contained package of business data and routing headers. These packages are called messages. While RMI and HTTP rely on a two-way active communication between a client and a server, messaging relies on two or more interested parties communicating asynchronously through a messaging server without waiting for a response. Java Messaging Service (JMS) is a wrapper API incorporated in the J2EE standard as a way to standardize messaging functionality. All standard application servers provide their own JMS server implementations as a part of their service offerings.

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.8 Powerful and Flexible Process Engine

With Oracle Identity Manager, you can create business and provisioning process models in easy-to-use applications. Process models include support for approval workflows and escalations. You can track the progress of each provisioning event, including the current status of the event and error code support. Oracle Identity Manager supports complex, branching, and nested processes with data interchange and dependencies. The process flow is fully customizable and does not require programming.

2.1.9 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:

- Presentation Tier

- Business Services Tier

- The Data Tier

Figure 2-1 illustrates Oracle Identity Manager architecture.

Figure 2-1 Oracle Identity Manager Architecture

Description of "Figure 2-1 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 Web 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 for which they are authorized.

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.1 The API Services

The API Services 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 API Services consist of:

- SPML APIs: Service Provisioning Markup Language (SPML) is a standard for managing the provisioning and allocation of identity information and system resources within and between organizations. Oracle Identity Manager supports a set of SPML-based Web services that expose identity administration functionality to the clients. The APIs provide support for:

- Adding, modifying, and deleting identities

- Adding, modifying, and deleting roles

- Adding and deleting role memberships

These APIs support requests coming into Oracle Identity Manager for administration purposes, which is distinct and separate from SPML as the protocol used to integrate with provisioning targets.

- EJB APIs: Highly granular access to the functionality of the platform is via a set of EJB. These session beans are the basis for functionality implemented in Oracle Identity Manager Web application clients. It is also the interface that custom clients can use to access Oracle Identity Manager capabilities.

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:

- Connector Framework

- Adapter Factory

- Generic Technology Connector

- Remote Manager

See Also:

"Integration Solutions" for details about how to define adapters by using the Adapter Factory.

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:

Figure 2-2 ICF Architecture

Description of "Figure 2-2 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.

- The required interfaces include the org.identityconnectors.framework.spi.Connector interface and the org.identityconnectors.framework.spi.Configuration interface. These interfaces must be implemented in order for the API to understand which class contains the implementation of the configuration and which contains the implementation of the operations.

- The feature-based interfaces are the org.identityconnectors.framework.spi.AttributeNormalizer and org.identityconnectors.framework.spi.PoolableConnector interfaces.

- The operation interfaces determine the features that the connector supports such as create, delete, or search. See Oracle Fusion Middleware Java API Reference for Oracle Identity Manager for details.

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.3 Adapter Factory

The Adapter Factory is a code-generation tool provided by Oracle Identity Manager. It enables an Oracle Identity Manager application developer to create Java classes, known as adapters.

A resource has an associated provisioning process, which in turn has various tasks associated with it. Each task in turn has an adapter associated to it, which in turn can connect to the target resource to carry out the required operations.

An adapter provides the following benefits:

- It extends the internal logic and functionality of Oracle Identity Manager.

- It interfaces with any software resource by connecting to that resource with the help of the API of the resource.

- It enables the integration between Oracle Identity Manager and an external system.

- It can be generated without manually writing code.

- It can be maintained easily because all the definitions for the adapter are stored in a repository. This repository can be edited through a GUI.

- A user in Oracle Identity Manager can retain the domain knowledge about the integration, while another user can maintain the adapter.

- It can be modified and upgraded.

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 the definitions and creates self-documenting views. You use these views to extend, maintain, and upgrade connectors.

See Also:

"Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager" for details about how to define adapters by using the Adapter Factory

2.2.2.2.4 Generic Technology Connector

Predefined Oracle Identity Manager connectors are designed for commonly used target systems such as Microsoft Active Directory and PeopleSoft Enterprise Applications. The architecture of a predefined connector is based on either the APIs that the target system supports or the data repository type and schema in which the target system stores user data.The use of a predefined connector is the recommended integration method when such a connector is available for the target system. However, in some instances you might want to integrate Oracle Identity Manager with a target system that has no corresponding predefined connector. For example, XYZ Travels Inc. owns a custom Web-based application that its customers use to request airline fare quotes. Agents, who are also employees of XYZ Travels, respond to these requests by using the same application. Customers register themselves to create accounts in this application. However, XYZ Travels employees need to have accounts auto-provisioned based on their HR job title. Account management functions, such as create, update, and delete, of the application are available through Java APIs. There is no predefined connector available to integrate the custom application with Oracle Identity Manager. Therefore, you must create the custom connectors that call the Java APIs exposed by the target application.

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. These 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.2.5 Remote Manager

When your adapter uses Java tasks, you must configure Oracle Identity Manager to find the appropriate Java APIs. The Java APIs are located in JAR files in the Meta Data Store (MDS). Sometimes, instead of directly communicating with the third-party system, Oracle Identity Manager must use an Oracle Identity Manager component that acts like a proxy. This component is known as Remote Manager. The Remote Manager is used for:

- Invoking nonremotable APIs through Oracle Identity Manager

- Invoking APIs that do not support Secure Sockets Layer (SSL) over secure connections

The Remote Manager is an Oracle Identity Manager server component that runs on a target system computer. It provides the network and security layer required to integrate with applications that do not have network-aware APIs or do not provide security. It is built as a lightweight Remote Method Invocation (RMI) server. The communication protocol is RMI tunneled through Hypertext Transfer Protocol/Secure (HTTP/S).

The J2EE RMI framework enables the creation of virtually transparent, distributed services and applications. RMI-based applications consist of Java objects making method calls to one another, regardless of their location. This enables one Java object to call methods on another Java object residing on another virtual computer in the same manner in which methods are called on a Java object residing on the same virtual computer.

Figure 2-3 shows an overview of the Remote Manager architecture.

Figure 2-3 Remote Manager Architecture

Description of "Figure 2-3 Remote Manager Architecture"

See Also:

"Installing and Configuring a Remote Manager" for information about the Remote Manager and its configuration in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

2.2.2.3 Platform Services

The Platform Services include:

- Request Service

- Authorization Service

- Plug-In Framework

- SoD Engine Framework

- Scheduler Service

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 run time whether or not a particular action is allowed. This is controlled by the authorization service that uses Oracle Entitlements Server (OES) embedded within Oracle Identity Manager. OES is an authorization product and 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:

Figure 2-4 OES-Based Authorization Service

Description of "Figure 2-4 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.3 Plug-In Framework

The Plug-in Framework allows customers to easily extend and customize the capabilities of the out-of-the-box Oracle Identity Manager features. The features expose specific plug-in points in the business logic where extensibility can be provided. An interface definition accompanies each such point and is called the plug-in interface. Customers can create code that extends these plug-in interfaces and defines customizations based on their business needs. These plug-ins are deployed and registered with Oracle Identity Manager by using the Plug-in Manager. Oracle Identity Manager then incorporates the plug-ins into the feature processing from that point onward.

Feature developers do not have to keep a track of where the custom implementations are stored and how they are loaded. The plug-in framework supports loading plug-ins from the classpath, from the file system, and from the database.

See Also:

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

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.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about SoD

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.

Figure 2-5 Oracle Identity Manager Scheduler Architecture

Description of "Figure 2-5 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:

- Oracle Identity Manager Database

- The Metadata Store

- The Identity Store

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.

Figure 2-6 System Components of Oracle Identity Manager

Description of "Figure 2-6 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

- Provisioning

- Audit and Reports

- Reconciliation and Bulk Load

- Common Services

- Workflow and Request Management

- Infrastructure and Middleware Integration

- Connector Framework

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:

- "Reconciliation Configuration" for detailed information about reconciliation

- "Managing Reconciliation Events" for information about managing reconciliation events in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

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:

- Form Designer: A form that allows you to create process and resource object forms that do not come packaged with Oracle Identity Manager. See "Form Designer Form" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for detailed information about the Form Designer.

- Scheduler: A service that provides the capability to run specific jobs at specific schedules. This service can be used by users, application developers, connector developer, and administrators to create and configure a Job to be run at specified intervals. In addition, this service provides administrative capabilities to manage the functionality of jobs and their schedules. See the "Managing Scheduled Tasks" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information.

- Notification Templates: A common notification service is used by other functional components to send notifications to interested parties about events occurring in Oracle Identity Manager. In addition, this service provides the administrative capabilities for notification template management. A notification template is used for sending the outgoing notifications. These templates typically contain the variables that refer to the available data to provide more contextual content. See the "Creating and Managing Notification Templates" chapter for more information.

- System Properties: A system property is an entity that controls the configuration aspect of an application. In addition, to the default system properties, you can create and manage system properties in Oracle Identity Manager. See the "Administering System Properties" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information.

- Deployment Manager: The Deployment Manager is a tool for exporting and importing Oracle Identity Manager configurations. The Deployment Manager enables you to export the objects that make up your Oracle Identity Manager configuration. See "Importing and Exporting Data Using the Deployment Manager" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information.

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

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:

- Overview of Oracle Identity Manager Administrative and User Console

- Overview of Oracle Identity Manager Design Console

- SPML Web Service

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:

- User Self Service

- Oracle Identity Administration

- Oracle Identity Manager Advanced Administration

- Customizing Oracle Identity Manager Administrative and User Console

- Localizing User Interfaces

Note:

If you are using Microsoft Internet Explorer versions 8 or 9 to access Oracle Identity Manager Administrative and User Console, then it is highly recommended to disable the compatibility view for the UI elements to be displayed correctly. Depending on the web browser version that you are using, perform one of the following procedures to disable the compatibility view:

For Microsoft Internet Explorer version 8:

1. Open Microsoft Internet Explorer.

2. From the Tools menu, select Compatibility View Settings. The Compatibility View Settings dialog box is displayed.

3. Remove the host name or domain name of the Oracle Identity Manager server from the Websites you've added to Compatibility View section, if present.

4. Ensure the Display intranet sites in Compatibility View checkbox is deselected.

5. Click Close.

For Microsoft Internet Explorer version 9:

1. Open Microsoft Internet Explorer.

2. From the Tools menu, select Developer Options.

3. In the Developer Options window that is displayed, from the Browser Mode: IE9 menu, select Internet Explorer 9.

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

- Managing Self Profile
Using the user self service, you can modify basic information associated with your Oracle Identity Manager user profile. Managing self profile includes updating user attributes for self, and requesting and removing roles and resources.

- Managing Proxies
The user self service lets you delegate your task approval responsibilities to another user if you are unavailable because of illness or vacation.

- Password Management
You can also change passwords at will, or from time to time depending on system requirements.

- Viewing and Resources and Requests
The user self service lets you view resources that have been provisioned to you. This Web client also lets you view all resource requests that you have submitted for yourself and those made by other users for you. You can also request provisioning of a new resource. You can request for resources or roles for other users as well. In addition, depending on the privileges, you can raise a request for creating and modifying users.

- Managing Tasks in the Tasklist
The process for approving requests and their associated resources consists of multiple tasks, so as the process for making a request and resources available for provisioning. The TaskList consists of the following:

- Approval Tasks: Related to any type of request (not just related to provision resource) assigned to you or pending your actions

- Provisioning Tasks: Related to provisioning tasks that are assigned to you or pending your actions

- Attestation Tasks: Related to attestation processes assigned to you or pending your actions

See Also:

Part II, "Oracle Identity Manager Self Service" for detailed information about completing tasks using Oracle Identity Manager Self Service

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:

- Searching Records
Many fields in Oracle Identity Manager have lookup capabilities. You use them when you want to locate a record. To locate a record, you must enter data in one or more fields to limit the records retrieved by your search. You can also use wildcard characters in addition to the data that you enter in the fields.

Note:

The manner in which the search is constructed and run depends on the type of search you perform. The results retrieved are based on the context in which you are conducting the search.

Oracle Identity Manager supports simple and advanced search. Simple search operation lets you search records based on the search strings that you specify as search attributes. This operation is also referred to as simple search or quick search. Advanced search operation presents a form, which allows you to specify more complex search criteria than the simple search operation.

- Creating and Managing User Records
Using Oracle Identity Administration, you can create and manage user records.

- Creating and Managing Organizations
Using Oracle Identity Administration, you can create and manage organization records. You can also enable, disable, revoke, and provision resources, organizations, and suborganizations.

- Creating and Managing Roles
Using Oracle Identity Administration, you can define roles that represent logical groupings of users to whom you can assign access rights within Oracle Identity Manager, provision resources automatically, or use in common tasks such as approval and attestation. Roles can be independent of organizations, span multiple organizations, or can contain users from a single organization.

- Creating and Managing Authorization Policies
Authorization policy management is centralized as an administrative feature. This is achieved by integrating Oracle Identity Manager with Oracle Entitlements Server (OES) as the authorization system, which secures the access control to the application. In addition, you can create context-sensitive authorization policies for various features in Oracle Identity Manager. Authorization policies control access to the application by the users to allow or prevent the users to perform various operations in the application.

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:

- Administration features:

- Creating and Tracking Requests
Oracle Identity Manager enables you to create and manage requests for various operations or actions, such as provisioning resources and creating and managing users and roles for other users. Based on the privileges granted to you by Oracle Identity Manager, you can use Advanced Administration to create and track requests. Request tracking is to be able to view the request details including basic information, request history, request comments, and the request approval tasks.

- Generating Reports
Based on your requirement, you can use Advanced Administration to generate reports in BI Publisher, which is the reporting solution in Oracle Identity Manager 11g Release 1 (11.1.1). The reports are classified based on functional areas, such as Access Policy Reports, Attestation Reports, Request and Approval Reports, and Password Policy Reports.

- Event management features:

- Managing Reconciliation Events
The reconciliation process involves generation of events to be applied to Oracle Identity Manager. These events reflect atomic changes in the target system, and contain the data that has changed, the type of change, along with other information. Advanced Administration allows you to manage the reconciliation events by querying the events stored, displaying event details, and performing the actions required to resolve event issues.

- Viewing Attestation Tasks and Processes
You can use Advanced Administration to view attestation reports assigned to you, and provide your attestation response to each individual item within the report.

In Oracle Identity Manager, attestation is supported through the definition of scheduled attestation processes. 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.

- Policy features:

- Creating and Managing Access Policies
You can create and manage access policies that define how resources are to be automatically provisioned or deprovisioned for users based on business rules. The Access Policy Wizard in Advanced Administration helps you define an access policy for provisioning resources to users that are members of the roles to which the access policy is attached. The access policy can also specify the entitlements to be provisioned to the account created during provisioning. Advanced Administration also enables you to modify information in existing access policies.

- Creating and Managing Approval Policies
Approval policy is a configurable entity of request management that helps associate various request types with approval processes defined in the request service only for request and operation level approvals. You can use Advanced Administration to create, modify, and delete approval policies.

- Creating and Managing Attestation Processes
Advanced Administration allows you to define new attestation processes, manage existing attestation processes, and start ad-hoc attestation processes. The Attestation Dashboard feature in Advanced Administration allows you to create, modify, disable, enable, run, and delete attestation processes.

- Configuration features:

- Configuring User Management
Oracle Identity Manager user management feature is configured and customized by using the configuration management feature. Configuration management helps customize the way in which the user records are displayed in Oracle Identity Manager Administrative and User Console and configure the user entity operations and attributes. Based on the operations performed on an entity, a set of attributes is displayed to the user in Oracle Identity Manager Administration. You can use Advanced Administration to define user entity data structure and configure user management operations and operational attributes.

- Managing Resources
You can use the Resource Management feature of Advanced Administration to manage resource objects for an organization or an individual user. Managing resources includes the following activities:

- Search for a resource and view its details

- Manage Resource Administrator and Authorizer groups

- View and edit the workflow

- Define Resource audit objectives

- Define and manage IT Resources

- Define and manage scheduled tasks

- Creating and Managing Request Templates
Request templates allow you to customize a request type for a purpose. Every request type has a default template, which cannot be deleted or renamed. Name of the default template is same as the request type. Advanced Administration allows you to create and manage custom request templates to customize the request types based on requirement.

- Creating and Managing Generic Connectors
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. You can use Advanced Administration to create and modify generic technology connectors, and to import and export connector XML files that contain definitions for all the objects that are part of the connector.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about how to create and manage generic technology connectors

- System management features:

- Creating and Managing Scheduler Jobs
In Oracle Identity Manager, it is often required to run jobs at specified times on a regular basis to manage various activities. A job is a task that can be scheduled to run at the specified interval. The scheduler feature enables you to schedule jobs that automatically run predefined scheduled tasks at the specified time. Advanced Administration allows you to create, modify, disable, enable, and delete jobs.

- Creating and Managing Notification Templates
A notification template is used to send notification e-mail messages to requesters, beneficiaries, or administrators about events occurring in Oracle Identity Manager. These templates contain variables that refer to available data to provide more context to the notifications. Using Advanced Administration, you can create, modify, delete notification templates, and add or remove locales from notification templates.

- Creating and Managing System Properties
The system configuration service enables you to manage system properties used by Oracle Identity Manager. System properties define the characteristics that control the behavior of Oracle Identity Manager. You can define the administration and self-service functionalities of Oracle Identity Manager by using system properties. The system configuration service in Advanced Administration allows you to create, modify, delete, and search existing system properties depending on their roles.

- Using the Deployment Manager
The Deployment Manager tool, accessed through Advanced Administration, helps you to export and import Oracle Identity Manager configurations. The Deployment Manager enables you to export the objects that form your Oracle Identity Manager configuration. Usually, you use the Deployment Manager to migrate a configuration from one deployment to another.

3.1.4 Customizing Oracle Identity Manager Administrative and User Console

You can customize the various aspects of Oracle Identity Manager Administrative and User Console. Oracle Identity Manager allows you to customize UI elements, such as branding information, menu options, and columns in search result tables, to be customized to meet the requirement of the organization.

You can customize the following components of Oracle Identity Manager Administrative and User Console:

- Branding information, such as branding text, logo image, and logo mouseover text

- Button labels

- Menus and Tabs

- Columns in search result tables

- Form templates

- Custom URLs

- Popup properties

- Colors, font, and alignment

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about how to customize the different components of Oracle Identity Manager Administrative and User Console

3.1.5 Localizing User Interfaces

Localization is the process of rendering User Interface (UI) to the end user based on the locale setting. Oracle Identity Manager uses the locale setting in the following order:

1. Oracle Access Manager (OAM) protected environments - If OAM login screen provides a language selection option and the user selects a language, then it is provided the highest preference.

2. Browser locale, if there is an issue in retrieving this locale, then the next option is evaluated.

3. Server locale, the locale with which the server is installed.

See Also:

"Setting the Language for Users" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information on localizing user interfaces

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:

- Field Types
The behavior of the basic features of Oracle Identity Manager Design Console is standard for all forms to enable ease of use. You can view records that are displayed in the data fields. You can also search for values by using the lookup fields. For example, the Date & Time window enables you to select a date, month, year, and time.

In addition, you can enter supplemental information about a record in the notes window. Oracle Identity Manager Design Console also lets you select and assign available entities to a record.

- Search Functions
Using Oracle Identity Manager Design Console, you can perform searches for records in a database, also known as queries. Every form in Oracle Identity Manager Design Console provides a search function. You can filter the search criteria in a form field. This limits the results that are returned to only the records that match the criteria you entered.

You can also use a wildcard in a search. The asterisk (*) wildcard character represents unspecified portions of the search criteria. For example, if you enter B* in the Location field of a Oracle Identity Manager Design Console form and execute a search, you retrieve all records with locations that begin with the letter B, for example, Burbank, Boston, Bristol, and so on.

Note:

If multiple records in the database match your search criteria, then you can view details of each record.

- User Management
Oracle Identity Manager Design Console lets you perform the following user management functions:

- Define default values for certain process form parameters at the organizational level

- Display resources that are allowed or disallowed by policies for each user

- Define what forms and folders on Oracle Identity Manager Design Console are allowed for which roles

It also enables you to view, analyze, correct, link, and manage information in reconciliation events received from target resources and the trusted source.

- Resource Management
You can manage resources in Oracle Identity Manager by using Oracle Identity Manager Design Console. The different tasks that you can perform in resource management are:

- Create resource types that appear as lookup values on IT resources from.

- Create rules that can be applied to password policy selection, auto-group membership, provisioning process selection, task assignment, and pre-populating adapters.

- Create and manage resource objects.

- Process Management
Process management includes creating and managing Oracle Identity Manager processes and templates for e-mail notifications.

An Oracle Identity Manager process is the mechanism for representing a logical workflow for approvals or provisioning. Process definitions consist of tasks that you must perform to complete a process. Using Oracle Identity Manager Design Console, you can create and manage the provisioning processes that are associated with the resource objects.

- Oracle Identity Manager Administration
Oracle Identity Manager Design Console provides you with tools to manage Oracle Identity Manager administrative features. You can perform various administrative tasks for Oracle Identity Manager by using these tools. Oracle Identity Manager Design Console also lets you create and manage lookup fields and their values, and user-defined fields.

Using this console, you can specify the value of properties that control the behavior of the client and server. You can also display information about servers that Oracle Identity Manager uses to communicate with third-party programs. In addition, you can set up schedules for when tasks should be run.

- Development Tools
Oracle Identity Manager Design Console contains a suite of development tools that enable you or developers to customize Oracle Identity Manager.

You can create and manage the code that enables Oracle Identity Manager to communicate with any IT Resource by connecting to that resource's API. This code is known as an adapter. You can also compile multiple adapters simultaneously.

Oracle Identity Manager Design Console lets you create error messages that are displayed when certain problems occur. In addition, you can create and manage event handlers, data objects, and reconciliation rules that are used in Oracle Identity Manager.

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

4 Deployment Configurations

This chapter discusses the following deployment configurations of Oracle Identity Manager:

- Provisioning Configuration

- Reconciliation Configuration

- Integration Between LDAP Identity Store and Oracle Identity Manager

4.1 Provisioning Configuration

Provisioning is the process by which any action to create, modify, or delete a target system identity initiated in the provisioning system (Oracle Identity Manager) is communicated to the target system. Changes made to the identity triggers a set of provisioning actions. For deployments on which Oracle Identity Manager has the identities in its own repository, changes made to the identity attributes are detected and the provisioning actions are triggered accordingly.

You can use Oracle Identity Manager to create, maintain, and delete users on target systems. In this configuration, Oracle Identity Manager acts as the front-end entry point for managing all the user data on the target systems. After accounts are provisioned, the users for whom the accounts have been provisioned can access the target systems without any interaction with Oracle Identity Manager. This is the provisioning configuration of Oracle Identity Manager.

The purpose of provisioning is to automate the creation and maintenance of users on target systems. Provisioning is also used to accommodate any requirement for workflow approvals and auditing that can be a component of that provisioning life cycle. Figure 4-1 illustrates the working of the provisioning module.

Figure 4-1 Provisioning Configuration

Description of "Figure 4-1 Provisioning Configuration"

Provisioning events can be started through any of the following ways:

- Request-based provisioning
A request can be manually created by an administrator or, in certain instances, by users themselves. Approval workflows are started after a request is submitted and provisioning of the approved account profile is started after the approval is completed.

- Policy-based provisioning
This type of provisioning refers to the automation of target resources being granted to users through access policies. Access policies are used to define the association between roles and target resources. By default, each member of these roles gets a predefined account in the target resource.

- Direct provisioning
This type of provisioning is a special administrator-only function. An authorized administrator can create an account. An account for a particular user can be created on a target system without having to wait for any approval processes.

4.2 Reconciliation Configuration

Reconciliation is the process by which operations, such as user creation, modification, or deletion, started on the target system are communicated to Oracle Identity Manager. The reconciliation process compares the entries in Oracle Identity Manager repository and the target system repository, determines the difference between the two repositories, and applies the latest changes to Oracle Identity Manager repository.

Reconciliation of roles, role memberships, and role hierarchy changes are handled as separate reconciliation events. Ideally role events must be submitted first and then only the membership events in order to avoid race conditions. For race conditions, the automatic retry logic allows the reconciliation engine to handle it. More details in race condition section. For information about roles, role memberships, and role hierarchies, see "Managing Roles".

See Also:

"Handling of Race Conditions" for information about race conditions in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

Figure 4-2 shows that provisioning and reconciliation involve synchronization from Oracle Identity Manager to the target system or from the target system to Oracle Identity Manager. Provisioning and reconciliation enable the provisioning system to build the managed identities in the target system as well as replicate the managed identities as they already exist in the target system.

Figure 4-2 Provisioning and Reconciliation

Description of "Figure 4-2 Provisioning and Reconciliation"

In Figure 4-2, a user is created by the HR representative when a new employee joins. The user is reconciled to Oracle Identity Manager by trusted source reconciliation. When the user is created in Oracle Identity Manager, the account for the user is provisioned in the target system. In the target system, the target system administrator can make changes in the account, which must be reconciled to Oracle Identity Manager.

In terms of data flow, provisioning provides the outward flow from the provisioning system by using a push model, in which the provisioning system indicates the changes to be made to the target system. Reconciliation provides the inward flow into the provisioning system by using either a push or a pull model, by which the provisioning system finds out about any activity on the target system.

The reconciliation process involves generation of events to be applied to Oracle Identity Manager. These events reflect atomic changes in the target system, and contain the data that has changed, the type of change, along with other information. The reconciliation events that are generated consequently because of changes occurring in the target system are managed by using the Reconciliation Event Manager in Oracle Identity Manager Administration console, which addresses these event management needs.

See Also:

"Managing Reconciliation" for information about managing reconciliation events by using Oracle Identity Manager Administration console in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

This section consists of the following topics:

- Types of Reconciliation

- Reconciliation Architecture

4.2.1 Types of Reconciliation

Reconciliation can be of different types, as shown in Table 4-1:

Table 4-1 Types of Reconciliation

Classification Criteria

Reconciliation Type

Object being reconciled

Based on identity being reconciled, such as user, account, role, or relationship that includes role hierarchy and role membership

Note: Oracle Identity Manager does not support reconciliation of organizations.

Mode of reconciliation

Changelog

Regular

Approach used for reconciliation

Incremental reconciliation

Full reconciliation

This section describes the following topics:

- Reconciliation Based on the Object Being Reconciled

- Mode of Reconciliation

- Approach Used for Reconciliation

4.2.1.1 Reconciliation Based on the Object Being Reconciled

Reconciliation depends on the entity object that is being reconciled. The following entities in Oracle Identity Manager are reconciled:

- User: A user is an identity that exists within and is managed through Oracle Identity Manager.

- Account: An account is granted to a user to give the user the ability to log in to Oracle Identity Manager and access Oracle Identity Manager features. At the minimum, these features involve self-service and request. An account can be granted additional privileges including the ability to define workflows and the delegated administration of various entities, such as users, organizations, and roles.

- Role: A role is a logical grouping of users to whom you can assign access rights within Oracle Identity Manager, provision resources automatically, or use in common tasks such as approval and attestation.

- Role hierarchy: Role hierarchy is the inheritance of the parent role to child roles. The parent role has the same permissions and privileges on the members as the inherited roles.

- Role membership: Role membership means that the members of the inheritor role inherit from the inherited role. See "Managing Roles" for detailed information about membership and permission inheritance.

This section discusses the following topics:

- Trusted Source Reconciliation

- Account Reconciliation

- Reconciliation Process Flow

4.2.1.1.1 Trusted Source Reconciliation

If data is reconciled from a system that drives the creation of users, roles, role memberships, or role hierarchies in Oracle Identity Manager repository, then that reconciliation mode is called identity reconciliation, or authoritative source reconciliation, or trusted source reconciliation. The system that is being reconciled from is referred to as the authoritative source for the enterprise identities, and may be an HR system or a corporate directory.

Note:

If the user login is not passed for trusted reconciliation, then the login handler generates the user login. The password is generated in postprocessing event handler, and notification is sent for the same. See "Customizing Reconciliation Operations" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about event handlers.

As shown in Figure 4-3, the authoritative sources of identity may be more than one. The different authoritative sources may be the source of reconciliation for different categories of user identities or may be the source of reconciliation for different sets of attributes. The various events generated by the reconciliation engine are add, modify, and delete.

Figure 4-3 Trusted Source Reconciliation from Single and Multiple Authoritative Sources

Description of "Figure 4-3 Trusted Source Reconciliation from Single and Multiple Authoritative Sources"

In Figure 4-3, trusted source reconciliation from a single authoritative source and multiple authoritative sources are shown. Creation of user entities can be reconciled from multiple authoritative sources. In addition, different attributes can be reconciled from different multiple authoritative sources. For example, the user ID and e-mail ID can be provided by an authoritative source and role attributes can be provided by another authoritative source.

Trusted source reconciliation must be followed by account reconciliation when the target system is the source for identities as well as accounts. For instance, if Active Directory is the corporate LDAP repository in which user information is stored, then the user information is reconciled from the Active Directory target system. Subsequently, the Active Directory accounts are reconciled into Oracle Identity Manager by using a different connector. Identity reconciliation occurs only from trusted sources, by using connectors specific to those trusted sources.

Note:

A reconciliation connector is a component developed to reconcile identities or accounts from a specific target system. Typically, a reconciliation connector is configured to be run as a scheduled task. However, there are push-based connectors, such as the PeopleSoft HR connector, for which there is no scheduled task to trigger the reconciliation.

4.2.1.1.2 Account Reconciliation

If the target system identities are accounts that get reconciled to Oracle Identity Manager, then that is target resource reconciliation or account reconciliation. This type of reconciliation is to reconcile a specific resource object that represents the target system being managed. There is always a corresponding provisioning flow for it. The identity retrieved from the target system maps to a resource object instance that has been provisioned to a user or organization.

Account reconciliation takes place in the following scenarios:

Scenario I

Identity gets created in Oracle Identity Manager from an authoritative source. The identities are provisioned with resources on the target system. Any change on the target system is reconciled with Oracle Identity Manager. Figure 4-4 shows account reconciliation from a target system:

Figure 4-4 Account Reconciliation From a Target System

Description of "Figure 4-4 Account Reconciliation From a Target System"

Scenario II

In this scenario, the target system initially plays the role of an authoritative source. Later it plays the role of a regular provisioning target. Following are the sequence of steps:

1. Identities are created in Oracle Identity Manager based on the target system entity details. Corresponding accounts are also created for these entities.

2. The entities are updated as provisioned entities in the target system.

3. The resource administrator at the target system makes changes to the accounts.

4. The changes made on the target system are reconciled with Oracle Identity Manager.

Figure 4-5 shows identity reconciliation followed by account reconciliation:

Figure 4-5 Identity and Account Reconciliation

Description of "Figure 4-5 Identity and Account Reconciliation"

Note:

When the value of the XL.UserProfileAuditDataCollection property is set to an audit data collection level, then the account reconciliation performs the matching in the database layer at a batch-level and performs the event action by using the provisioning APIs. This in turn triggers the audit event handlers for account reconciliation. By default, the value of this property is set to Resource Form. See "Administering System Properties" for information about system properties in Oracle Identity Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.1.1.3 Reconciliation Process Flow

The reconciliation process flow is shown in Figure 4-6:

Figure 4-6 Reconciliation Process Flow

Description of "Figure 4-6 Reconciliation Process Flow"

Reconciliation process involves the following steps:

1. Changes in the target system: The various activities that can happen in the target system are creation, modification, or deletion of user, account, role, role membership, or role hierarchy.

Note:

If you create an entity on an external system and then modify it a short time later, reconciliation processes the create entity step, but the modify entity step fails with the Creation Failed event status. This is because reconciliation cannot process a create and a modify action for the same entity in the same batch process.

However, the entity modification action can be resubmitted for reconciliation at a later time by one of the following built-in mechanisms:

- The "Automated Retry of Failed Async Task" scheduled task will run to re-process the failed events without any manual intervention. See "Automated Retry Error Handling Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for details.

- The failed event will be re-processed if the "Manual Retry Error Handling Mechanism" is triggered. See "Manual Retry Error Handling Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for details.

Reconciliation failure messages that are caused by processing conflicts within the same batch process should be regarded as transitory failures only.

2. Providing reconciliation data: When the creation, modification, or deletion event occurs, data about that event is sent to the reconciliation service by using reconciliation APIs.

Note:

Reconciliation service refers to the collection of reconciliation engine, reconciliation APIs, and the associated metadata and schema.

3. Creation of reconciliation event record: When the data for a reconciliation event is provided to reconciliation service, a record of that event is stored in Oracle Identity Manager repository.

4. Processing of the reconciliation event data: The data received is then evaluated to determine the actual operation to be performed in Oracle Identity Manager based on the changes in the target system. The evaluation involves application of a specific set of rules that help in:

1. Identifying whether the data is for an account or for an identity that Oracle Identity Manager already has a record of

2. Identifying the owner of the account or identity that the data represents

3. Defining the context-sensitive action to be taken

4. Setting the status of the event at the end of evaluation and the action that the reconciliation engine must take

5. Taking action on the event: Based on the evaluation result of processing the reconciliation event data, the intended action is taken. The various actions can be:

Note:

The actions on the event can be manually performed through the UI, or they can be automatic actions.

- Creating a new account and associating with proper owner identity

- Updating the matched account

- Deleting the matched account

- Creating a new user in Oracle Identity Manager

- Modifying an existing user in Oracle Identity Manager

- Deleting an existing user

- Enabling and disabling account status by updating the status attribute

- Enabling or disabling user

- Creating, updating, or deleting role

- Creating or deleting role membership

- Creating or deleting role hierarchy

See Also:

"Reconciliation Engine" for information about role membership and role hierarchy

6. Follow up actions triggered by the reconciliation event: After the action is taken, follow up tasks can be started based on the reconciliation event. An example of follow up tasks or post-processing task is creating a request to provision a resource, such as a laptop computer, after a user creation event.

4.2.1.2 Mode of Reconciliation

The mode of reconciliation is either pull or push that depends on the connector used. Most connectors, such as Active Directory, use the pull model. For the pull model, a pull reconciliation task is scheduled in the IAM Scheduler. The task runs at recurring intervals.

See Also:

"Managing Scheduled Tasks" for information about the IAM Scheduler in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

Typically, the pull-based reconciliation connectors submit the reconciliation events within a scheduled task. Every time the scheduled task runs, a new reconciliation run is triggered and the reconciliation events are created in batches. When the batch size is met, the batch is submitted for processing. At the end of the scheduled task, an end of job listener is triggered, which submits all the batches whose size is not met.

Other reconciliation connectors, such as the PeopleSoft connector, use a push model. The connector comprises of an HTTP listener that detects any asynchronous messages issued by PeopleSoft. On receiving a message, the listener submits reconciliation events by calling the reconciliation API. The events are processed by the reconciliation engine in batches when the batch size is met. For batches where batch size is not met, a scheduled task runs periodically and submits the batches for reconciliation processing.

Pull or push model is used based on the nature of the target system and how the changes can be detected in the target system. But irrespective of the push or pull model being used, reconciliation is performed by using a scheduled task that runs in the IAM Scheduler.

Note:

You can also create the reconciliation events directly by using the reconciliation APIs.

Changelog reconciliation is the default reconciliation mode. In this mode, only changed attributes are reconciled. Unspecified fields are ignored. You typically use the Changelog reconciliation mode when a connector is aware of the list of changed attributes. Along with the changed attributes, Oracle Identity Manager needs a list of required fields for matching. The Changelog reconciliation mode was supported in previous Oracle Identity Manager releases, so all connectors work in this mode.

Regular reconciliation is a new reconciliation mode, introduced in this release, where the reconciliation engine completely replaces the existing snapshot of the entity. You typically use this reconciliation mode when the connector cannot determine which attributes have changed, and therefore, sends an entire snapshot of the entity. For new connectors, you can specify this mode when performing a full reconciliation. Using regular reconciliation mode results in better performance because the events are processed faster.

Note:

The mode of reconciliation depends on the connector implementation. For information about connector implementation, see "Connector for Reconciliation".

Table 4-2 lists the differences between regular and changelog reconciliation modes:

Table 4-2 Regular and Changelog Reconciliation Modes

Regular

Changelog

Must pass a full set of mapped attributes

Must pass a subset of mapped attributes that are required by the specific profile and used by matching a rule

Performs better in batch processing mode (no difference in performance while in single event processing mode)

Creates and updates all fields

Creates and updates only specified fields, and all other fields remain unchanged

See Also:

"Changing the Profile Mode" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about changing the reconciliation mode

4.2.1.3 Approach Used for Reconciliation

When you run reconciliation for the first time on a target system, all users and accounts on the target system are reconciled into Oracle Identity Manager by default. This is called full reconciliation. To perform full reconciliation, the connector sends the reconciliation events for each entity in the target system. The reconciliation engine processes the events as create or update events depending on whether or not the entity already exists in Oracle Identity Manager. The connector also identifies all the deleted entries and sends the deletion events to Oracle Identity Manager.

At the end of full reconciliation, the connector typically sets the last execution time parameter to the time when the reconciliation run ends. For the next reconciliation run, only the entity records that have been added, modified, or deleted after the first reconciliation run ended are fetched for reconciliation. This is called incremental reconciliation.

You can manually switch from incremental reconciliation to full reconciliation by setting the value of the timestamp IT resource parameter to 0.

4.2.2 Reconciliation Architecture

Reconciliation is the process of pulling entity data from the target system into Oracle Identity Manager to keep the entity data in a consistent state between the two systems. The various components of Oracle Identity Manager involved in reconciliation and the interaction between these components are shown in the Figure 4-7:

Figure 4-7 Reconciliation Architecture

Description of "Figure 4-7 Reconciliation Architecture"

The reconciliation architecture is described in the following steps:

1. Each connector has scheduled tasks associated with it. The scheduler triggers the connector scheduled task, which invokes reconciliation APIs to generate events. The event can be of type Regular, Changelog, or Delete. For more information about the scheduler, see "Managing Scheduled Tasks" for information about the Scheduler in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager. For more information about scheduled tasks, see "Connector for Reconciliation".

2. The reconciliation events are stored in the reconciliation event repository, which is Oracle Identity Manager database.

3. When batch size is met, an asynchronous message is submitted which processes the batch of events in bulk. At the end of the schedule task another asynchronous message is submitted for processing the events of the last batch.

Note:

- In Figure 4-7, the reconciliation engine encapsulates the Action JAVA Layer as well as parts of the Reconciliation Event Repository, and orchestrates all the arrows in that diagram.

- In this release, trusted source reconciliation is supported for users only. It is not supported for roles, role membership, and role hierarchy reconciliation.

- In this release, Oracle Identity Manager supports trusted source reconciliation and account reconciliation for organizations.

4. The processing involves data validation, matching of the entities and action (create, update, delete and so on). This is followed by post processing via kernel orchestrations. For information about the action module, see "Action Module". For information about the reconciliation profile, see "New Metadata Model-Profile" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

5. By default the reconciliation event processing happens in bulk, and therefore all the steps till post processing are performed by PL/SQL stored procedures. Event can be processed one at a time in the following scenarios (in this case all the steps till matching are done in PL/SQL and the action is performed in java layer):

- When events are processed from the Reconciliation Management console

- When failed events are retried by the retry scheduled task that runs periodically

For reconciliation single event processing, actions and post processing take place through the kernel.

6. Reconciliation events are made available to the Reconciliation Management console by another API call in the reconciliation management service.

The functionality of various components of the reconciliation service are explained in the following sections:

- Reconciliation Profile

- Reconciliation Metadata

- Reconciliation Target

- Reconciliation Run

- Reconciliation APIs

- Reconciliation Schema

- Reconciliation Engine

- Reconciliation Best Practices

- Connector for Reconciliation

- Archival

- Backward Compatibility

- Reconciliation Manager

4.2.2.1 Reconciliation Profile

A reconciliation profile is the configuration defined to govern how reconciliation is run for a particular resource. A particular resource can have multiple reconciliation profiles, each of which defines matching rules, action rules, and field mappings, which can differ in each profile corresponding to the resource. For example, while one reconciliation run can perform reconciliation of new and modified accounts, another reconciliation run can reconcile deletion of accounts because you might want to run the deletions only once a day. In this example, you define two reconciliation runs and two profiles. Each profile is associated with respective reconciliation run and each profile having its own rules of reconciliation.

The profile is an XML-based configuration file stored in Oracle Identity Manager MetaData Store (MDS).

There is always a default profile associated with reconciliation configurations for any resource object. The default profile can be explicitly generated from Oracle Identity Manager Design Console in the developer's environment or implicitly generated during import from the Deployment Manager. For details on how to create and update profiles, see "Managing Reconciliation Events" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.2 Reconciliation Metadata

The reconciliation metadata consists of various configurations used in creating and processing the reconciliation events. The reconciliation metadata is stored in a logical container called a profile. For information about reconciliation profile, see "Reconciliation Profile".

Examples of the reconciliation metadata are:

- Mapping rules: Used to map the data received from the target system to the data managed about that target system in Oracle Identity Manager.

- Matching rules: Used during the processing of each reconciliation event to correlate the event data to a particular account, user, or role in Oracle Identity Manager.

- Action Rules: Used to specify the actions taken by Oracle Identity Manager based on the result of the processing of a reconciliation event.

- List of target attributes: Used to define the data attributes received from the target system via reconciliation. It is used in the mapping rules, and is configured by using Oracle Identity Manager Design Console.

The various configurations used in creating and processing the reconciliation events are managed by using Oracle Identity Manager Design Console, and for backward compatibility, is stored in the same Oracle Identity Manager tables as in Oracle Identity Manager release 9.1.0. In addition, the configurations are also stored in the reconciliation profile.

Note:

For reconciliation in Oracle Identity Manager, a metadata model is being used. See "Managing Reconciliation Events" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.3 Reconciliation Target

Reconciliation target refers to an instance of an application that acts as a source of changes for Oracle Identity Manager. An example of reconciliation target is an HR system, which acts as a source of identities for Oracle Identity Manager. A reconciliation target can be a source of users or accounts.

4.2.2.4 Reconciliation Run

Reconciliation run refers to the combination of a reconciliation connector and associated configurations which when run by the scheduled task, performs the reconciliation based on the rules defined in the associated configurations. The scheduler runs reconciliation periodically at fixed intervals. Reconciliation runs are scheduled within Oracle Identity Manager scheduler to run at a specified frequency. All events created during a reconciliation run are grouped together by a unique reconciliation run ID.

4.2.2.5 Reconciliation APIs

These are a set of published APIs to provide reconciliation data to Oracle Identity Manager in the form of reconciliation events. Connectors can use the APIs to push data to the reconciliation event repository. Scheduled tasks can be setup to run the APIs when reconciliation is to be run on a scheduled basis. The existing connectors do not need to be changed because the existing APIs are supported.

4.2.2.6 Reconciliation Schema

The data that comes from the target system for reconciliation is stored in the reconciliation schema. The data contains the changes to be reconciled with Oracle Identity Manager.

Reconciliation schema refers to the set of schema tables to store the reconciliation data. The reconciliation schema is redesigned for performance reasons and future extensibility. See "Improved Database Schema" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about the reconciliation schema.

4.2.2.7 Reconciliation Engine

The reconciliation engine uses all configurable components and includes the data processor and rule evaluator that use these components to convert input data into a list of action items. It also includes the components that determine whether or not the actions can be automated based on the rule context. When an action is performed, either automatically or manually, the engine performs the appropriate updates and provisioning actions.

The main task of the reconciliation engine is to perform the comparison, determine the action to be taken, and apply the action in Oracle Identity Manager. It contains two modules, which are described in the following sections:

- Matching Module

- Action Module

4.2.2.7.1 Matching Module

The matching rule specified in the profile is used to identify whether the record being searched, exists in Oracle Identity Manager or not. Matching rules are rules to identify whether the data is for an identity that Oracle Identity Manager already has a record of, or to identify the owner of the account in Oracle Identity Manager. When no record is found for the data of an account, an owner match is then performed to identify the owner of the account by using the matching rules.

For user and role entities owner matching is performed. For account entities, when no record is found, an owner match is then performed to identify the owner of the account.

For role membership events, matching is performed to identify role and user. For role hierarchy events, matching is performed to identity the parent and child role.

Note:

While performing role hierarchy and role membership reconciliation, the matching criteria must contain both Namespace and Role Name in the matching criteria. The following is an example of a matching rule:

((UGP.ugp_rolename=x) and (UGP.ugp_namespace=y))

Here, x is the name of the horizontal table name column that is mapped to Role Name, and y is the name of the horizontal column that is mapped to Namespace.

At the end of the evaluation, the match table contains all the possible matches found within Oracle Identity Manager that meet the criteria for the event, and the state of the event is updated to one of the statuses listed in Table 4-3:

Table 4-3 Reconciliation Status Events

Status Events

Description

Data Received

Event data has been created in the database and is ready for further processing.

Event Received

A reconciliation event has been created and is ready for further processing. The finishReconciliationEvent API has not yet been called.

Data Validation Failed

The reconciliation event record is invalid. For example, a role event with an invalid role category will fail to validate. (This situation could indicate a race condition.) The RE_NOTE field should contain the details of the failure, which is also displayed in the user interface.

Data Validation Succeeded

The event data was successfully validated and the event can now safely be processed by the Engine.

Multiple Accounts Match Found

Given the current matching rules, multiple matching account records were found for the data.

No Account Match Found

Given the current matching rules, no matching account records were found for the data.

Single Account Match Found

Given the current matching rules, one matching account record was found for the data.

Multiple Org Matches Found

Given the current matching rules, multiple matching organization records were found for the data.

No Org Match Found

Given the current matching rules, no matching organization records were found for the data.

Single Org Match Found

Given the current matching rules, one matching organization record was found for the data.

Multiple Role Grants Match Found

Multiple matching records for user membership within a role were found.

No Role Grant Match Found

No matching records for user membership within a role were found.

Single Role Grant Match Found

One matching record for user membership within a role was found.

Multiple Roles Match Found

Given the current matching rules, multiple matching role records were found for the data.

No Role Match Found

Given the current matching rules, no matching role records were found for the data.

Single Role Match Found

Given the current matching rules, one matching role record was found for the data.

No Role Members Found

The Reconciliation Engine did not find role members matching the data, given the current matching rules.

No Role Parent Found

The Reconciliation Engine did not find a role matching the data, given the current matching rules.

Multiple Role Relationships Match Found

Given the current matching rules, reconciliation has found multiple role-to-role relationships that match data in the event.

No Role Relationship Match Found

Given the current matching rules, reconciliation did not find any role-to-role relationships that match data in the event.

Single Role Relationship Match Found

Given the current matching rules, reconciliation has found one role-to-role relationship that matches data in the event.

Multiple Users Match Found

Given the current matching rules, multiple matching user records were found for the data.

No User Match Found

Given the current matching rules, no matching user records were found for the data.

Single User Match Found

Given the current matching rules, one matching user record was found for the data.

Invalid Event Data Passed

The event contains invalid data. This status pertains to the e-mail attribute.

Being Re-evaluated

The reconciliation event is being reevaluated from the reconciliation management console.

Being Re-tried

The reconciliation event is being retried automatically. This status event has been deprecated.

Creation Failed

The user/account/role entity was not created successfully.

Creation Succeeded

The user/account/role entity was created successfully.

Delete Failed

The user/account/role entity was not successfully deleted.

Delete Succeeded

The user/account/role entity was deleted successfully.

Event Closed

The reconciliation event was closed from the reconciliation management console. The change is complete.

Update Failed

The user/account/role entity was not updated successfully.

Update Succeeded

The user/account/role entity was updated successfully.

4.2.2.7.2 Action Module

This module applies the action based on the event state, entity type, and the action rules, as listed in Table 4-4:

Table 4-4 Action Rules

Event State

Entity Type

Action

Description

No User Match Found

User

No Action

Does not perform any action

Create User

Creates a user in Oracle Identity Manager

No Account Match Found

Account

No Action

Does not perform any action

User Matched

User or Account

No Action

Does not perform any action

User

Establish Link

Modifies or deletes the matched user based on the change type

Account

Establish Link

Owner identified - creates an account

Users Matched

User or Account

No Action

Does not perform any action

Account Matched

Account

No Action

Does not perform an action

Establish Link

Modifies or revokes the account based on the change type

Accounts Matched

No Action

Does not perform any action

No Role Match Found

Role

No Action

Does not perform any action

Single Role Match Found

Role

No Action

Does not perform an action

Establish Link

Modify or delete a role

Role Membership

Create role membership

Grant a role member to Oracle Identity Manager

Delete role membership

Delete a role member from Oracle Identity Manager

No action

Does not perform an action

Role Hierarchy

Create role hierarchy

Creates a role hierarchy in Oracle Identity Manager

Delete role hierarchy

Delete a role hierarchy in Oracle Identity Manager

No action

Does not perform an action

Multiple Roles Matched

Role, Role membership and Role Hierarchy

No action

Does not perform an action

No Role Grant Match Found

Role Membership

No Action

Does not perform an action

Create Role Member

Creates a role member in Oracle Identity Manager

Single Role Grant Match Found

Role Membership

No action

Does not perform an action

Establish Link

Delete role member

Multiple Role Grant Match Found

Role Membership

No action

Does not perform an action

Note: This state does not occur because the role grant match is done by looking for the primary key, which is a combination of the usr key and the group key.

No Role Parent Match Found

Role Hierarchy

No Action

Does not perform an action

Create role parent

Create a role parent in Oracle Identity Manager

Single Role Parent Match Found

Role Hierarchy

No Action

Does not perform an action

Establish Link

Delete role parent

Multiple Role Parent Match Found

Role Hierarchy

No Action

Does not perform an action

Data Validation Failed

Role, Role Hierarchy, Role Member

Race condition

Does not perform an action. The event needs to be re-evaluated.

Parent role not found

Role Hierarchy

Race condition

Does not perform an action. The event needs to be re-evaluated.

Role member not found

Role membership

Race condition

Does not perform an action. The event needs to be re-evaluated.

4.2.2.8 Reconciliation Best Practices

This section describes how to improve performance by identifying indexes that are required for connector tables and reconciliation tables. It contains the following topics:

- Additional Indexes Requirement for Matching Module

- Collecting Database Schema Statistics for Reconciliation Performance

4.2.2.8.1 Additional Indexes Requirement for Matching Module

When Oracle Identity Manager is installed, the necessary indexes are created in the Oracle Identity Manager database schema. However, there can be additional indexes required because of dynamic nature of some of the features in Oracle Identity Manager. This is especially true for reconciliation.

Reconciliation uses matching algorithm to find if the user/account/role/organization for which the change is requested is already existing in Oracle Identity Manager or not. The matching algorithm compares the data in set of columns in Oracle Identity Manager with the data in target horizontal table columns. The columns that contains the matching rules are defined in the reconciliation profile. To improve the performance of the matching operation quickly, there must be correct indexes created on the matching rule columns.

To illustrate the recommended method of identifying the appropriate indexes, a sample Active Directory (AD) user profile present in the Meta Data Store (MDS) repository is taken as an example. In this example, trusted source as well as target resource reconciliation are covered.

Selecting Indexes for Trusted Source Reconciliation

To select indexes based on the matching rule criteria in trusted source and target resource reconciliation:

1. Open the AD user profile file in a text editor.

Note:

The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. Search for ownerMatchingRuleWhereClause for all entities, as shown in the following figure with code sample:

Here, the ownerMatchingRuleWhereClause is the following:

ownerMatchingRuleWhereClause = (((UPPER(USR.USR_LOGIN)=UPPER(RA_ADUSER7.RECON_USERID5A729570)) OR (UPPER(USR.USR_UDF_OBGUID)=UPPER(RA_ADUSER7.RECON_OBJECTGUID))))

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Note:

- If any key field is defined in Oracle Identity Manager as case-insensitive, then a function-based index on that key field must be created. For example, if the connector code internally performs a search for the first name, assuming that FIRST_NAME is a key, then appropriate indexing must be done.

- If multiple or composite keys are used for looking up a user, then choose between individual or composite indexes.

Selecting Indexes for Target Resource Reconciliation

To select indexes based on the matching rule criteria in target resource reconciliation:

1. Open the AD user profile file in a text editor.

Note:

The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. Search for account search tag <matchingruleWhereClause>, as shown in the following figure:

Here, the <matchingruleWhereClause> is the following:

<matchingruleWhereClause>((UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSER7.RECON_OBJECTGUID))</matchingruleWhereClause>

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Selecting Indexes for Target Resource Reconciliation With Multi-Valued Data

To select indexes based on the matching rule criteria in target resource reconciliation with multi-valued data:

1. Open the AD user profile file in a text editor.

Note:

The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. For entitlements, search for the <matchingruleWhereClause> tag under <childreconeventdata>.

Here, the <matchingruleWhereClause> tag is the following:

<matchingruleWhereClause>((UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_UD_ADUSRC.RECON_MEMBEROF))</matchingruleWhereClause>

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Note:

Pointers for required indexes can also be taken by monitoring the real-time running of reconciliation process from the database side by using a performance-monitoring tool, such as Oracle Enterprise Manager Console, or through the Automatic Workload Repository (AWR) Reports available in Oracle Database 11g.

4.2.2.8.2 Collecting Database Schema Statistics for Reconciliation Performance

Database statistics is essential for the Oracle optimizer to select an optimal plan in running the SQL queries. Oracle recommends that the statistics are collected regularly for Oracle Identity Manager schema. Because Oracle Identity Manager 11g Release 1 (11.1.1) uses lot of database SQL features for reconciliation process, make sure that the schema statistics are updated before running the reconciliation.

Note:

- Other options with DBMS_STATS.GATHER_SCHEMA_STATS API can be used as required, such as DEGREE,ESTIMATE_PERCENT based on the environment, data profile, Oracle DB Edition and underlying hardware capabilities.

- See "Database Performance Monitoring" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about collecting database schema statistics.

Because Oracle Identity Manager reconciliation process is a data-intensive process and quickly brings in large volume of data, database statistics must also be able to represent the underlying data correctly. To achieve this, refer to the following guidelines:

- Make sure that statistics is collected for reconciliation on a fresh setup or with a low volume with no or negligible existing data in the Oracle Identity Manager schema. Maximum row count in relevant Oracle Identity Manager tables must be between 100 and 1000 rows. Examples of tables are USR table for trusted source reconciliation and parent account table for target resource reconciliation.

- For the statistics to be a proper representative of data distribution after reconciliation has started and is expected to bring in a large volume of data, such as more than 20000 users or accounts, collect Oracle Identity Manager schema statistics in the following manner:

1. Plan to gather statistics after the initial collection only after reconciliation has started successfully and has been running for a while. To verify this, check the counts of a few key tables from the Oracle Identity Manager schema, such as USR table for trusted source reconciliation and parent account (UD_*) tables for target resource reconciliation.

2. After reconciliation has brought in almost 20000 to 25000 rows in the USR table or in the parent account tables, statistics can be collected.

Note:

- Statistics can be gathered concurrently with reconciliation running.

- The row counts specified in the guidelines are examples and you can determine any other row count for collecting statistics.

- After the statistics is collected, the performance might not improve immediately. However, as older SQL Plans are cleared from the shared pool of the Oracle Database, new and more efficient plans are created and performance improves.

4.2.2.9 Connector for Reconciliation

The connector refers to the software that extracts the changes from the target system and creates events in the reconciliation schema by calling the reconciliation APIs. If the connector that you want to use is shipped with a predefined reconciliation module, then a scheduled task definition is available. You use this component to control the frequency at which the target system is polled for changes to track data and other connector-specific parameters.

The connector for reconciliation is deployed by using the Deployment Manager. When the connector is deployed, the corresponding reconciliation profile for that connector is created in the metadata store (MDS), and horizontal tables that store the event data are also created.

Note:

Do not manually update reconciliation profile or update any reconciliation configurations from the Deployment Manager or Oracle Identity Manager Design Console when a reconciliation run is still in progress. This is because, if a reconciliation field is deleted or updated when a reconciliation run is in progress, then the event data might not be valid any more.

For information about configuring connectors, see Oracle Identity Manager Connector documentation.

See Also:

- "Reconciliation Metadata" for information about MDS

- "Horizontal Tables" for information about the horizontal tables in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.10 Archival

The Reconciliation Archival utility allows you to move processed events from the active reconciliation tables to archive tables. The events to move can be selected based on a time range. Only linked and closed events, which means successfully processed or closed by an administrator, can be archived.

See Also:

"Using the Reconciliation Archival Utility" for information about how to use the Reconciliation Archival utility in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.11 Backward Compatibility

You do not need to change the existing reconciliation configurations or scheduled tasks to leverage the new reconciliation service.

The existing configurations for reconciliation setup in earlier Oracle Identity Manager releases continues to function after upgrading to 11g Release 1 (11.1.1). As part of the upgrade, corresponding reconciliation event tables are created for each of the existing object types being reconciled.

4.2.2.12 Reconciliation Manager

The Reconciliation Manager is a Web-based UI, which is a part of Oracle Identity Manager Administrative and User Console. The Reconciliation Manager lets you view and manage reconciliation events generated by Oracle Identity Manager reconciliation engine. These events are generated through scheduled reconciliation runs. The Reconciliation Manager provides search capabilities on reconciliation runs as well as events. Users can use the Reconciliation Manager to perform reconciliation manually on generated events.

See Also:

"Managing Reconciliation Events" for more information about the Reconciliation Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.3 Integration Between LDAP Identity Store and Oracle Identity Manager

Oracle Identity Manager users and roles are stored in Oracle Identity Manager database. However, when a user, role, or role membership change takes place in Oracle Identity Manager, this information is propagated to LDAP identity store. If user, role, or role membership change takes place in LDAP directly, then these changes are synchronized into Oracle Identity Manager. The synchronization involves:

- User creation, modification, deletion, change in enable or disable states, and password change are made in LDAP in addition to the internal Oracle Identity Manager tables.

- Role creation, modification, and deletion actions update the LDAP groups, including membership changes.

- Initial load of users, roles, and role memberships are synchronized.

- Direct changes to user profile in LDAP are reconciled to Oracle Identity Manager.

- Direct changes to roles and role memberships in LDAP are reconciled to Oracle Identity Manager.

When changes are made in the user and role data, the actual operation is performed with the help of the kernel handlers. These handlers go through an orchestration lifecycle of various stages, such as validation, preprocessing, action, and postprocessing. For more information about the various stages of kernel orchestration, see Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

Oracle Identity Manager kernel orchestration connects to the Entity Manager, which in turn connects to the LDAP provider. The LDAP provider connects to Oracle Virtual Directory (OVD). The OVD is an interface to various directory systems, such as Oracle Internet Directory, iPlanet, and Active Directory. The LDAP provider reaches the LDAP data by using OVD. Figure 4-8 shows the communication between Oracle Identity Manager and LDAP:

Figure 4-8 Oracle Identity Manager and LDAP

Description of "Figure 4-8 Oracle Identity Manager and LDAP"

The integration configuration and synchronization of data between Oracle Identity Manager and the LDAP identity store are described in the following sections:

- Configuring the Integration with LDAP

- Provisioning Data From Oracle Identity Manager to LDAP Identity Store

- Reconciliation From LDAP Identity Store to Oracle Identity Manager

4.3.1 Configuring the Integration with LDAP

Configuring the integration between Oracle Identity Manager and LDAP is performed while installing Oracle Identity Manager. You can choose to install Oracle Identity Manager with or without LDAP. If you install Oracle Identity Manager with LDAP, then you must install OVD and Oracle Internet Directory, create a container to store reserved users, create a new user in Oracle Identity Manager to perform Oracle Identity Manager operations, and configure OVD and Oracle Internet Directory for Oracle Identity Manager. For information about how to perform these configuration steps, see "Setting Up LDAP Synchronization" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

After installing Oracle Identity Manager with LDAP enabled, you must open the following scheduled jobs and update their Last Change Number parameter with the last changelog number value of Oracle Internet Directory:

- LDAP User Create and Update Reconciliation

- LDAP User Delete Reconciliation

- LDAP Role Membership Reconciliation

- LDAP Role Hierarchy Reconciliation

- LDAP Role Create and Update Reconciliation

- LDAP Role Delete Reconciliation

In addition, you must enable these scheduled jobs after updating the Last Change Number parameter. To do so, see "Disabling and Enabling Jobs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

See Also:

"Managing Scheduled Tasks" for detailed information about scheduled jobs in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.3.2 Provisioning Data From Oracle Identity Manager to LDAP Identity Store

Oracle Identity Manager database stores the user and role information. When the user and role information is updated in Oracle Identity Manager, then the external repositories, such as the LDAP directory, must also be updated.

The LDAP changes are performed before Oracle Identity Manager changes. If Oracle Identity Manager changes fail, then the LDAP changes must be reverted to the original state. This is achieved by correcting an enable operation with a disable operation, a create operation with a delete operation, and a modification operation with another modification operation with the original values.

For instance, when a user is created, the validation processes are performed in the validation stage, such as password or any other policy validation. In the preprocessing stage, the user is created in LDAP first. Then, in the action stage, the user is to be created in Oracle Identity Manager. If there is an error in creating the user in Oracle Identity Manager, then the user must be deleted from LDAP because the corresponding user could not be created in Oracle Identity Manager. The operation to revert the change made is provided by the kernel handlers through the compensation method, which is predefined in Oracle Identity Manager.

Note:

Each handler has predefined execute and compensate methods. The execute method runs any operation, such as creating a user. The compensate method is called when an error occurs to revert the operation performed by the execute method.

To synchronize date from Oracle Identity Manager to LDAP, the location of the LDAP must be known to Oracle Identity Manager. The information about the LDAP location is stored in Oracle Identity Manager as the DirectoryServer IT resource. This is a default IT resource provided by Oracle Identity Manager. The various parameters of this IT resource, which you can specify while installing Oracle Identity Manager, allows the connection between Oracle Identity Manager and LDAP.

In order to identify the same entry in Oracle Identity Manager and LDAP, the Distinguished Name (DN) and GUID attributes are used. Each entry has the DN attribute in LDAP, which indicates the unique location of an entry in LDAP. The GUID attribute is an unique ID to identify the entry. The DN and GUID for users and roles are stored in columns in the users and role tables in Oracle Identity Manager database. For information about how to synchronize user-defined fields between Oracle Identity Manager and LDAP, refer "Synchronizing User-Defined Fields Between Oracle Identity Manager and LDAP" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

This section describes the following topics:

- Managing Users

- Managing Roles

4.3.2.1 Managing Users

The following user operations can be performed to synchronize data from Oracle Identity Manager to LDAP:

- Create user

- Update user

- Delete user

- Enable user

- Disable user

- Lock user

- Unlock user

- Add role member

- Delete role member

- Change password

4.3.2.2 Managing Roles

The following role operations can be performed to synchronize data from Oracle Identity Manager to LDAP:

- Create role

- Update role

- Delete role

- Add role to a member

- Add and Update role

- Remove role from a member

- Add role hierarchy

- Remove role hierarchy

4.3.3 Reconciliation From LDAP Identity Store to Oracle Identity Manager

When changes in the identities are made directly in the LDAP identity store, the changes must be replicated to Oracle Identity Manager through authoritative source reconciliation. The identities include users and roles.

Reconciling users from LDAP to Oracle Identity Manager works with the general configuration of reconciliation, which includes the scheduled tasks for reconciliation.

See Also:

- "Reconciliation Configuration" for detailed information about reconciliation

- "Managing Scheduled Tasks" for information about scheduler and scheduled tasks in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Note:

Instead of using LDAP synchronization reconciliation jobs to reconcile users from LDAP to Oracle Identity Manager, if the Bulk Load utility is used, then subsequent operation on these users might fail if LDAP synchronization is enabled. To avoid this, all the users that are loaded in Oracle Identity Manager must be updated with correct GUID and DN values, and all these users in LDAP must be updated with an object class called orclIDXPerson.

For detailed information about the Bulk Load utility, see "Bulk Load Utility" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

The role reconciliation works only with the LDAP groups. Role reconciliation supports creation, updation, and deletion of roles. Role membership reconciliation supports creation and deletion of role memberships being driven from changes in an external LDAP directory.

See Also:

Chapter 12, "Managing Roles" for information about roles, role memberships, and role hierarchies

Without roles and users being present in Oracle Identity Manager, role membership reconciliation will fail. Therefore, configure the LDAP synchronization scheduled jobs to run in the following order:

1. Fusion Applications Role Category Seeding

Note:

Fusion Applications Role Category Seeding is a predefined scheduled task that is generated only when LDAP synchronization is enabled, along with other LDAP synchronization scheduled jobs. This job gets all distinct business categories in LDAP and creates them as OIM role categories.

For a list of the predefined scheduled jobs, see "Predefined Scheduled Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

2. LDAP Role Create and Update Reconciliation

3. LDAP Role Hierarchy Reconciliation

4. LDAP User Create and Update Reconciliation

5. LDAP Role Membership Reconciliation

For each of these jobs, except Fusion Applications Role Category Seeding, there is a parallel job to do the full reconciliation. All these jobs, except Fusion Applications Role Category Seeding, perform the reconciliation based on change logs, whereas full reconciliation jobs use the search base to do the reconciliation.

4.3.3.1 Consolidated LDAP Sync Full Reconciliation

The LDAP Consolidated Full Reconciliation scheduled job runs the following jobs in order:

1. LDAP User Create and Update Full Reconciliation

2. LDAP Role Create and Update Full Reconciliation

3. LDAP Role Membership Full Reconciliation

4. LDAP Role Hierarchy Full Reconciliation

See Also:

"LDAP Scheduled Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the LDAP Consolidated Full Reconciliation scheduled job

When you run the LDAP Consolidated Full Reconciliation scheduled job, the job status of the previous job and all event status for that particular job are checked because the next job must be run in a particular order. If any job fails to run, then the automatic run of the jobs stop, and error messages are logged in the diagnostic log.

Note:

The LDAP User Delete Full Reconciliation and LDAP Role Delete Full Reconciliation jobs are not part of LDAP Consolidated Full Reconciliation. These scheduled jobs are disabled by default. They can be enabled by selecting the radio buttons and can be run individually.

You can also run the individual jobs by selecting the radio buttons on the LDAP Sync Consolidated Full Reconciliation job details page. The job details contain all the common parameters for the four full reconciliation reconciliation jobs. In addition, you can specify the values for the following parameters of the LDAP Sync Consolidated Full Reconciliation scheduled job:

- Reconciliation Search Base: Search base for the full reconciliation of users or roles. This defines the location in the LDAP directory from which the LDAP search begins.

- Reconciliation Role Search Filter: Search filter for full reconciliation of roles. This filter allows certain role/group entries in the subtree of the LDAP directory and excludes others.

- Reconciliation User Search Filter: Search filter for full reconciliation of users. This filter allows certain user entries in the subtree of the LDAP directory and excludes others.

Based on the values entered for the Reconciliation Search Base and/or Reconciliation User Search Filter and Reconciliation Role Search Filter parameters, the user and role accounts are pulled into Oracle Identity Manager from LDAP when the LDAP Sync Consolidated Full Reconciliation job is run. As a result of this full reconciliation, the delete happens in the Oracle Identity Manager database for the deleted entries in LDAP from that particular node.

The Reconciliation Search Base and Reconciliation Search Filter parameters support the following:

- Reconciling the user or role account from LDAP to Oracle Identity Manager database:
This provides the option to perform fine-grained reconciliation of a particular user or role. The value of the Reconciliation Search Base parameter is:

"cn=cokeuser1,cn=users,cn=subrealm1,dc=us,dc=oracle,dc=com"

- All users and roles or groups under the node is reconciled:
The value of Reconciliation Search Base is:

"cn=tenant1,dc=us,dc=oracle,dc=com"

Here, the user full reconciliation and role full reconciliation are triggered. Therefore, all the users and roles or groups under the tenant1 node are reconciled.

- All users under the node is reconciled:
The value of Reconciliation Search Base is:

"cn=users,cn=tenant1,dc=us,dc=oracle,dc=com"

Here, all the users under the tenant1 node are reconciled.

- All roles or groups under the node is reconciled:
The value of the Reconciliation Search Base parameter is:

"cn=groups,cn=tenant1,dc=us,dc=oracle,dc=com"

Here, all roles or groups under the tenant1 node are reconciled.

The Reconciliation Search Base and Reconciliation Search Filter parameters are not bound together for LDAPSync Full reconciliation. Reconciliation Search Filter can be empty. Search Base can be used for provisioning or pushing entries from Oracle Identity Manager to LDAP, while Reconciliation Search Base can be used to perform full reconciliation from LDAP to Oracle Identity Manager database. If a value is not provided for Reconciliation Search Base, then the value for Search Base from the 'Directory Resource' IT resource configuration is used for both provisioning and full reconciliation.Sample values for the Reconciliation Search Base parameter:

"cn=tenant1,dc=us,dc=oracle,dc=com"

Sample values for the Search Base parameter:

"dc=us,dc=oracle,dc=com"

Sample values for the Reconciliation User Search Filter and Reconciliation Role Search Filter parameters:

(objectclass=orclAPPIDPerson)
(title=foobar)

Messages Logged For the LDAP Sync Consolidated Full Reconciliation Scheduled Job

The following is a list of messages for the LDAP Sync Consolidated Full Reconciliation scheduled job that are logged in the Oracle Identity Manager diagnostic log files:

LDAP Sync Full Reconciliation Scheduler job {0} is currently Running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Stopped.
LDAP Sync Full Reconciliation Scheduler job {0} is currently being Interrupted while running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Failed.
Error occurred while running the LDAP Sync User Full Reconciliation scheduler job. Please refer to the OIM Server logs for more details.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has been Shutdown.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running.
SQLException has occurred.
All LDAPSync Full Reconciliation jobs ran successfully and Stopped.

5 Integration Solutions

Oracle Identity Manager has a three-tier integration solutions strategy to provide connectors to various heterogeneous identity-aware IT systems. This three-tier strategy is designed to minimize custom development, maximize the reuse of code, and reduce deployment time. The three tiers are:

- Out-of-the box integration using predefined connectors and predefined generic technology connector providers

- Connectors based on custom generic technology connector providers

- Custom connectors using the Adapter Factory

Figure 5-1 illustrates the three-tier integration solutions strategy of Oracle Identity Manager.

Figure 5-1 Three-Tier Integration Solutions Strategy of Oracle Identity Manager

Description of "Figure 5-1 Three-Tier Integration Solutions Strategy of Oracle Identity Manager"

This chapter discusses the following topics:

- Predefined Connectors

- Generic Technology Connectors

- Custom Connectors

- Components Common to All Connectors

- Connector Installation

5.1 Predefined Connectors

When a predefined connector is available for the target resource, this is the preferred integration method. 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 target recommended integration technologies and are preconfigured with application specific attributes.

See Also:

""Predefined Scheduled Tasks" for information about predefined connector installation in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

5.2 Generic Technology Connectors

Similar to a predefined connector, a generic technology connector acts as the bridge for reconciliation and provisioning operations between Oracle Identity Manager and a target system. In terms of functionality, a generic technology connector can be divided into a reconciliation module and provisioning module. When you create a generic technology connector, you can specify whether you want to include both modules or only the reconciliation or provisioning module.

The GTC framework provides basic components that are used to rapidly assemble a custom connector. The reconciliation and provisioning modules of a generic technology connector are composed of these reusable components that you select. Each component performs a specific function during provisioning or reconciliation. The components are:

- Reconciliation:

- Reconciliation Transport Provider: This provider is responsible for moving the reconciled data from the target system to Oracle Identity Manager.

- Reconciliation Format Provider: This provider parses the message received from the target system, which contains the reconciled data, into a data structure that can be interpreted by the reconciliation engine in Oracle identity Manager.

- Validation Provider: This provider validates any data received before passing it on to the reconciliation engine.

- Provisioning:

- Provisioning Format Provider: This provider converts Oracle identity Manager provisioning data into a format that is supported by the target system.

- Provisioning Transport Provider: This provider carries the provisioning message received from the Provisioning Format Provider to the target system.

Figure 5-2 shows the functional architecture of a generic technology connector.

Figure 5-2 Functional Architecture of a Generic Technology Connector

Description of "Figure 5-2 Functional Architecture of a Generic Technology Connector"

See Also:

"Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager" for detailed information about the functional architecture, configuration, and functionalities of the generic technology connector

Generic technology connectors have the following features:

- Features specific to the reconciliation module are:

- Generic technology connector in trusted source reconciliation: A generic technology connector can be used for trusted source reconciliation. During reconciliation in trusted mode, if the reconciliation engine detects new target system accounts, then it creates corresponding OIM Users. If the reconciliation engine detects changes to existing target system accounts, then the same changes are made in the corresponding OIM Users.

- Generic technology connector in account status reconciliation: User account status information is used to track whether or not the owner of a target system account is to be allowed to access and use the account. If the target system does not store account status information in the format in which it is stored in Oracle Identity Manager, then you can use the predefined Translation Transformation Provider to implement account status reconciliation.

- Generic technology connector in full or incremental reconciliation: While creating a generic technology connector, you can specify that you want to use the connector for full or incremental reconciliation. In incremental reconciliation, only target system records that have changed after the last reconciliation run are reconciled (stored) into Oracle Identity Manager. In full reconciliation, all the reconciliation records are extracted from the target system.

- Generic technology connector for batched reconciliation: To exercise more control over the reconciliation process, you can use the generic technology connector to specify a batch size for reconciliation. By doing this, you can break into batches the total number of records that the reconciliation engine fetches from the target system during each reconciliation run.

- Generic technology connector in reconciliation of multivalued attribute data (child data) deletion: You can specify whether or not you want to reconcile into Oracle Identity Manager the deletion of multivalued attribute data on the target system.

- Generic technology connector in failure threshold for stopping reconciliation: During reconciliation, Validation Providers can be used to run checks on target system data before it is stored in Oracle Identity Manager. You can set a failure threshold to automatically stop a reconciliation run if the percentage of records that fail the validation checks to the total number of records processed exceeds the specified threshold percentage.

- Other features of generic technology connectors are:

- Custom Providers: If the predefined providers shipped with Oracle Identity Manager do not address the transport, format change, validation, or transformation requirements of your operating environment, then you can create custom providers.

- Multilanguage Support: Generic technology connectors can handle both ASCII and non-ASCII user data.

- Custom Date Formats: While creating a generic technology connector, you can specify the format of date values in target system records that are extracted during reconciliation and the format in which date values must be sent to the target system during provisioning.

- Propagation of Changes in OIM User Attributes to Target Systems: While creating a generic technology connector, you can enable the automatic propagation of changes in OIM User attributes to the target system.

5.3 Custom Connectors

If the target resource has no technology interface or accessible user repository, then the customer can develop a custom connector. 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.

See Also:

"Adapters" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for details about how to define adapters by using the Adapter Factory

5.4 Components Common to All Connectors

Table 5-1 lists the definitions of connector components contained in the connector XML file. These components are common to all connectors.

Table 5-1 Connector Components

Components

Description

Resource Object

This is a virtual representation of the target application on which you want to provision accounts. It is the parent record with which the provisioning process and process form are associated.

Provisioning Process

This process definition is used to create, maintain, and delete accounts on the target system. It consists of definitions of the individual tasks that are used to perform automated functions on the target system. Each connector is packaged with a single provisioning process. You can manually create additional provisioning processes.

Note: For more information about provisioning process, see Table 5-2 and Table 5-3.

Process Form

This form is used to provide information about user accounts to be created, updated, or deleted on the target system. This form is also used to capture data that can be used by provisioning process tasks or to provide a mechanism for users to provide real-time data.

This form is used extensively when conducting reconciliation. The table structure associated with this form supports the archiving and auditing of user accounts on the target system.

Each process form consists of field definitions required by a standard connector. If you require additional fields, then you can create another version of the form and add the required fields.

Each connector is shipped with certain default process forms. You can manually create additional process forms.

IT Resource Type

This component is a template for all IT resource definitions associated with the connector. An IT resource type specifies the parameters that are common to all IT resource instances, such as host servers and computers, of that particular IT resource type.

The parameters specified in this definition are inherited by all IT resource definitions of that type. For example, the Solaris 8 IT resource type can have a parameter called IP Address. The value of that parameter for the Target_Solaris IT resource instance can be set to 192.168.50.25.

Adapters

This includes all adapters that are required to perform common functions on the target application. Each adapter is predefined with certain mappings and functionality. These adapters are capable of interacting with the tasks in the provisioning process and the fields of the process form.

Note: For more information about adapters, see Oracle Identity Manager Tools Reference.

Scheduled Task (where applicable)

If the connector that you want to use is shipped with a predefined reconciliation module, then you are provided with a scheduled task definition. You use this component to control the frequency at which the target system is polled for changes to tracked data.

5.4.1 Provisioning Process Tasks

Table 5-2 lists the predefined tasks (or their equivalents) that the Provisioning Process component contains.

Table 5-2 Provisioning Process Tasks

Provisioning Process Task

Purpose

Create User

Creates a new user account in the target application (provisions the user with an account)

Disable User

Temporarily disables a user account in the target application

Enable User

Re-enables a disabled user account in the target application

Delete User

Deletes a user account in the target application (revokes the user's account)

Update User

Modifies the privileges or profile of a user account in the target application

5.4.2 Reconciliation-Related Provisioning Process Tasks

In addition to the tasks listed in the previous section, the Provisioning Process component also contains the reconciliation-related tasks. Table 5-3 lists these tasks.

Note:

When Oracle Identity Manager receives a reconciliation event, all provisioning-related tasks within the provisioning process are suppressed and the relevant reconciliation-related task is inserted.

Table 5-3 Reconciliation-Related Provisioning Process Tasks

Provisioning Process Task (Reconciliation-Related)

Purpose

Reconciliation Insert Received

This task is inserted into the Provisioning Process instance associated with the user or organization when Oracle Identity Manager determines that the reconciliation event received from the target system represents the creation of a user or organization account.

In addition, the information in the reconciliation event record is stored in the process form according to the mappings set on the provisioning process.

Reconciliation Update Received

This task is inserted into the Provisioning Process instance associated with the user or organization when Oracle Identity Manager determines that the reconciliation event received from the target system represents the update of an existing user or organization account.

In addition, the information in the reconciliation event record is stored in the process form according to the mappings set on the provisioning process.

Reconciliation Delete Received

This task is inserted into the Provisioning Process instance associated with the user or organization when Oracle Identity Manager determines that the reconciliation event received from the target system represents the deletion of an existing user or organization account.

5.5 Connector Installation

Oracle Identity Manager provides features to install connectors. The following are general considerations that you must address before installing connectors:

- Some connectors require external libraries in the form of JAR files for normal functioning. You can purchase these JAR files from the respective vendors. After you obtain these JAR files, you must configure Oracle Identity Manager as required. For example, you can update the CLASSPATH environment variable.

- Some connectors require external software to be installed on the target system. For example, if you are using the Bourne (sh) shell on Solaris, then you must install and start WBEM Services on the target Solaris computer. Otherwise, you cannot use Oracle Identity Manager to provision users on Solaris.

- For optimal performance of the prepackaged connectors, you must configure the target systems separately. Where required, this step is explained in the connector deployment guides.

- While installing Oracle Identity Manager in a clustered environment, you copy the contents of the installation directory to each node of the cluster. Similarly, all the JAR files that you copy to Oracle Identity Manager server during the connector deployment process must be copied to the corresponding directories on each node of the cluster.

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:

- Overview

- Audit Engine

- User Profile Auditing

- Role Profile Auditing

- Enabling and Disabling Auditing

6.1 Overview

This section provides an overview of auditing in the following sections:

- Auditing Design Components

- Profile Auditing

- Standard and Customized Reports

6.1.1 Auditing Design Components

Figure 6-1 shows the design components for Oracle Identity Manager auditing process.

Figure 6-1 Design Components of the Auditing Process

Description of "Figure 6-1 Design Components of the Auditing Process"

Any action that a user performs in Oracle Identity Manager translates into an Application Programming Interface (API) call or into a Message Driven Bean (MDB) picking up a message to process an action.One action can cause multiple changes. All changes are combined into an audit transaction. Each API method that can modify data objects calls the startTransaction method in the audit engine at the beginning of the API call and the endTransaction method at the end of the API call. This defines boundaries for the audit transaction. The audit engine generates a transaction ID to identify the changes made in the transaction.

6.1.2 Profile Auditing

Oracle Identity Manager provides auditing and historical archiving of profile information. It takes a snapshot of a profile, stores the snapshot in an audit table in the database, and updates the snapshot each time the profile data changes. In the context of profile auditing, the term snapshot means a copy taken of the entire profile data at any instant when the data is modified.

6.1.3 Standard and Customized Reports

The BI Publisher provides standard reports for viewing archived data. You can also create customized reports.

For information about reporting, refer to the following:

- ""Using Reporting Features""

- "Reporting" in Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about reporting

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:

- Audit Levels

- Tables Used for Storing Information About Auditors

- Issuing Audit Messages

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.2.2 Tables Used for Storing Information About Auditors

Information about auditors is stored in the following tables of the database:

- AUD: This table stores metadata about all the auditors defined in Oracle Identity Manager.

- aud_jms: This table stores data to be consumed by the audit engine and eventually by the auditors. It is an operational and intermediate staging table.
The key in this table is sent to the JMS. Oracle Identity Manager uses this table to control the order of the changes when multiple changes are made to the same user. You can use the Issue Audit Messages Task scheduled task to automate the reissue of messages that are not processed. This scheduled task is discussed in the "Issuing Audit Messages".

6.2.3 Issuing Audit Messages

Oracle Identity Manager provides a scheduled task named Issue Audit Messages Task. This scheduled task retrieves audit message details from the aud_jms table and sends a single JMS message for a particular identifier and auditor entry in the aud_jms table. An MDB processes the corresponding audit message.

The following is the attribute of this task:

Max Records

Use the Max Records attribute to specify the maximum number of audit messages to be processed for a specified scheduled task run. The default value of this attribute is 400.

If there is a backlog of audit messages in the aud_jms table, then you can increase the value of the Max Records attribute. The value that you set depends on how many messages the JMS engine can process during the default scheduled task execution interval. This, in turn, depends on the performance of the application server and database. Before increasing the Max Records value, you must determine how much time is taken to process the number of audit messages in the JMS destination (oimAuditQueue) by, for example, using the administrative console of the application server. If the time taken is less than the scheduled task interval, then you can make a corresponding increase in the value of the Max Records attribute.

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:

- Data Collected for Audits

- Post-Processor Used for User Profile Auditing

- Tables Used for User Profile Auditing

- Archival

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:

- Capture of User Profile Audit Data

- Storage of Snapshots

- Trigger for Taking Snapshots

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 documentation provided with Oracle Identity Manager.

- User Record: Contains the USR table, including all User Defined Fields (UDFs).
The USR table stores user attributes. When you create a user, Oracle Identity Manager adds an entry to this table.

- User Role Membership: Contains the RUL, UGP, and USG tables, as listed in Table 6-1.

Table 6-1 User Group Membership Tables

Table Name

Description

RUL

Stores rule definitions.

UGP

Defines groups and roles in the system.

USG

Defines which users are in which groups and lists priorities for the users in a specific group. Oracle Identity Manager might use these priorities when making task assignments for a group. For example, a process task might be assigned to the user having highest priority. In addition, if a role/group is granted through a rule, then it lists the specific rule.

- User Policy Profile: Contains the following tables:

- UPD: Stores User Policy Profile data. This is a policy-centric view of the resources that are provisioned to a user.

- UPP: Stores User Policy Profile-related details. This is a user-centric view of all the applicable policies for a user, and the resources they allow/deny.

Note:

When you change a role name by using the Administrative and User Console, the User Profile Audit (UPA) tables in the database are not updated with the change until the next snapshot of the user.

- User Resource Profile: This component can be divided into the following subcomponents:

- User Resource Instance: Contains the OBI, OBJ, and OIU tables, as listed in Table 6-2.

Table 6-2 User Resource Instance Tables

Table Name

Description

OBI

Stores resource (object) instance information. Oracle Identity Manager creates a resource instance every time a resource is provisioned. This instance stores all generic information related to that provisioned instance, including a request key (if the resource has been provisioned through a request), the corresponding process instance, and the instance status.

OBJ

Represents the resource object data, including details about the resource, such as resource name, whether or not auto-save and auto-prepopulate are set, and whether or not the resource object allows multiple instances.

OIU

Associates applicable user information to the resource object instance when provisioning takes place. In addition, it stores policy-related information for the specific resource instance.

- Resource Lifecycle (Provisioning) Process: Contains the MIL, ORC, OSI, PKG, SCH, and TOS tables, as listed in Table 6-3.

Table 6-3 Resource Lifecycle Process Tables

Table Name

Description

MIL

Defines the process task definitions. Each entry corresponds to a process task. A process definition (PKG table) comprises of multiple tasks, which are a part of the various workflows in the definition.

ORC

Stores process instance information when provisioning takes place. When provisioning starts, Oracle Identity Manager generates an associated process (or workflow) instance that stores process-related information specific to the provisioning instance.

OSI

Stores information about tasks created for process instance.

PKG

Defines processes or workflows in Oracle Identity Manager, including process details such as process name, process type, descriptive field mapping, and associated resources and process forms.

SCH

Stores information related to running of a specific task instance such as the task status, status bucket, and timing of when the adapter run started or ended.

TOS

Stores atomic process information.

- Resource State (Process) Form: This information is stored in the UD parent and child tables. The UD_* tables are user-defined field tables that store the account state.

6.3.1.2 Storage of Snapshots

When Oracle Identity Manager takes a snapshot of a user profile, it stores the snapshot in the UPA table. The structure of the UPA table is described in Table 6-4.

Table 6-4 Definition of the UPA Table

Column

Data Type

Description

UPA_KEY

NUMBER (19,0)

Key for the audit record

USR_KEY

NUMBER (19,0)

Key for the user whose snapshot is recorded in this entry

EFF_FROM_DATE

TIMESTAMP (6)

Date and time at which the snapshot entry became effective

EFF_TO_DATE

TIMESTAMP (6)

Date and time at which the snapshot entry was no longer effective

In other words, this is the date and time at which the next snapshot entry was created. For the entry representing the latest user profile, the To Date column value is set to NULL.

SRC

VARCHAR2 (4000)

User ID of the user responsible for the change, and the API used to carry out the change

SNAPSHOT

CLOB

XML representation of the snapshot

DELTAS

CLOB

XML representation of old and new values corresponding to a change made to the snapshot

SIGNATURE

CLOB

Can be used to store a digital signature for the snapshot (for nonrepudiation purposes)

Note:

The initial audit snapshots for default users in Oracle Identity Manager is not UTF-8 encoded. However, auditing of subsequent modifications to these users have UTF-8 encoded snapshots.

6.3.1.3 Trigger for Taking Snapshots

When any data element in a user profile changes, Oracle Identity Manager creates a snapshot.

The following events trigger the creation of a user profile snapshot:

- Modification of any kind to the user record (for example, through reconciliation and direct provisioning)

- Role membership change for the user

- Changes in the policies that apply to the user

- Provisioning a resource to the user

- Deprovisioning of a resource for the user

- Any provisioning-related event for a provisioned resource:

- Resource status change

- Addition of provisioning tasks to the provisioning process

- Updates to provisioning tasks in the provisioning process, for example, status changes, escalations, and so on

- Creation of or updates to Process Form data

6.3.2 Post-Processor Used for User Profile Auditing

The user profile auditor has an internal post-processor that normalizes the snapshot XML into the reporting tables: UPA_USR, UPA_FIELDS, UPA_GRP_MEMBERSHIP, UPA_RESOURCE, UPA_UD_FORMS, and UPA_UD_FORMFIELDS. These tables are used by the reporting module to generate the appropriate reports.

6.3.3 Tables Used for User Profile Auditing

Table 6-5 lists the tables in the database that User profile audits use:

Note:

For more information about the User Profile Audits tables, such as column names and how to use them, refer to the schema documentation provided with Oracle Identity Manager.

Table 6-5 User Profile Audit Tables

Table Name

Description

AUD

Stores detailed information about all of the Auditors (for example, the User Profile Auditor) supported by Oracle Identity Manager. Currently, only the UserProfileAudit entry is available.

AUD_JMS

Staging table that stores information about changes made as a part of any business transaction. This is an intermediate table to temporarily store data changelog data before the audit engine consumes it. When Audit messages are successfully processed, corresponding records are deleted from the table.

Note: This table is not intended for end users and must not be used directly.

UPA

Main auditing table for storing all snapshots and changes made to the user profiles.

UPA_FIELDS

Stores user profile audit history changes in denormalized (vertical) format.

UPA_GRP_MEMBERSHIP

Stores groups membership history in denormalized format.

UPA_RESOURCE

Stores user profile resource history in denormalized format.

UPA_USR

Stores user profile history in denormalized format.

UPA_UD_FORMS

Together with the UPA_UD_FORMFIELDS table, contains information about changes to the user's account profile (process form). This table keeps track of the changes to the various forms, such as parent or child forms, which are being changed in any transaction. The changes to the account or entitlement attributes are stored in the UPA_UD_FORMFIELDS table.

UPA_UD_FORMFIELDS

Stores the names of account or entitlement profile fields that are modified. This table also keeps track of the old and new values of the modified fields.

Note:

- The UPA_UD_FORMS and UPA_UD_FORMFIELDS tables together store the audit trail of changes to the user's account profile in a de-normalized format. These tables can be used in various audit-related reports.

- The UPA_UD_FORMS and UPA_UD_FORMFIELDS tables will be populated only if the XL.EnableExceptionReports system property is set to TRUE. For more information about this property, see "System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

6.3.4 Archival

User Profile audit data growth is based on the setting of the audit levels, and the growth can be significant in most of the deployments.

There is also a requirement to clean or archive the old user profile audit data to accommodate future growth.You can use Audit Archival and Purge Utility to meet these requirements. See "Using the Audit Archival and Purge Utility" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for detailed information about this utility.

6.4 Role Profile Auditing

Role profile audits cover changes to role profile attributes, role administrators, and direct subroles.

This section discusses the following topic:

- Data Collected for Audits

6.4.1 Data Collected for Audits

Unlike user auditing, an independent audit level is not defined for role profile auditing. Instead, the audit levels defined for user profile auditing are used for role profile auditing. Role profile auditing takes place only if the audit level defined for user profile audit level is Membership or a level higher than that. By default, user profile auditing is enabled and the audit level is set to Resource Form when you install Oracle Identity Manager. As a result, role profile auditing is also enabled by default because the default audit level for user profile audit is Resource Form, which is higher than Membership.

This section discusses the following topics:

- Capture and Archiving of Role Profile Audit Data

- Storage of Snapshots

- Trigger for Taking Snapshots

6.4.1.1 Capture and Archiving of Role Profile Audit Data

Each time a role profile changes, Oracle Identity Manager takes a snapshot of the role profile and stores the snapshot in an audit table in the database.

Oracle Identity Manager generates a snapshot when an audit is created for a role, even if an initial snapshot is missing. The current snapshot is treated as the initial snapshot.

The following are the components of a role profile and the tables that constitute these components:

- User role record: UGP table, including all UDFs for roles

- Subrole information: GPG table

6.4.1.2 Storage of Snapshots

When Oracle Identity Manager takes a snapshot of a role profile, it stores the snapshot in a GPA table. The structure of this table is as described in Table 6-6.

Table 6-6 Definition of the GPA Table

Column

Data Type

Description

GPA_KEY

NUMBER (19,0)

Key for the audit record

UGP_KEY

NUMBER (19,0)

Key for the role whose role snapshot is recorded

EFF_FROM_DATE

TIMESTAMP (6)

Date and time at which the snapshot entry became effective

EFF_TO_DATE

TIMESTAMP (6)

Date and time at which the snapshot entry was no longer effective

In other words, this is the date and time at which the next snapshot entry was created. For the entry representing the latest user profile, the To Date column value is set to NULL

SRC

VARCHAR2 (4000)

Source of the entry, User ID of the user responsible for the change, and the API used to carry out the change

SNAPSHOT

CLOB

XML representation of the snapshot

DELTAS

CLOB

XML representation of old and new values corresponding to a change made to the snapshot

SIGNATURE

CLOB

Can be used to store a digital signature for the snapshot (for nonrepudiation purposes)

6.4.1.3 Trigger for Taking Snapshots

When any data element in the role profile snapshot changes, Oracle Identity Manager creates a snapshot.

The creation of role profile snapshots is triggered by events that result in changes in any of the following:

- Role profile data

- Subrole information

6.5 Enabling and Disabling Auditing

This section describes how to enable and disable auditing in Oracle Identity Manager in the following sections:

- Disabling Auditing

- Enabling Auditing

6.5.1 Disabling Auditing

To disable auditing in Oracle Identity Manager:

1. Set the value of User profile audit data collection level (XL.UserProfileAuditDataCollection) system property to None, as described in "Modifying System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

2. Disable the Issue Audit Messages Task scheduled job as described in "Disabling and Enabling Jobs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
If pending audit changes are required to be recorded in the audit tables, then disable the scheduled task after all the pending audit changes are processed.

6.5.2 Enabling Auditing

To enable auditing in Oracle Identity Manager:

1. Set the value of User profile audit data collection level (XL.UserProfileAuditDataCollection) system property to one of the levels defined in "Audit Levels".
See "Modifying System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about modifying the values of system properties.

2. Enable the Issue Audit Messages Task scheduled job as described in "Disabling and Enabling Jobs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

3. Generate snapshots by running the GenerateSnapshot script as described in "Generating an Audit Snapshot" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.
The following is the command-line usage of the GenerateSnapshot script:

Note:

Before running the GenerateSnapshot and GenerateGPASnapshot utilities, you must set the WL_HOME and JAVA_HOME environment variables.

./GenerateSnapshot.sh -username OIM_ADMIN_USERNAME -numOfThreads 8 -serverURLt3://WLS_SERVER:PORT -ctxFactory weblogic.jndi.WLInitialContextFactory[-inputFile fileWithUserKeys]

Here:

- OIM_ADMIN_USERNAME is the Oracle Identity Manager administrator username.

- WLS_SERVER is the Oracle WebLogic Server name.

- PORT is the port number of the WebLogic Server.

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:

- Chapter 7, "Configuring and Using Self-Service Registration"

- Chapter 8, "Managing Profile"

- Chapter 9, "Managing Tasks"

- Chapter 10, "Managing Requests"

7 Configuring and Using Self-Service Registration

This chapter describes the tasks that you can perform using self-service registration and how to configure auto-approval for self-registration in the following sections:

- Using Self-Service Registration

- Configuring Auto-Approval for Self-Registration

7.1 Using Self-Service Registration

The login page provides the ability to log in, and provides a starting point for all unauthenticated operations. This page is displayed when you access Oracle Identity Manager Administrative and User Console without authenticating either natively to Oracle Identity Manager or by using SSO.

Typical tasks you can perform before logging in to Oracle Identity Manager Administrative and User Console include:

- Logging In to Oracle Identity Manager Administrative and User Console

- Submitting Registration Requests

- Tracking Registration Requests

7.1.1 Logging In to Oracle Identity Manager Administrative and User Console

To login to Oracle Identity Manager Administrative and User Console:

Note:

- If Oracle Identity Manager is configured to support native authentication, then the login link redirects you to a form in which you can authenticate by using your Oracle Identity Manager username and password.

- If Oracle Identity Manager is configured to support Single Sign-On (SSO), then the login link redirects you to the SSO application login page.

1. Go to Oracle Identity Manager Administrative and User Console login page.

2. In the User ID field, enter your username.

3. In the Password field, enter your password.

4. Click Sign In. If you are successfully authenticated, then you are logged in and directed to the main page in the authenticated context.
The login attempt might generate an error because of the following reasons:

- Incorrect credentials: If the user name and password entered are not correct, then an error message is displayed. This may be because of the following reasons:

- Username does not exist

- Password is incorrect

- Username exists but the user is deleted

Note:

- The system configuration property Maximum Number of Login Attempts provides the number of times authentication can fail before your OIM account is locked. By default this value is 10. The login backend must keep a counter of the number of times a failed login attempt occurs on an account. When login fails, the backend increments the count. For a successful authentication while the account is not locked, the counter is reset to 0. If the counter exceeds the value of the Login Failures Allowed before Lockout configuration property, then the account is locked. In addition, the value of the Account Locked On attribute is set to current timestamp, and the value of the Manually Locked attribute is set to No.

- If the configuration property is set to 0 or a negative number, then the account is not locked irrespective of how many login attempts fail.

- Locked account: If the account is locked, then you are not allowed to log in even if the credentials are correct. On trying to login with a locked account, the "Invalid sign in" message is displayed. Contact Oracle HelpDesk if your account is locked.

Tip:

Soft locking a user because of maximum login failures can be configured in Oracle WebLogic. This configuration is independent of the maximum login attempt configuration in Oracle Identity Manager and determines when and for what time user is to be soft locked. By default, the maximum login failures for a user to soft lock by WebLogic is five consecutive login failures because of incorrect passwords, and duration for locking is 30 minutes. You can modify this configuration by navigating to the following location in the WebLogic Administrative Console:

Home, Security Realms, myrealm, User Lockout in WLS Console

Therefore, if you try to login to Oracle Identity Manager Administrative and User Console with correct username and incorrect password for more than five times and less than 10 times, then your account is soft locked by WebLogic Security Realms, but remains unlocked in Oracle Identity Manager. Although your account is enabled and unlocked in Oracle Identity Manager, you cannot login for 30 minutes even by entering correct password, and your account cannot be unlocked before the configured time, for example 30 minutes.

If you try incorrect password for more than 10 times, your account will be locked by both WebLogic and Oracle Identity Manager. As a result, if Oracle Identity Manager administrator resets or unlocks the account, it is still soft locked by WebLogic and you cannot login till 30 minutes expire.

- Disabled user: If your user account is disabled, then you are not allowed to log in.

5. If your password has expired, then the Change Password page is displayed. You are not allowed to proceed to the main page of the console without changing the password. Enter a new password and click Apply.

6. If the system configuration property "Force to set questions at start up" is set to "Yes", then the login flow checks if you have set the required challenge responses on your profile. If not, then the form to set the challenge responses is displayed. If you have the challenge responses set, or if the configuration property is set to "No", then this step is skipped. In the form, set the challenge responses, and then click Submit.
Alternatively, you can click Remind Later if you want to defer setting challenge questions and continue with login to Oracle Identity Manager Self Service.

Note:

The PCQ.FORCE_SET_QUES system property with name 'Force to set questions at startup' indicates whether or not the challenge questions are required to be set on first logon. If setting challenge questions is not required, then the Remind Later button is displayed. On clicking this button, you can log in to the Administrative and User Console without setting the challenge questions.

If you attempt to access an Oracle Identity Manager UI page other than login and you are not already logged in, then you are redirected to the login page. Follow the login instruction provided in this section to log on to Oracle Identity Manager. Following successful login, you will then be redirected to the original page you tried to access.

7. After you log in for the first time, the Change Password page is displayed. This is because you must change your password after logging in for the first time. Enter a new password, and click Submit.

Note:

The XL.ForcePasswordChangeAtFirstLogin system property is no longer used in Oracle Identity Manager 11g Release 1 (11.1.1). Therefore, forcing the user to change the password at first login cannot be configured. By default, the user must change the password:

- When the new user is logging in to Oracle Identity Manager for the first time

- When the user is logging in to Oracle Identity Manager for the first time after the password has been reset by the administrator

- When the user's password has expired

7.1.2 Submitting Registration Requests

Oracle Identity Manager requires you to register yourself with identity to Oracle Identity Manager to perform certain tasks on Oracle Identity Manager Self Service. To register yourself in to Oracle Identity Manager:

1. In Oracle Identity Manager Administrative and User Console login page, click Register. The Basic information page of User Registration wizard is displayed.

Note:

The information required in the User Registration wizard is governed by the Self-Register User request dataset. See "Step 1: Creating a Request Dataset for the Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about request datasets.

2. Enter first name, middle name, last name, and email in the respective fields and click Next. The Login Information and Security Information page is displayed.
The UI does not allow you to enter more than the allowed number of characters. The maximum length for the values entered during self-registration is specified as 80 characters for First Name, Middle Name, Last Name, and Common Name and 382 characters for the Display Name.

If any other attributes are added on the self-service UI by modifying the Self-Register User request dataset, then the values will not be validated explicitly. The field on the UI will allow only as many characters to be entered as specified in the length field of the UI.

There is no restriction on the characters that can be entered in each of these fields. The input for each of these fields can contain any special characters, such as hash (#) and percentage (%).

Email should be provided as per the pattern mentioned against system property "XL.EmailValidationPattern". If the email is inappropriate, the UI gives an error "Invalid e-mail ID. Please enter a valid email ID." If the email Id specified is already used by any other user in the system, the UI gives an error "Email ID <email id> is already taken. Please enter a different Email ID."

3. In the Select a User ID and Password section, enter user login, password and confirm password. The password entered will be subjected to a password policy. On the next page, the password policy is shown adjacent to the password fields. If the password does not satisfy the criteria of the password policy, the UI gives an error defining the criteria required to be satisfied. Refer "Password Management" for detailed information about password policy.
If you do not enter the password, then the system generates the password automatically and emails it to the email address that you entered in the first page of the User Registration page.

Note:

- The registration form is prepopulated with attributes from self-registration templates.

- The Administrator can create custom registration forms by specifying a custom registration template name in the URL link. The URL link that the user uses will then determine the template and form used during registration. Therefore, multiple registration forms can be supported via multiple URL links. For registration, the URL link can either be configured on the UI or included in the e-mail requesting the user to register.

4. In the Set your Challenge Questions and Answers section, select the challenge questions and set an answer for each question. The challenge questions and answers are checked for:

- distinct challenge questions not selected

- distinct answers not specified for the challenge questions

If either of theses conditions are detected, then an error is displayed.

5. Click Register. You are provided a tracking ID for the registration request that can used for tracking the request.

Note:

- Challenge questions and answers are asked if the attribute for this is defined in the template for self registration.

- All Oracle Identity Manager deployments do not support self-registration. This is especially true of internal deployments that manage the identities of employees and contractors, where the identities are added through reconciliation and not self-registration.

- Oracle Identity Manager provides the Is Self-Registration Allowed system property to enable self registration. The Register link is always displayed on the unauthenticated self-service console. If the property is set to False, then clicking on the Register link gives an error, "Self registration is not allowed". If it is set to True, then self registration is allowed.

7.1.3 Tracking Registration Requests

You can track your request to register as an identity in Oracle Identity Manager. If the current status indicates success, then you can go to the Oracle Identity Manager Administrative and User Console, and then enter your username and password to log in to the Oracle Identity Manager Self Service.

To track your registration:

1. In Oracle Identity Manager Administrative and User Console login page, click Track Registration. The Request Status page is displayed.

2. In the Tracking ID field, enter the tracking ID that was assigned to your registration request. Then click Submit. The Self-Registration Status page is displayed with the following details:

- Request ID

- Request submission date
When the request is submitted and approval is not done, the date shown is the request submission date. In all cases, the date always reflects the last update date.

- Current status
Every self-registration request that is submitted has to go through approvals for it to be processed completely. See "Approval Levels" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for details about different approval levels.

If a user tracks the current status of the request, the status is shown with a description of the stage the request is in. The status would be one of the following:

- Pending: This state indicates that the request is submitted and the approval is pending. In case of default approval, the following status message is displayed:
"Obtaining request-level approval for registration. The manager needs to approve this request."

If the request level approval is pending. Once the request level approval is obtained, the following status message is displayed:

"Obtaining operation-level approval for registration."

- Rejected: This state indicates that the request is rejected during approval. The description indicates the reason of rejection. In case of default approval levels, if the request got disapproved at the request approval level, the following status message is displayed:
"Request approval rejected for registration."

If the request gets disapproved at the operation approval level, the following status message is displayed:

"Operation approval rejected for registration."

- Completed: This state indicates that the request is completed. If all the approvals have been provided and the request is successfully completed, the following status message is displayed:
"The registration request is completed."

- Failed: This state indicates that the request is failed during submission. If the request submission is failed, the following status message is displayed:
"The request registration failed."

Note:

You can only track the status of Self Registration Requests from this page.

7.2 Configuring Auto-Approval for Self-Registration

End-user self-registration can be configured so that the system will automatically approve new registrations without human intervention.

In the default Self-Registration request dataset, SelfCreateUserDataset.xml, the Organization field is designated as an approver-only field. This means that an approver must manually supply a value for the Organization field when approving the request. To configure the self-registration request dataset so that registrations are approved automatically, make a copy of the default dataset, remove the approver-only flag for the Organization field in the Self-Registration request dataset, and provide a link to the new template.

To configure auto-approval for self-registration:

Note:

You must understand the concepts covered in Chapter 10, "Managing Requests", before undertaking this task.

1. Create a new request template for Self-Register user by making a copy of the default template. Include the Organization attribute but add a restriction by specifying the organization that should be used.
For information about configuring the request template, refer to Chapter 17, "Managing Request Templates".

2. Modify the self-create user data set to remove the approver-only flag for the Organization attribute.
For details about request datasets, refer to "Creating a Request Dataset for the Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

For information about uploading the data set into MDS, refer to "Uploading Request Datasets into MDS" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

3. Create two new approval policies, one at request level and the other at the operational level for self registration, with auto-approval configuration.
For information about creating approval policy rules, see "Creating Approval Policies".

4. Refer to the following to use the newly created template for self-registration:

- The system takes a parameter T_ID=<template name> to use a custom template for self-registration. If the user clicks on the Register link, it takes the user to the following page:
http://host:port/oim/faces/pages/USelf.jspx?E_TYPE=USELF&OP_TYPE=SELF_REGISTRATION

This page uses the default template.

- To use a custom template, use T_ID at the end of the request, for example:
http://host:port/oim/faces/pages/USelf.jspx?E_TYPE=USELF&OP_TYPE=SELF_REGISTRATION&T_ID=<new_template>

This will display the self-registration page as per "new_template" instead of the default one.

8 Managing Profile

The Profile page enables you to view and modify personal details. The actions that you perform while managing a user profile are determined by the authorization policies defined for Self Service User Management. These authorization policies are defined for Oracle Identity Manager and stored in Oracle Entitlements Server (OES).

All authorization privileges are controlled by authorization policies. Every privilege that is granted is validated to check if you have the permission to use it. Table 8-1 lists the privileges for profile management operations:

Table 8-1 Profile Management Privileges

Privilege

Description

VIEW_USER_DETAILS

This privilege determines if you have the ability to view the user profile attributes in the Attributes tab of the My Profile page. This privilege supports fine-grained attribute level controls, which allows you to select the specific attributes that apply to that operation.

MODIFY_USER_DETAILS

This privilege determines if you have the ability to modify the user profile attributes in the Attributes tab of the My Profile page. This privilege supports fine-grained attribute level controls, which allows you to select the specific attributes that apply to that operation. If you have view and modify privileges for an attribute, it will be shown as an editable attribute on the My Profile page. If you have the view privilege only for an attribute, then it will be shown as a read-only attribute on the My Profile page.

MODIFY_SELF_USER_PROXY_PROFILE

This privilege determines if you have the ability to add, modify, and remove a proxy in the Proxies tab of the My Profile page.

See Also:

- Chapter 15, "Managing Authorization Policies" for details on authorization policies and authorization for profile attributes

- Chapter 17, "Managing Request Templates" for information about request templates

- "Configuring Requests" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about request datasets

To view the Profile section:

1. Login to Oracle Identity Manager Self Service.

2. Click the Profile tab.

The Profile page has the following sections:

- Managing Profile Attributes

- Managing Role Assignments

- Managing Resource Profile

- Managing Proxies

- Managing Security

- Resetting Forgotten Password

8.1 Managing Profile Attributes

The first tab of the My Profile page is the Attributes tab. This tab displays the user's profile attributes. The attributes that are displayed are controlled by field-level authorization policies that determine which profile attributes are visible to self.

By default, all the profile attributes are visible to the user. Any new attribute added for the user entity is by default set to be hidden from the user until explicitly made visible. The access to the profile attributes is controlled by authorization policies. For more information about the authorization policies for this feature, see "Authenticated User Self Service".

In addition, field-level authorizations determine if the attributes are editable or not by self. Editable attributes are displayed in editable text boxes or appropriate UI widgets, such as lookup fields. You can provide new values and click the Apply button to submit a change.

When the profile update is submitted, request is created for modification of all attributes:

- The attributes for which a request is raised are displayed and along with a tracking number for the request. Workflow rules determine the approval workflow to start and obtain approval before allowing the changes in attributes. The status of the request can be seen on the Requests tab of the self-service page. For more information about request tab and Modify User request, see Chapter 10, "Managing Requests".

- The Preferences section on the Attributes tab provides access to user preferences. Using this option, you can set your preferences on how you expect the product to behave.
The user preferences in Oracle Identity Manager are attributes stored as part of the user's profile. By default, the following attributes are shown on the UI:

- Locale: You can select the language preference for notification messages based on the languages supported by Oracle Identity Manager. The administrator defines the languages supported by installation as part of the deployment configuration. You can only select from the limited set of languages configured for the deployment.

Note:

In Oracle Identity Manager 11g release 1 (11.1.1.4), the language preference of the user for the UI is not set according to the locale specified by the user in the Preferences section of the Self Service. The UI locale is determined as described in "Setting the Language for Users" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Oracle Identity Manager supports translation of the following default languages:

- Arabic (ar)

- Czech (cs)

- Canadian French (fr-CA)

- Danish (da)

- Dutch (nl)

- English (en)

- Finnish (fi)

- French (fr)

- German (de)

- Greek (el)

- Hebrew (he)

- Hungarian (hu)

- Italian (it)

- Japanese (ja)

- Korean (ko)

- Norwegian (no)

- Polish (pl)

- Portuguese (pt)

- Brazilian Portuguese (pt-BR)

- Romanian (ro)

- Russian (ru)

- Simplified Chinese (zh-CN)

- Traditional Chinese (zh-TW)

- Slovak (sk)

- Spanish (es)

- Swedish (sv)

- Thai (th)

- Turkish (tr)

Tip:

To seed all supported MLS locales in Oracle Identity Manager, run the seedAllMLSLanguages operation of the MLSLanguageSeedingMBean Mbean in the System MBean Browser in Oracle Enterprise Manager. However, the locales are not seeded unless you restart Oracle Identity Manager. To seed the MLS locales without restarting Oracle Identity Manager:

1. Set JAVA_HOME and WL_HOME env variables.

2. Navigate to the $IDM_HOME/server/bin/ directory.

3. Run the PurgeCache.sh or PurgeCache.bat utility as follows:

./PurgeCache.sh SystemProperties

- Time Zone: You can specify the time zone in which all data is displayed.

- Note:

- Other default attributes can be added by modifying the user profile in the self service user management administration policy in Oracle Identity Administration. A custom policy needs to be created to view and modify other attributes in my profile.

- User-defined fields (UDFs) can be added by creating a policy and adding attributes in the self service user management administration policy in Oracle Identity Administration. To add the User defined attributes for view or modification under the Attributes tab, these UDFs need to be added to the modify user request dataset for self service. See "Configuring Requests" in the Fusion Middleware Developer's Guide for Oracle Identity Manager for information about request datasets.
In addition, a custom policy needs to be created under self service user management to grant permission to view and/or modify these attributes. For details on authorization policies, see "Creating and Managing Authorization Policies".

8.2 Managing Role Assignments

The Roles tab displays the roles of which you are a member, directly or indirectly. It displays the following information:

- Role Display Name: Displays the role name.

- Description: Displays the description of the role.

- Membership Type: Displays the membership type, either direct role or indirect role.

- Assigned Date: Displays the date on which you are assigned to a role.

The tab also provides options to start the following role management operations:

- Requesting Roles

- Removing Roles

8.2.1 Requesting Roles

To request a role:

1. Go to My Profile, Roles.

2. From the Actions list, select Request Role. The Select Roles page of the Request Role wizard is displayed. The roles those are made available for the end user in the list of roles on Request Roles page are the result of intersection of the roles provided in the request template and roles for which the user has search permission.

Note:

If you have access to any other request template other than default request templates, then you will be prompted to select a template. This step is skipped if you have access only to pre-defined templates.

3. In the Role Name field, enter the name of the role that you want to request. You can also search for roles based on role name and/or role display name by using the icon next to the Role Name field to display a list of available roles.

4. From the Available Roles list, select one or more roles that you want to request, and then click the Move icon to include the roles in the Selected Roles list.

5. Click Next. The Justification page is displayed.

6. Enter values in the Effective Date and Justification fields to specify the date from which the role is to be active and a comment to justify the request respectively.

7. Click Finish. You can view the status of the request on the Requests tab of Oracle Identity Manager Self Service. See Chapter 10, "Managing Requests" for the detailed information about request statuses.

8.2.2 Removing Roles

To remove a role:

1. Go to My Profile, Roles. A list of roles is displayed in a table.

2. Select a role to be removed in the table and from the Actions list, select Remove Role. The Select Roles page of the Remove Role wizard is displayed.

Note:

If you have access to any other request template other than default request templates, then you will be prompted to select a request template. This step is skipped if you have access only to default request templates.

3. In the Role Name box, enter the name of the role that you want to remove. You can also search for the role names by using the icon next to the Role Name field to display a list of available roles.

4. From the Available Roles list, select one or more roles that you want to remove, and then click the Move icon to include the roles in the Selected Roles list. This step is applicable only if a custom request template is configured for the self remove roles operation, and the user selects one of the templates.

5. Click Next. The Justification page is displayed.

6. Enter values in the Effective Date and Justification fields to specify the date from which the role is to be removed and a comments to justify the removal respectively.

7. Click Finish. The status of the request can be seen on the Requests tab of the self-service page. For more information about request tab, see Chapter 10, "Managing Requests".

8.3 Managing Resource Profile

The Resources tab displays the resources that are currently provisioned to you. For each resource in the list, you are allowed to view the following information associated with that resource:

- Resource name

- Status

- Identifying information

- Summary information block with additional information

You can drill down to a page that displays details about the provisioned resource. On this page, you can modify the resource by clicking the Modify Resource button. This redirects you to the Modify Resource request wizard with the beneficiary preset to self and the resource instance also preset. You can go through the process of providing the updates that you want to request, and any associated information. A tracking number for the request is generated.

Self-service requests can only modify one resource instance at a time and does not support bulk requests. If you want to modify another resource instance, then you must raise another request.

In the Resources tab, you can perform the following:

- Requesting a Resource

- Modifying a Resource

- Displaying Resource Details

8.3.1 Requesting a Resource

To request a resource:

1. Go to My Profile, Resources.

2. From the Actions list, select Request Resource. The Select Request Template page is displayed.

Note:

This page is displayed only if you have access to any other request template other than default request templates. You will be prompted to select a request template. This page is skipped if you have access only to default request templates.

3. From the Request Template list, select the request template assigned to the resource and click Next. The Select Resources page of the Request Resources wizard is displayed.

4. In the Resource Name field, enter the name of the resource that you want to request. You can also search for the resource names by using the icon next to the Resource Name field to display a list of available resources.

Note:

The resources displayed in this screen is a conjunction of the list of resources available and the list of resources restricted in request template that is being used. For example, If available resources are Active Directory, Exchange, and UNIX and in the template, if the resources are restricted to Active Directory and Exchange, this screen displays only Active Directory and Exchange.

If no resources are selected for restriction in the request template, then all the available resources are displayed.

5. From the Available Resources list, select a resource that you want to request, and then click the Move icon to include the resource in the Selected Resources list.

Note:

In case of bulk request, you must select two or more resources (two or more child requests will be created). The rest of the procedure is same for bulk request.

6. Click Next. The Enter Resource Data form is displayed.

7. Enter appropriate details related to the resource, and then click Next. The Justification page is displayed.

8. Enter values in the Effective Date and Justification fields to specify the date from which the resource is to be active and a comment to justify the request respectively.

9. Click Finish. The status of the request can be seen on the Requests tab of the self-service page. For more information about request tab, see Chapter 10, "Managing Requests"

8.3.2 Modifying a Resource

To modify a resource:

1. Go to My Profile, Resources.

2. From the Actions list, select Modify Resource. The Select Request Template page is displayed.

Note:

This page is displayed only if you have access to any other request template other than default request templates. You will be prompted to select a request template. This page is skipped if you have access only to default request templates.

3. From the Request Template list, select the request template assigned to the resource and click Next. The Select Resources page of the Request Resources wizard is displayed. The Select Resources page is displayed.

4. In the Resource Name field, enter the name of the resource that you want to modify. You can also search for the resource names by using the icon next to the Resource Name field to display a list of available resources.

5. From the Available Resources list, select one or more resources that you want to request, and then click the Move icon to include the resource in the Selected Resource list.

6. Click Next. The Resource related page is displayed in which you can modify the resource details. Enter the updates that you want to request and any associated information.

Note:

You can raise a request to modify one resource instance at a time, and this model does not support bulk requests. If you want to modify another resource instance, then you must raise another request.

7. Click Next. The Justification page is displayed.

8. Enter values in the Effective Date and Justification fields to specify the date from which the resource is to be active and a comment to justify the request respectively.

9. Click Finish. The status of the request can be seen on the Requests tab of the self-service page. For more information about request tab, see Chapter 10, "Managing Requests".

8.3.3 Displaying Resource Details

To display resource details:

1. Go to My Profile, Resources.

2. From the resource information table, select a resource.

3. From the Actions list, select Open Resource Details. The Resource Details form with the details such as resource name, description, type, status, service account, and date provisioned are displayed for the selected resource.

8.4 Managing Proxies

The Proxies tab allows you to view and manage the proxy information. It displays the proxies currently set up within Oracle Identity Manager for you, and also allows you to view previously set up proxies. The Past Proxies view is read-only and no modifications are allowed.

The existing proxy view allows you to cancel an upcoming proxy whose start date is in the future. You can also edit only the end date of an in-progress proxy whose start date is in the past and end date is in future or not specified.

In the Proxies tab, you can also add new proxies. When adding up new proxies, you must specify a start date, an end date, and the proxy user.

This section contains the following topics:

- Adding a Proxy

- Editing a Proxy

- Removing a Proxy

8.4.1 Adding a Proxy

To add a proxy:

1. Go to My Profile, Proxies.

2. In the Current Proxies section, from the Actions list, select Add Proxy. The Add Proxy window is displayed.

3. In the Proxy Name field, select My Manager to specify your manager as proxy. Otherwise, select Other User to specify any other user as proxy. To do so, click the lookup icon to search for the user you want to specify as proxy.

Note:

The user search result is governed by authorization policies. For more information, see Chapter 15, "Managing Authorization Policies".

4. In the Start Date field, specify a start date.

5. In the End Date field, specify an end date.

6. Click Apply. A message box is displayed asking for confirmation.

7. Click Yes.

Note:

Oracle Identity Manager does not allow adding another proxy whose start and end dates overlap with the existing proxy.

8.4.2 Editing a Proxy

To edit a proxy:

1. Go to My Profile, Proxies.

2. In the Current Proxies section, from the Actions list, select Open Proxy Detail. The Proxy Detail window is displayed.

3. In the Proxy Name field, select My Manager to specify your manager as proxy. Otherwise, select Other User to specify any other user as proxy. You can search for the user name.

Note:

To change the proxy user, you can search only those users for which you have search permission.

4. Click Edit. In case of active proxy, you cannot edit the proxy name and the start date, but in case of the proxy that has not started, you can change the proxy user, start date, and end date.

5. Click Apply. A message box is displayed asking for confirmation.

6. Click Yes.

8.4.3 Removing a Proxy

To edit a proxy:

1. Go to My Profile, Proxies. A table with the list of proxies is displayed.

2. Select a proxy to be removed.

3. In the Current Proxies section, from the Actions list, select Remove Proxy. The Remove Proxy window is displayed.

4. Click Remove. A message box is displayed asking for confirmation.

5. Click Yes.

8.5 Managing Security

The Security tab allows you to change your profile attributes related to password security. Using this tab, you can perform the following tasks:

- Changing Password

- Setting Challenge Questions and Response

8.5.1 Changing Password

Using this feature, you can reset your enterprise password. To specify a new password, enter and re-confirm the new passwords. The new password is evaluated for compliance against the applicable password policy, which is displayed on the Change Password page. If the new password does not comply with the password policies, then the password change will be rejected and you will be informed of the failing condition(s). If the password evaluates successfully against all policies, then the enterprise password is changed.

To change the password:

1. Go to My Profile page, click the Security tab.

2. In the Password section, click Change Password. The Change Password window is displayed with the applicable password policy.

3. In the Old Password field, enter the existing password.

4. In the New Password field, enter the new password that you want to set.

5. In the Re-Type New Password field, re-enter the new password.

6. Click Apply. If the old password is valid and the new password is in compliance with the password policy, then the password is changed. Otherwise, an error message is displayed.

8.5.2 Setting Challenge Questions and Response

The challenge-response service allows you to set up a series of challenge questions that are used to validate the user's identity. Only the user should know the correct answers to the challenge questions.

Questions and answers are stored as part of the user's profile as a name-value pair list, where the name is the question, and the value is the answer to that question. For example, for user John Doe, the challenge-response set could be as follows:

Challenge

Response

What is your favorite color?

Blue

What is the name of your pet?

Rex

What is the city of your birth?

New York

Note:

Oracle recommends defining answers to challenge questions that cannot be guessed easily by collecting information about the user from the Internet or other public sources.

When a user's identity needs to be validated without relying on the authentication scheme, the challenge questions are asked, and the user must provide the necessary number of correct answers.

Oracle Identity Manager configuration properties for this feature are as follows:

- PCQ.USE_DEF_QUES: If Oracle Identity Manager has been customized to allow end-users to create their own challenge questions, this property specifies whether users must select their challenge questions from a predefined list, or if users should create their own challenge questions. The default value is TRUE (users must select their challenge questions from a predefined list). To require users to provide their own challenge questions, set the value to FALSE.

Note:

Functionality that allows end-users to create their own challenge questions is not supported in the standard, out-of-the-box user interface.

- PCQ.NO_OF_QUES: Sets the number of challenge questions that must be completed by a user. The default value is 3.

- PCQ.FORCE_SET_QUES: Determines if new users must set up challenge questions upon logging into the application for the first time, or if new users can skip this step and do it later. New users are redirected to the Self.jspx page where the user can select challenge questions. This page includes a Skip button so that users can skip the challenge question set up process.

Note:

You can access the Admin.jspx page in another tab. This is the same page for setting challenge questions in the Oracle Identity Manager Administrative and User Console by performing the password validation.

- PCQ.NO_OF_CORRECT_ANSWERS: Represents how many questions the user must answer correctly to reset user password.

To set the challenge questions and responses:

1. Go to the My Profile page and click the Security tab.

2. In the Challenge Questions section, select questions from the Question 1, Question 2, and Question 3 fields.

3. In the corresponding Answer 1, Answer 2, and Answer 3 fields, select the answers.

4. Click Apply.

8.5.2.1 Localizing Challenge Questions and Responses

The following default challenge questions are localized automatically in Oracle Identity Manager:

- What is the name of your pet?

- What is the city of your birth?

- What is your favorite color?

- What is your mother's maiden name?

Localized default challenge questions are located in the xlWebAdmin_LANG.properties file. Here, LANG is the locale code.

If you add custom challenge questions to Oracle Identity Manager Design Console for lookup code Lookup.WebClient.Questions, add corresponding properties to the custom resource bundles to localize the question text in the supported languages. Corresponding translations should be saved to the following file:

CustomResource_LANG.properties

For example, you might add the new challenge question What is your favorite sport?. To localize this text, add properties to the property files in the following format:

global.Lookup.WebClient.Questions.question-text=value

Replace any white spaces in the question text with a hyphen (-). For example, to localize the "What is your favorite sport?" challenge question in French, add the following property to the customResources_fr.properties file:

global.Lookup.WebClient.Questions.What-is-your-favorite-sport?= Quel est votre sport favori?

To modify the text of the default challenge questions, add corresponding properties to the custom resource bundles. For example, to modify the text of the "What is your favorite color?" question to use the British spelling (colour) instead of the American version (color), add the following new property in the CustomResource_en.properties file:

global.Lookup.WebClient.Questions.What-is-your-favorite-color?=What is your favourite colour?

To modify the text of the default challenge questions for a specific locale, add properties for the modified questions to the customResources.properties file and the customResource_lang.properties file that represents the locale's language. For example, the customResources_ja.properties file contains language property translations for Japanese.

8.6 Resetting Forgotten Password

If you have forgotten your Oracle Identity Manager password, you can reset it by entering your responses for a series of challenge questions.

To reset your forgotten password:

1. In Oracle Identity Manager Administrative and User Console login page, click Forgot Password. The Enter Your User Login page of the Forgot Password wizard is displayed.

2. In the User Login field, enter your user login to allow Oracle Identity Manager to locate your user record. Then click Next. The Answer Challenge Questions page is displayed.

3. In this page, the wizard provides the challenge questions that you set during user registration to verify your user identity or edited by using the Self Service. This page also displays the applicable password policies. Enter your responses to the challenge questions, and then click Next. The Set a New Password page is displayed.

See Also:

Chapter 7, "Configuring and Using Self-Service Registration" for information about registering to oracle Identity Manager

4. In this step, enter the new password that you want to set, and click Save. The following are the possible outcomes of these steps:

- If the new password fails to satisfy the configured password policies, then an error message is displayed specifying the rules of the password policy that are not met by the specified password. Also, if you exceed the maximum number of reset password attempts, you will no longer be able to perform this operation. An error message will be displayed stating, "User has exceeded the maximum number of password reset attempts allowed."

- If you satisfy the identity verification criteria and the password is successfully set, a message is displayed stating that the password has been reset and you will be automatically logged in to the Self-Service console.

- Password reset fails because either the user account is invalid or the challenge questions are not defined for this account.

Note:

The PCQ.NO_OF_QUES configuration property, as mentioned in "Setting Challenge Questions and Response", which controls the challenge questions in the Forgot Password wizard are:

- Number of Challenge Questions to Ask: Number that specifies how many challenge questions to display in the wizard and to collect responses for.

- Number of Correct Responses Needed: Number that specifies how many challenge questions must be answered correctly to pass the identity verification test. This cannot be greater than the previous configuration property.

9 Managing Tasks

In the Welcome page of Oracle Identity Manager Self Service, when you click Tasks, the My Tasks page is displayed. This page displays the task instances of specific types. These types are associated with specific Oracle Identity Manager components. The task types are approvals, provisioning, and attestation. The My Tasks page can be used by both administrators and end-users. For example, an IT department personnel responsible for delivering a laptop to an employee may not be an Oracle Identity Manager administrator, but needs to view and change provisioning tasks.

The following task types are supported in Oracle Identity Manager:

- Approval tasks: These tasks are instantiated by request service and correspond to associated requests that are in the user or administrator's queue to be approved. For more information about approval tasks, see "Managing Approval Tasks".

- Provisioning tasks: These tasks correspond to either pending manual provisioning tasks or failed automatic provisioning tasks in the user or administrator's queue. For more information about provisioning tasks, see "Managing Provisioning Tasks".

- Attestation tasks: These tasks correspond to outstanding attestation process in the user or administrator's queue. For more information about attestation tasks, see "Managing Attestation Tasks".

Note:

Only approval tasks are fetched from Oracle Service Oriented Architecture (SOA) Server and rest of the tasks come from Oracle Identity Manager.

9.1 Managing Approval Tasks

Oracle Identity Manager request service interacts with SOA Server to handle various aspects of human interaction in Oracle Identity Manager workflows. This request service is used to assign tasks to identities, such as users and roles. You can perform various operations upon tasks assigned to you. For example, you can approve, reject, or claim a task, or request for more information. The process flow in corresponding Oracle Identity Manager workflow is dependent on the outcome of given tasks.

See Also:

"Approval Workflows" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information information about approval workflows

When a request is submitted, the request service initiates the approval as a task in Oracle SOA Server. This task is assigned to the approver. Further processing of this request by request service remains pending, which is subject to the outcome of the corresponding task. The approver must be able to access the Approvals tab in the All Tasks section that lists all the tasks assigned to the approver. The approver can now act upon this task and set its outcome, for example, approve or reject. After the task outcome has been set, the request service resumes the processing of the request that is based on the task outcome.

On successful submission of requests, the request service invokes request service, which creates Human Tasks in SOA and assigns them to users or roles in Oracle Identity Manager. Authenticated users can view the tasks waiting for action in the Approvals tab. When you click Tasks in Oracle Identity Manager Self Service, the Approvals tab is open by default.

You can perform the following tasks in the Approvals tab:

- Searching Approval Tasks

- Viewing Task Details

- Claiming a Task

- Approving a Task

- Rejecting a Task

- Reassigning a Task

- Requesting for More Information

- Submitting Information

9.1.1 Searching Approval Tasks

In the Approvals tab, you can search for requests based on task name, request ID, start date, and end date. The search results are displayed in a table in the lower part of the Approvals tab. From the View Tasks Assigned To list, you can select the following:

- You Only: To display only the approval tasks assigned to you

- Roles You Have: To display the requests assigned to the roles of which you are a member

- You and Roles You Have: To display the requests assigned to you and to the roles of which you are a member

- Users You Manage: To display the requests assigned to your reportees

The table in the lower part of the Approvals tab lists all tasks that are assigned to you and Roles you have, by default. Using this table, you can perform operations on tasks and can also view the Task details. For information about task details, see "Viewing Task Details".

Table 9-1 describes the columns in the full tasklist view table:

Table 9-1 Columns in the Full Tasklist View Table

Column

Description

Request ID

ID of the request associated with the approval task

Request Type

The type of request

Beneficiary

The beneficiary for the request

Request Target

The target entity associated with the request. It can be either role name or resource name or user name

Example 1: For "Assign Roles" type of request, it is role name

Example 2: For "Provision Resource" type of request, it is resource name

Example 3: For "Modify User" type of request it is user display name

Requester

The user who created and submitted the request

Assignee

The user or role to whom the approval task is assigned

Date Assigned

The date when the task was assigned to you or the role

9.1.2 Viewing Task Details

When you click on Request ID link of any of the approval tasks in the table, Task details are shown for that approval task.

The Task Details page displays a detailed view of the request in the Basic Details and Request Information sections. It allows complete management of the listed task. To display the task details view, select a row in the full tasklist table, and then select Open Task Detail from the Actions list.

If some attributes are marked as approver-only in request 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 (if the field is marked as mandatory) the approver will not be allowed to approve a request. In the next level of approval, the approver can modify the data, if required. Similarly, if the approver sends the task to another user for more information (using the 'Request More Information' operation), then the user to whom it is assigned can see an additional section called "Additional Request Information" in Task details and the user can send a response to the information requested.

In addition, the following tabs display details associated to the request:

- Resources or Users or 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 Users tab shows the user details that is part of a request. For example, for CreateUser, the Users tab displays the user name and "View Details" link provides the attributes of the user provided during the request creation.

The Roles 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 request comments associated with the request. The comments recorded are questions and responses for Request More Information. For example, the comments that an approver requests for additional information from the user and the response provided by the user to those queries are recorded in this section.

- Request History: This tab displays the various changes the request has been through in the process of execution.

Modification of task details can only be performed in the Task Details page. Following modifications are supported:

- An approver might need to fill in some mandatory request information before approving the corresponding task. For this, the Task Details page displays the "Additional Data From Approver" section, where approver can fill in the required information.

- An approver can explicitly add comments in task. All the request comments are displayed in the Request Comments tab in the Task Details page. You can also add comments indirectly while requesting for more information or submitting information on a task. For information about requesting for more information and submitting information, see "Requesting for More Information" and "Submitting Information" respectively.

9.1.3 Claiming a Task

If a task is assigned to a role, then all users who belong to that role view the task in their queue. You can claim a task that is assigned to the roles you have, and approve it later. For example, when a request is created to provision a laptop to a user, the request-level approval is configured to be provided by the requester's manager, and the operation-level approval is configured to be given by a user who is a member of the resource IT administrator group. Therefore, after the request-level approval is obtained, the request is submitted for operational-level approval. For this, the user who is a member of the resource IT administrators role must first claim the task to be able to approve or reject it later.

To claim a task:

1. In the Welcome page of Oracle Identity Manager Self Service, click Tasks.

2. From the View Tasks Assigned To list, select Roles You Have. The tasks assigned to the roles to which you are a member are displayed in the search results table.

3. Select the task that you want to claim.

4. From the Actions list, select Claim Task. A message is displayed stating that the task has been claimed successfully.

9.1.4 Approving a Task

The Approval Tasks displayed in the Approvals table can be of the following two levels of approval:

- Template Level

- Request Level

- Operational Level

Note:

the template level approval can fill values for attributes in the 'Additional Data From Approver'.

To approve a request level task that is assigned to you:

1. Go to Tasks, Approvals and click Search. As an approver, if you are expected to provide some information before approving the task, then provide the information in the "Additional Data From Approver" section of the Task Details page.

Caution:

If no information is provided before approving a task for which information is requested, then you are not allowed to approve the request until you provide some information in the Additional Data From Approver' section. This is applicable only for fields that are marked as mandatory in the request dataset.

2. Select a request in the full tasklist view table.

3. From the Actions list, select Approve Task. The request is approved and is no longer displayed in the full tasklist view table.

To approve a operational level task that is assigned to you:

1. Go to Tasks, Approvals and click Search. The operational level requests are displayed.

2. Select a request in the full tasklist view table.

3. From the Actions list, select Approve. The request is approved and is no longer displayed in the full tasklist view table.

9.1.5 Rejecting a Task

To reject a request that is assigned to you:

1. Go to Tasks, Approvals and click Search.

2. Select a request in the full tasklist view table.

3. From the Actions list, select Reject Task. The system prompts you to enter comments for rejecting the request.

4. Enter the comments and click Reject. The task is rejected and is no longer displayed in the full tasklist view table. The comments that you enter here are recorded in the "Request Comments" section of the Task Details page.

9.1.6 Reassigning a Task

To reassign a request that is assigned to you:

1. Go to Tasks, Approvals and click Search.

2. Select a request in the full tasklist view table.

3. From the Actions list, select Re-Assign. The Re-Assign Task dialog box is displayed.

4. Search and select the user or role to whom you want to reassign the task.

5. Click Re-Assign.

Note:

The functionality supported by Oracle Identity Manager task list is a subset of functionality offered by SOA human workflow component.

9.1.7 Requesting for More Information

An approver can request the Requester or some other user (in Oracle Identity Manager) for more information about the request associated with the task. After this action is performed, the task is converted to Request For Information (RFI) type of task and is assigned to the specified user. This action is only available on the task details view. The exchange of information between the approver and the user is added to the Comments tab of the Task Details page.

To request for more information about a task:

1. Go to Tasks, Approvals and click Search.

2. In the search results, click the request ID link to open the Task Details window.

3. In the Task Details window for a task, from the Actions list, select Request More Information. The Request More Information dialog box is displayed.

4. In the Send to field, select Requester or search and select some other user from whom you want more information about the task.

5. Enter the details about the required information.

6. Click Submit Request. A message is displayed stating that the task is sent for additional information.

7. Click OK.

When the user to whom the information is requested views the request in the Approvals tab page of Oracle Identity Manager Self Service, RFI is added to the task preview, as shown in Figure 9-1:

Figure 9-1 The RFI Task

Description of "Figure 9-1 The RFI Task"

9.1.8 Submitting Information

This action is only applicable on the RFI type of tasks. You can provide the requested information by using task comment(s), and then use this action to submit the requested information. After this action is performed, the task is converted to original approval task again. It is then reassigned back to the original user who had requested for more information and task approval flow continues from there. This action is only available on the task details view.

User can submit the additional info requested by approver using this action. The requested query will be shown and the user needs to provide the details. The exchange of information is recorded as comments.

When you select the task and expand the Actions menu, the Approve, Reject, Re-Assign, and Claim Task options are not available because you must provide the requested information before performing any of these actions. Only the Task Details option is available, as shown in Figure 9-2, so that you can view the details of the task and provide the requested information.

Figure 9-2 Available Option for an RFI Task

Description of "Figure 9-2 Available Option for an RFI Task"

To submit information:

1. In the Task Details: Approval tab, click on the Request ID link of the RFI task. Alternatively, you can select the RFI task, and from the Actions menu, select Select Open Task Detail. The Task Details view for the RFI task is displayed, as shown in Figure 9-3:

Figure 9-3 RFI Task Details

Description of "Figure 9-3 RFI Task Details"

2. In the Additional Request Information section, in the Response field, enter the information that is requested about the task.

3. Click Submit to Approver. A message is displayed stating that the additional information is submitted successfully.

4. Click OK.

After submitting to the Approver, this task will get assigned back to the original approver. This task can now be approved, rejected, reassigned, or claimed by the approver.

All the additional information submitted for a request can be viewed in the Request Comments tab of the Task Details page.

9.2 Managing Provisioning Tasks

This tab displays all provisioning tasks assigned to you or pending actions in your inbox. In addition, failed automatic provisioning tasks that you must review to take corrective action are displayed in your inbox. You must take corrective action, such as retry and manually complete, on those tasks.

The provisioning tasks feature is used by administrators as well as users. For example, the person in IT administration who is responsible for delivering a laptop computer to an employee may not be an administrator in Oracle Identity Manager, but must view and change provisioning tasks.

You can perform the following tasks in the Provisioning tab:

- Searching Provisioning Tasks

- Viewing Provisioning Task Details

- Adding Notes to a Task

- Reassigning a Task

- Viewing Task Assignment History

- Viewing Form Details

- Modifying Form Details

- Retrying a Task

9.2.1 Searching Provisioning Tasks

The first section in the Provisioning tab page allows you to search for the provisioning tasks assigned to you or on which your action is pending. Specify values in the following fields to search for the provisioning tasks:

- Match: Select All if you want to match all the search criteria that you specify. Select Any if you want to match any search criteria that you specify.

- Task Name: Specify a task name that you want to search. To do so, select any one of the equal, contains, begins with, or ends with search operations.

- Resource Name: Specify a resource name whose provisioning task you want to search. To do so, select any one of the equal, contains, begins with, or ends with search operations.

- Status: Select Pending or Rejected to search for tasks for which your action is pending or for rejected tasks respectively.

After specifying the search criteria, when you click Search, the search results table is displayed. Table 9-2 lists the fields in the search results table:

Table 9-2 Fields in the Provisioning Tasks Search Results Table

Field

Description

Task Name

The name of the task

Task Status

The status of the task, which is Pending or Rejected

Resource Name

The name of the resource, which is affected by this task

Beneficiary

The user whose provisioned resource will get affected because of this task

Date Assigned

The date and time when the Provisioning task has been assigned to the Assignee

Assignee

The user to whom the task is assigned

9.2.2 Viewing Provisioning Task Details

To view provisioning task details:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task whose detail you want to view.

3. From the Actions list, select Open Task Detail.

Table 9-3 lists the fields in the Task Details window:

Table 9-3 Fields in the Task Details Window

Field

Description

Task Name

The name of the task

Resource Name

The name of the resource, which is affected by this task

Description

A description of the task

User

The beneficiary user name

Status

The status of the task, Pending or Rejected

Response

The response set by the user on the Set Response page

Note: For information about setting response, see "Setting Response for a Task".

Response Description

The description of the response that is defined in the Response tab of the Task Definition section in Oracle Identity Manager Design Console

Notes

The additional comments entered by the approver

Assigned to

The user to whom or role to which the task is assigned

Note: If the task is assigned to a role, this property will come as "Assigned to Role" with the role details.

Error Details

The error, if any, while setting the response

Projected Start

The date when the task is scheduled to start

Projected End

The date when the task is suppose to end

Actual Start

The date when the task was started

Actual End

The date when the task was ended

Last Update

The date when the task was last updated

9.2.3 Setting Response for a Task

As an approver, you can set a response for the task while taking an action on the task. To set a response for a task:

Note:

Response cannot be set if there are no response codes defined for the corresponding tasks. Response codes are defined by using Oracle Identity Manager Design Console. For more information about defining response codes, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task whose detail you want to view.

3. From the Actions list, select Open Task Detail. The Task Details window is displayed.

4. In the Specify Task Responses page, select one of the multiple responses defined and click Set Response.

9.2.4 Adding Notes to a Task

Notes are additional comments provided by the approver. These comments are optional.

To add notes to a task:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task whose detail you want to view.

3. From the Actions list, select Open Task Detail. The Task Details window is displayed.

4. In the Task Details window, click Add Notes. The Add Notes for Task window is displayed, as shown in Figure 9-4:

Figure 9-4 The Add Notes for Task Window

Description of "Figure 9-4 The Add Notes for Task Window"

5. In the Enter Additional Notes field, enter the note that you want to add to the task.

6. Click Add Notes.

9.2.5 Reassigning a Task

As the approver, you can reassign a task to another user or role for taking appropriate action on the task. When the task is reassigned to another user, the assignee becomes the approver. When the task is reassigned to a role, any one member of that role can approve or reject the task.

To reassign a task to another user or role:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task whose detail you want to view.

3. From the Actions list, select Open Task Detail. The Task Details window is displayed.

4. In the Task Details window, click Reassign. The Select User Assignee for Task window is displayed, as shown in Figure 9-5:

Figure 9-5 The Select User Assignee for Task Window

Description of "Figure 9-5 The Select User Assignee for Task Window"

5. Select User or Role depending on what you want to search for. A list of users or roles is displayed, depending on your selection. You can also filter the search by specifying a criteria for filtering and entering a value in the Filter By field.

6. In the Reassign column, select a user or role to whom you want to assign the task.

7. Click Reassign.

8. In the Confirm Tasks to Reassign page, read the details of the action that you are performing and select Confirm Re-assign Task to reassign the task or select Cancel Re-assign Task to cancel the task reassignment.

9. Check whether the value in the Assigned to section is properly updated according to the above reassignment action.

9.2.6 Viewing Task Assignment History

To view the assignment history of a task:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task whose detail you want to view.

3. From the Actions list, select Open Task Detail. The Task Details window is displayed.

4. In the Task Details window, click Task Assignment History. The Task History window is displayed, as shown in Figure 9-6:

Figure 9-6 The Task History Window

Description of "Figure 9-6 The Task History Window"

The task assignment history is displayed in the fields, as shown in Table 9-4:

Table 9-4 Fields in the Task History Window

Field

Description

Task Status

The status of the task, Pending or Rejected

Task Action

The source details of the task, for example, when the task is first created it will be "Engine". If the user reassigns the task, it will be "User".

Assign Type

The type of the assignee of the task, for example, when the task is assigned for the first time, it is "Default Task Assignment". If the task is reassigned, then its value is either user or role.

Assigned to User

The user to whom the task is assigned

Assigned to Role

The role to which the task is assigned

Assigned By

The user who assigned the task

Assigned Date

The date when the task was assigned

9.2.7 Viewing Form Details

You can view the process form attached with a task. These are process forms associated with the underlying process definition. A task is embedded in the process definition.

To view the process form attached with a task:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task for which you want to view the process form.

3. From the Actions list, select Open Form. The View Form window is displayed.

9.2.8 Modifying Form Details

To modify the process form details:

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task for which you want to modify the process form.

3. From the Actions list, select Edit Form.

4. Modify the required details and click Save.

9.2.9 Retrying a Task

As the approver, you can retry a task when an error was generated while setting the response in the first attempt. To retry a task:

Note:

Only automated tasks can be retried, and an adapter must be attached to the task. Manual tasks cannot be retried.

1. Go to Tasks, Provisioning and click Search.

2. In the search results table of the Provisioning tab. select a task that you want to retry.

3. From the Actions list, select Retry Task. A message is displayed stating the status, whether the task is successfully retried or not.

9.3 Managing Attestation Tasks

Attestation enables users designated as reviewers to be notified of reports they must review. These reports describe provisioned resources of other users. A reviewer can attest to the accuracy of the 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.

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.

The Attestation tab in Oracle Identity Manager Self Service displays all attestation processes assigned to you or pending your actions in your inbox. In the My Tasks section, when you click the Attestation tab, the Attestation page is displayed.

Note:

Using Oracle Identity Manager integrated with Oracle Identity Analytics (OIA) replaces the attestation functionality.

You can perform the following tasks in the Attestation tab:

- Searching Attestation Tasks

- Viewing Attestation Request Detail

9.3.1 Searching Attestation Tasks

To search for attestation tasks:

1. Go to Tasks, Attestation.

2. In the Search Task section of the Attestation tab, select All to search all the tasks that match the criteria you specify. Otherwise, select Any to search any task that matches your criteria.

3. In the Task Name field, enter the name of the task that you want to search. To do so, select the equals, contains, ends with, or begins with search operators.

4. In the Start Date field, specify a start date of the task by using the Start Date icon next to the field. To do so, select the after, equals, or before search operators.

5. Click Search. The attestation tasks that match the search criteria are displayed in a search results table. Table 9-5 shows the fields in the search results table:

Table 9-5 Fields in the Attestation Task Search Results Table

Field

Description

Task Name

The name of the task.

Process Code

An unique identifier for the task that is entered by the user.

Start Date

The start date of the attestation task.

Type

The type of task. This is hard coded as 'Access Right'.

Number of records

The number of records displayed as the search result.

9.3.2 Viewing Attestation Request Detail

To view attestation request detail:

1. Go to Tasks, Attestation.

2. In the Attestation tab, select an attestation task for which you want to view the request detail.

3. From the Actions list, select Attestation Request Detail. The Attestation Request Detail window is displayed, as shown in Figure 9-7:

Note:

Multiple users, designated as reviewers can view the attestation request details. However, only one user, whoever does it first, can submit the attestation.

Figure 9-7 The Attestation Request Detail Window

Description of "Figure 9-7 The Attestation Request Detail Window"

Table 9-6 lists the fields in the Attestation Request Detail window:

Table 9-6 Fields in the Attestation Request Detail Window

Field

Description

Process

Name of your attestation process created.

Request Time

The time when the request is created.

Hide records where action has already been specified

Whether or not the records for which action has been specified must be hidden from the list of attestation requests.

User

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

Resource

Resource 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 Data

Description of the provisioned resource instance.

Last Attested

Last response that was provided for the attestation.

Comments

Reviewer comments. The comments will be updated in this field, when you click Update Existing Comments and Delegation Information. Long comments are truncated, and tooltips are used to show the full text of the comments.

Actions

Action to be performed on the request. The value can be one of the following:

- Certify

- Reject

- Decline

- Delegate

Submit Attestation

Click this button to submit the attestation request.

Save

Click this button to save the attestation request for future submission.

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.

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 Request Process Flow"

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:

- Request Stages

- Bulk Requests and Child Requests

- Request Models

- Creating Requests for Self and Others

- Searching for Requests

- Withdrawing a Request

- Performing Request-Related Tasks by Using the Task List

- Closing Requests

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 Request Stages

Description of "Figure 10-2 Request Stages"

Note:

If a request is not submitted successfully, then the error messages are displayed in the UI. For SPML-initiated requests, the error messages are thrown to SPML.

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 Stage

Description

Created

After successful submission of the request, the request moves to the Created stage.

Obtaining Approval

After the request is created, the 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:

- Parent requests: A request submitted with multiple beneficiaries, multiple target entities, or both is a parent request

- Child requests: When the request level approval happens for a parent request, multiple child requests are created. The parent request is divided into multiple child requests containing one beneficiary and one target entity, or both.

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:

Figure 10-3 Bulk Request and Child Request Stages

Description of "Figure 10-3 Bulk Request and Child Request Stages"

See Also:

- Table 17-1, "Default Request Templates" for information about the request models that support bulk request

- Table 10-1, "Request Stages" for information about request stages

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.

Table 10-2 Default Operations and Request Models

Catalog

Request Model

Bulk

Self or Admin

Beneficiary

User Management

Create User

N

Admin

N

Self-Register User

N

Self

N

Modify Self Profile

N

Self

N

Modify User Profile

Y

Admin

N

Enable User

Y

Admin

N

Disable User

Y

Admin

N

Delete User

Y

Admin

N

Provisioning

Provision Resource

Y

Admin

Y

Self-Request Resource

Y

Self

Y

Modify Provisioned Resource

Y

Admin

Y

Enable Provisioned Resource

Y

Admin

Y

Disable Provisioned Resource

Y

Admin

Y

De-Provision Resource

Y

Admin

Y

Self Modify Provisioned Resource

N

Self

Y

Self De-Provision Resource

Y

Self

Y

Role Management

Create Role

N

Admin

N

Delete Role

Y

Admin

N

Modify Role

N

Admin

Y

Assign Roles

Y

Admin

Y

Remove from Roles

Y

Admin

Y

Self-Assign Role

Y

Self

Y

Self-Remove Role

Y

Self

Y

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:

- Name of the model

- Whether or not a target entity is required:

- The requests in which a resource is provisioned to a user have a beneficiary. An example of this type of request is a request to create an entity and a relationship between a user or organization with that entity. Specifically the relationship is a 'has a' relation.

- Requests such as creating a user require creation of an entity, but they do not necessarily have a "has a' relation with any other entity.

- The beneficiary type that is being addressed, which is user.

- The entity-type that the model is associated with and whether or not the entity is a generic one.

- A generic entity type is a parent entity type for which the creation of entities is not possible unless a specific subtype is selected. For example Resource is a generic entity, where E-mail and Laptop are subtypes.

- If the entity type can be created without defining subtypes, then it is not a generic entity, such as user.

- Whether or not the model is a creation model. A creation model results in the creation of an entity. It creates an entity and its relation with a user or organization. A non-creation model requires a target entity to be selected.

- Reference to data collection. A model contains an implicit connection to an XML element to determine the data that needs to be collected. For a generic entity, the final reference is constructed by using the entity subtype selected at runtime, which allows the collection of different data for different entity subtypes.

- Approval workflow selection. A model may contain a reference to the algorithm(s) that are used to select the approval process to be associated for a request. The parameters to be passed to the algorithm are also mentioned.

- Whether or not the model supports an operation that is to be performed in bulk mode.

- Whether or not authentication is required. If true, then a model is available to all authenticated users creating requests. If false, then it is only available through unauthenticated self service, and not available in the authenticated self service.

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:

- Creating a Request to Register Yourself in Oracle Identity Manager

- Creating a Request from Oracle Identity Manager Self Service

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:

- Creating a Request From Welcome Page of Oracle Identity Manager Self Service

- Creating a Request From the My Requests Page

- Creating a Request From the My Profile Page

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:

Table 10-3 Columns in the Table Showing Request Information

Column

Description

Request Type

The type of the request or the operation to be performed by raising the request

Request ID

A unique ID to identify the request

Status

A descriptive indication of the state the request is currently in

Date Requested

Date and time when the request was raised

Requester

The user or the system component that created and submitted the request

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.4.2.3 Creating a Request From the My Profile Page

You can create requests from the My Profile page in Oracle Identity Manager Self Service. The following request types are allowed:

- Requesting roles: See "Requesting Roles" for details.

- Removing roles: See "Removing Roles" for details.

- Requesting a resource: See "Requesting a Resource" for details.

- Modifying a resource: See "Modifying a Resource" for details.

10.5 Searching for Requests

Using Oracle Identity Manager Self Service, various roles perform request searching and tracking:

- Request Search as a Requester

- Request Search as a Beneficiary

- Request Searching by Approver

- Request Search by Unauthenticated User

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:

Figure 10-4 The Request Details Tab

Description of "Figure 10-4 The Request Details Tab"

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:

- Requested Roles/Requested Resources/Users

- Request Comments

- Request History

- Approval Tasks

- Child Requests

10.5.1.1 Requested Roles/Requested Resources/Users

The Requested Roles tab is displayed only for the requests that are associated with role management request types. If the request type is associated with provisioning, then the Requested Resources tab is displayed. If the request type is associated with user management, then the Users tab is displayed.

The Requested Roles tab shows the beneficiary and the role display name. For a bulk request, the table in this tab displays all the beneficiary and role names corresponding to each beneficiary, as shown in Figure 10-5:

Figure 10-5 The Requested Roles Tab

Description of "Figure 10-5 The Requested Roles Tab"

When you open the request details of a Create User or Provision Resource request type, the Users tab or the Requested Resources tab respectively displays a View Details link. Figure 10-6 shows the View Details link in the Users tab:

Figure 10-6 The Users Tab

Description of "Figure 10-6 The Users Tab"

When you click the View Details link, a window is displayed with the user or resource details, as shown in Figure 10-7:

Figure 10-7 The User Details Window

Description of "Figure 10-7 The User Details Window"

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.3 Request History

This tab displays the request history, which consists of various changes the request has been through in the process of execution. Request history shows or tracks only the status changes to an request. The table in this tab shows the status of the request, the date on which the request is updated, and the user who updated the request, as shown in Figure 10-8:

Figure 10-8 The Request History Tab

Description of "Figure 10-8 The Request History Tab"

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.2 Request Search as a Beneficiary

To view the requests for which you are a beneficiary:

1. Log in to Oracle Identity Manager Self Service.

2. Click Requests. The My Requests page is displayed.

3. From the Show list, select Requests Raised For Me. The requests raised for you are displayed in a table as shown in Figure 10-9:

Figure 10-9 Requests Raised For You

Description of "Figure 10-9 Requests Raised For You"

4. Select a request to display detailed information about the request in the Request Details tab.

In the My Requests page, you cannot perform any action on the requests as a beneficiary.

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.

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

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.

Part III

Identity Administration

This part describes Oracle Identity Manager delegated administration functionalities by using the identity administration features.

It contains the following chapters:

- Chapter 11, "Managing Users"

- Chapter 12, "Managing Roles"

- Chapter 13, "Managing Organizations"

- Chapter 14, "Creating and Searching Requests"

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:

- User Lifecycle

- User Entity Definition

- User Management Tasks

- User Management Authorization

- Username Reservation

- Common Name Generation

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:

Figure 11-1 User Life Cycle

Description of "Figure 11-1 User Life Cycle"

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 State

Operation

Sample Scenario

Process 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:

- OIM Account

- Organization

- Role

11.1.1 OIM Account

OIM Account is an abstraction representing a means to be authenticated to access Oracle Identity Manager. In Oracle Identity Manager, the cardinality of relationship between user and OIM account is one-to-one. By default, users are associated with OIM accounts that allows users to access Oracle Identity Manager. However, there may be users who do not need to access Oracle Identity Manager, and therefore, may not be provisioned with an OIM account.

Some user operations, such as lock and unlock, are explicitly account operations. When locking or unlocking a user, you lock or unlock the user's OIM account.

In Oracle Identity Manager, each user has a Design Console Access attribute that controls the OIM account of the user. If the Design Console Access option for a user is selected in the UI, then the user is End-User Administrator. If this option is not selected, then the user is an End-User.

11.1.2 Organization

Organization is a logical container for authorization and permission data. A user in Oracle Identity Manager must belong to one organization only. For detailed information about organizations in Oracle Identity Manager, see Chapter 13, "Managing Organizations".

11.1.3 Role

Oracle Identity Manager provides easy and controlled privilege management through roles. Roles are named groups of related privileges that you grant to users or other roles. Roles are designed to ease the administration of end-user system and schema object privileges. For detailed information about roles, see Chapter 12, "Managing Roles".

11.2 User Entity Definition

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

For each attribute of an entity, the following properties are defined in Oracle Identity Manager:

- Attribute Name: The name of the attribute.

- Category: All entity attributes are classified into a category. This categorization is used to organize the data in the UI. The category is only for display on the UI and is not used anywhere else. The default categories are:

- Basic User Information: This category contains basic user attributes such as user first name, user last name, e-mail, manager, organization, and user type.

- Account Settings: This category contains account-related attributes such as user login, identity status, account status, and global unique identifier (GUID).

- Account Effective Dates: This category contains account start and end date attributes.

- Provisioning Dates: This category contains provisioning date and deprovisioning date attributes.

- Lifecycle : This category shows flags related to User Account such as manually locked, locked on, or automatically delete on.
All the attributes in the category are hidden by default so the category is also not visible.

- System: This category contains the system controlled attributes for the user entity such as created on, password expiration date, password reset attempts, and so on.

- Other User Attributes: This category contains a list of all the FA and LDAP related attributes.

- CustomAttributes: This is an empty category where the user can add all the new custom attributes.

- Preferences: This category contains the attributes related to user preferences. It contains various attributes such as locale, timezone, currency, date format, and so on.

- Type: Indicates the type of data in the attribute. Supported types are string, number, date, and Boolean.

- Properties: For each attribute, the following properties can be defined:

- required: Determines whether or not every user in the repository must have a non-null value for this attribute

- system-controlled: Determines if the value can only be set and edited by the system itself

- system-can-default: Determines if the value can be set by the system to a default if no value is provided

- encryption: Determines if the value stored in the repository is encrypted. If true, then the value is encrypted but this encrypted value can be decrypted producing the original value. If false, then the value is stored as CLEAR, meaning that the stored value is not encrypted.

- user-searchable: Determines if the values can be used in searches

- bulk-updatable: Determines if the field can be modified as part of a bulk modification of multiple users. Fields that are expected to be unique to users, such as username, name fields, and password, do not support bulk update. For fields with system-controled=Yes or Unique=Yes, this property can never be set to Yes. For information about setting the properties of an attribute, see "Configuring User Attributes" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

- display-type: Determines how the field is displayed in the UI for creating and modifying users. It can have any one of the following values:
TEXT, TEXTAREA, NUMBER, DOUBLE, CHECKBOX, DATE_ONLY, SECRET, LOV, and ENTITY.

- multi-valued: Determines whether the attribute is multi-valued or not. The value of this property is either true or false. Oracle Identity Manager does not support multiple values, and therefore, this property is set to false for all user attributes.

- max-size: Indicates the maximum allowed length for the specified attribute.

- read-only: Indicates if the attribute has "read-only" permission only or if it is editable.

- custom: Determines if the attribute is a default attribute or a user-defined attribute.

- visible: Determines if the attribute is visible to the user.

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

Table 11-2 Attributes Defined for User Entity

Attribute Name

Category

Description

Data Type

Properties

LOV (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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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: No

Multi-represented: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

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

User-Searchable: No

Bulk-Updatable: 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

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

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

User-Searchable: No

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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: 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

User-Searchable: Yes

Bulk-Updatable: No

Read-Only: No

Max-Size: 256

Visible: Yes

Display-Type: TEXT

N/A

FA Language

Preferences

Language of the user for LDAP environment.

string

Required: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: Yes

Read-Only: No

Max-Size: 100

Visible: No

Display-Type: TEXT

NA

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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: 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

User-Searchable: No

Bulk-Updatable: No

Read-Only: No

Max-Size: 20

Visible: No

Display-Type: LOV

Lookup.Users.AccessibilityMode

screenReader

inaccessible

default

FA Territory

Preferences

Region of the user for LDAP environment.

string

Required: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

Read-Only: No

Max-Size: 100

Visible: No

Display-Type: LOV

NA

User Name Preferred Language

Preferences

The preference language of the user used to show only 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

User-Searchable: Yes

Bulk-Updatable: 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:

- Searching Users

- Creating Users

- Viewing and Modifying User Information

11.3.1 Searching Users

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

- Simple Search

- Advanced Search

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:

- Searchable Attributes

- Search Comparators

- Search String

- Conjunction Operator

- Search Results

- Operations on Search Results

- Performing a Simple Search

11.3.1.1.1 Searchable Attributes

The default set of attributes across which search is conducted are:

- User Login

- First Name

- Last Name

- Display Name

11.3.1.1.2 Search Comparators

The search comparator for the search operation is set to Begins With. The search comparator can be combined with wildcard characters to specify a search condition. The asterisk (*) character is used as a wildcard character.

11.3.1.1.3 Search String

Search string is not case-sensitive. Only the asterisk (*) character is supported as a wildcard for the search string. Oracle Identity Manager Administration removes any leading or trailing white spaces from the search string. For performance reasons, any leading occurrences of (*) in the search string are removed.

11.3.1.1.4 Conjunction Operator

The conjunction operator for the search operation is by default set to be OR.

The relationships between the search attributes, search comparator, search string, and conjunction operator is described by using the following query composition formula:

Query begins with ((attribute 1 begins with 'search string') or (attribute 2 begins with 'search string') or …)

For example, if you enter Jo* as a search text, then the search operation forms an internal query where User Login begins with Jo* or First Name begins with Jo* or Last Name begins with Jo* or Display Name begins with Jo*. As a result, all the users whose user name, first name, or last name starts with Jo are displayed.

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.1.6 Operations on Search Results

This section describes the operations that you can perform based on selection of row(s) in the search results table. It is divided into single selection operations and bulk or multiple selection operations.

You can perform the following single selection operations by selecting a user from the search results table:

- View detail

- Modify, only if the user status is active

- Enable, only if the user status is disabled

- Disable, only if the user status is enabled

- Lock, only if the selected user's account is unlocked

- Unlock, only if the selected user's account is locked

- Reset password

- Delete

You can perform the following bulk or multiple selection operations by selecting multiple users from the search results table:

- Enable, only if the user status is disabled

- Disable, only if the user status is enabled

- Lock, only if the selected user's account is unlocked

- Unlock, only if the selected user's account is locked

- Delete

11.3.1.1.7 Performing a Simple Search

To perform a simple search and display the details of the user:

1. Login to Oracle Identity Manager Administration.

2. To search users, in the left pane, select Users from the drop-down list.

3. In the search field, enter a search criterion. You can include wildcard characters (*) in your search criterion.

4. Click the icon to the right of the search field. The search result is displayed in the left pane that shows the display names of the users that matches the search criterion you specified.

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:

- Advanced Search Page

- Search Comparators

- Conjunction Operator

- Searchable Attributes

- Search Results

- Performing an Advanced Search Operation

11.3.1.2.1 Advanced Search Page

You specify the search criteria in the Advanced Search page. This page lets you create a search query that consists of multiple criteria. Each criterion consists of:

- The attribute to search against

- The search comparator, such as equals and begins with

- The values to search for

The value can be multiple in the case where the comparator requires two or more values. You can specify multiple search criteria if the comparator requires two or more values, for example, range searches on numeric fields or data ranges on date fields. When you specify multiple search criteria, you must specify the AND or OR conjunction operator for the search operation.

11.3.1.2.2 Search Comparators

The search comparators that the Advanced Search page supports are predefined in Oracle Identity Manager. Each comparator specifies the kind of attribute (data type) it supports, and also the number of input data fields it requires.

Table 11-3 lists the comparators supported by advanced search:

Table 11-3 Advanced Search Comparators

Comparator

Field Types Supported

Equals

Text, Date, Numeric, Boolean

Begins With

Text

11.3.1.2.3 Conjunction Operator

The conjunction operators for the search operation are:

- All: Search is performed with the AND condition. This means that the search operation is successful only when all the search criteria specified are matched.

- Any: Search is performed with the OR condition. This means that the search operation is successful when any search criterion specified is matched.

11.3.1.2.4 Searchable Attributes

Searchable attributes define the set of attributes that you can use in the Advanced Search page. While creating the search criteria, you can select the attributes that you want to search against from this base list.

Only a subset of the searchable attributes, called default fields in Table 11-4, is displayed by default in the Advanced Search page. You can add additional searchable attributes to the page by using the Add Fields functionality. Each attribute also specifies the comparators it supports.

Table 11-4 Default Search Attributes

Attribute

Comparators Available

Default Fields

Display Name

Begins With, Equals

Yes

User Login

Begins With, Equals

Yes

First Name

Begins With, Equals

Yes

Last Name

Begins With, Equals

Yes

Identity Status

Equals, Not Equals

Yes

Organization

Equals, Begins With

Yes

Email

Begins With, Equals

Yes

Start Date

Equal, Before, After, Range

Yes

End Date

Equals, Before, After, Range

Yes

Note:

You can configure the attributes that are searchable in User Management Configuration.

The searchable attributes configured for advanced search must be a subset of the attributes defined for the User Entity that are marked with the Searchable = Yes property.

11.3.1.2.5 Search Results

The search results table is displayed in the same tab as the Advanced Search page so that the user can view the query they searched by along with the search results. The table, being in the right pane, is always displayed as the full search results table.

If your search returns a lot of information, you can hide one or more columns in the search results table. For example, if your table contains 20 columns, you might want to display only the eight most-important columns, so you do not have to keep scrolling through the less important information.

To hide one or more columns, open the Search Results pane, click View, and deselect the columns you want to hide. A status message displays along the bottom of all search tables to identify how many columns are currently hidden in a particular table view. Figure 11-2 shows that the user has hidden three columns.

Figure 11-2 Advanced Search Result with Hidden Columns

The search results does not return deleted users, unless the user explicitly selects the Status attribute in the Advanced Search page and provides a value, Status Equals Deleted. In that case, deleted users will be returned as part of the search results.

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.

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

Section

Field

Description

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:

- User Details Page

- User Modifications

- Single User Operations

- Bulk User Modifications

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:

- The Attributes Tab

- The Roles Tab

- The Resources Tab

- The Proxies Tab

- Direct Reports

- The Requests Tab

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.2 The Roles Tab

This tab displays a list of roles to which the user belongs. You can click each role to display summary information about the role. For each role in the list, it displays the following:

- Display Name: The name displayed on the UI.

- Role Name: Name of the role assigned to a user.

- Role Namespace: Namespace to which the role is assigned.

- Description: A description of the role.

In the Roles tab, you can assign roles to the user and remove roles from the user. For more details, see "Adding and Removing Roles".

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.4 The Proxies Tab

This tab displays all proxies that are currently set up for the user. For each proxy in the list, it displays the following:

- Proxy Name: The display name of the proxy user

- Start Date: The start date for the proxy user

- End Date: The end date for the proxy user

- Status: The status of the proxy user

- Relationship: The relationship of the proxy user with the open user, such as manager

- Last Updated: The date when the proxy user was last updated

This section also displays the history of proxy information for the user in which the end date is shown. The Current Proxies display the current proxies for the user. The Past Proxies display the proxies history for the user. The Status column is not displayed in the Past Proxies table.

If you select a row in the table that displays proxies information, then a summary information about the proxy is displayed where you can edit the proxy name, relationship with the user, start date, and end date.

The Proxies tab allows you to add proxies to the user and to remove proxies from the user. For information about adding and removing proxies, see "Modifying Proxy Details".

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:

- Modifying Attribute Profile

- Adding and Removing Roles

- Adding and Removing Resources

- Enabling and Disabling Resources

- Displaying Resource Details

- Displaying Resource History

- Modifying Proxy Details

11.3.3.2.1 Modifying Attribute Profile

The attribute profile information is displayed in the Attributes tab of the user details page. To modify the attribute profile, edit the fields in the Attributes tab, and click Apply.

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

Figure 11-3 Sample Process Data

Description of "Figure 11-3 Sample Process Data"

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.2.4 Enabling and Disabling Resources

A resource can be enabled if the status of the selected resource is Disabled or Provisioned. To enable a resource:

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

2. From the Action menu, select Enable. A confirmation message is displayed.

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

A resource can be disabled if the status of the selected resource is Enabled. To disable a resource:

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

2. From the Action menu, select Disable. A confirmation message is displayed.

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

11.3.3.2.5 Displaying Resource Details

To display resource details:

1. In the Resources tab, select a resource whose details you want to display.

2. From the Action menu, select Open. A page is displayed with the resource details. You can edit resource details in this page. When finished, click Save.

11.3.3.2.6 Displaying Resource History

To display resource history:

1. In the Resources tab, select a resource whose history you want to display.

2. From the Action menu, select Resource History. A page is displayed with the provisioning details of the resource. The details include task name, task details, date assigned, and the user to whom the task is assigned. A retry checbox is also displayed. You must enable this to retry all failed tasks.

11.3.3.2.7 Modifying Proxy Details

The Proxies tab allows you to add a proxy and select one or multiple proxies in the list, and then invoke the following operations:

- Edit a proxy, only if a single user is selected

- Remove a proxy

To add a proxy:

1. In the Proxies tab, from the Action menu, select Add. The Add Proxy dialog box is displayed.

2. In the Proxy Name field, select an appropriate proxy. Your proxy can be any user. Search for proxy user's name from the search field below the Proxy Name field or select Manager to add your manager as a proxy.

3. Specify a start date and end date for the proxy to operate on your behalf.

4. Click OK. A message is displayed asking for confirmation.

5. Click OK. A confirmation message is displayed stating that the proxy is assigned.

To remove a proxy, select the proxy in the Proxies tab, and click Remove Proxy.

To modify proxy details:

1. Select a row in the table displaying proxy information. The details of the proxy are displayed at the bottom of the tab.

2. Edit the fields to modify proxy information.

3. Click Save.

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:

- Enabling a User

- Disabling a User

- Locking a User

- Unlocking a User

- Resetting the Password for a User

- Deleting User

11.3.3.3.1 Enabling a User

This operation is available only if the user status is Disabled. To enable 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 Enable User. Alternatively, you can click the Enable User icon on the toolbar. If the user details page for the user is open, then you can click Enable User on the toolbar. A message box is displayed asking for confirmation.

3. Click OK to confirm. A confirmation message is displayed stating that the user is enabled.
If you enable a user from the user detail page, then it's 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.

11.3.3.3.2 Disabling a User

This operation is available only if the user status is Enabled. To disable 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 Disable User. Alternatively, you can click the Disable User icon on the toolbar. If the user details page for the user is open, then you can click Disable User on the toolbar. A message box is displayed asking for confirmation.

3. Click OK to confirm. A confirmation message is displayed stating that the user is disabled.
If you disable a user from the user detail page, then it's 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.

11.3.3.3.3 Locking a User

This operation is available only if the user account is unlocked. To lock 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 Lock Account. Alternatively, you can click the Lock Account icon on the toolbar. If the user details page for the user is open, then you can click Lock Account on the toolbar. A message is displayed asking for confirmation.

3. Click OK. A confirmation message is displayed stating that the user is successfully locked.
If you lock an account from the user detail page, then it's 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.

11.3.3.3.4 Unlocking a User

This operation is available only if the user account is locked. To unlock as 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 Unlock Account. Alternatively, you can click the Unlock Account icon on the toolbar. If the user details page for the user is open, then you can click Unlock Account on the toolbar. A message is displayed asking for confirmation.

3. Click OK. A confirmation message is displayed stating that the user is successfully unlocked.
If you unlock an account from the user detail page, then it's successful completion refreshes the Attributes tab. If you perform this operation from a user list, such as simple or advanced search result, then the corresponding row in the list is refreshed.

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-4:

Figure 11-4 The Reset Password Dialog Box

Description of "Figure 11-4 The Reset Password Dialog Box"

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 the Oracle Identity Manager Design Console. See "Configuring Challenge Questions for the User" 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:

Table 11-6 Fields in the Bulk Modify Page

Section

Field

Description

Basic User Information

Design Console Access

Design Console Access check box that indicates whether or not the users can login to the Design Console.

Manager

The reporting manager of the selected users.

Organization

The organization to which the selected users belong.

User Type

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

Account Effective Dates

Start Date

The date when the selected users will be activated in the system.

End Date

The date when the selected users will be deactivated in the system.

Provisioning Dates

Provisioning Date

The date when the users are provisioned.

Deprovisioning Date

The date when the users are provisioned.

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:

- Privileges

- Attributes

- Data Constraints

- Authorization with Multiple Policies

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

Privilege

Description

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:

- Search Operation Authorization with Multiple Authorization Policies

- Modify Operation Authorization with Multiple Authorization Policies

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 Name

Entity Name

Permissions

Data Constraints

Assignment

Policy1

User management

Search

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) = TRUE

Role: Role1

Management Chain of User = FALSE

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

Policy2

User management

Search

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) = FALSE

Role: Role2

Management Chain of User = FALSE

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

Policy3

User management

Search

Modify User Profile. Attribute includes Designation

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

All Users

Role: 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.4.4.2 Modify Operation Authorization with Multiple Authorization Policies

If the logged in user is allowed to modify a user profile as defined by multiple policies, then a union of the set of attributes from individual policies is used for performing the operation. Refer to Scenario II of the "Search Operation Authorization with Multiple Authorization Policies" for the example related to the modify operation in case of multiple applicable authorization policies.

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:

- The USER ATTRIBUTE RESERVATION ENABLED system property must be set to TRUE for the functionality to be enabled. For information about searching and modifying system properties, see "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

- Reservation in LDAP is done only if reservation functionality is enabled, and LDAP is in sync with Oracle Identity Manager database. For information about synchronization between Oracle identity Manager and LDAP identity store, see ""Integration Between LDAP Identity Store and Oracle Identity Manager".

Note:

- If LDAP provider is not configured, then the reservation is done only in Oracle Identity Manager.

- When LDAP synchronization and user attribute reservation features are enabled, it is recommended to enable UID uniqueness in the directory server. Without this, user reservation in the directory does not work properly because while the user is reserved in the reservation container, the user with the same user ID can be created in the user container. This results is user creation failure when Oracle Identity Manager tries to move the user from the reservation container to the user container.

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:

- Enabling and Disabling Username Reservation

- Configuring the Username Policy

- Releasing the Username

- Configuring Username Generation to Support Microsoft Active Directory

11.5.1 Enabling and Disabling Username Reservation

The username reservation functionality is enabled by default in Oracle Identity Manager. This is done by keeping the value of the USER ATTRIBUTE RESERVATION ENABLED system property to TRUE. You can verify the value of this system property in the System Configuration section of Oracle Identity Manager Administration.

To disable username reservation:

1. Log in to the Administrative and User Console.

2. Click Advanced Administration.

3. Click System Management.

4. Click System Configuration.

5. On the left pane, click the search icon to search for all existing system properties. A list of system properties are displayed in the search results table.

6. Click User Attribute Reservation Enabled. The System Property Detail page for the selected system property is displayed, as shown in Figure 11-5:

Figure 11-5 The System Property Detail Page

Description of "Figure 11-5 The System Property Detail Page"

7. In the Value field, enter False.

8. Click Save. The username reservation functionality is disabled.

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 Name

Expected Information

Username Generated

oracle.iam.identity.usermgmt.impl.plugins.EmailIdPolicy

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:

- For user name generation and validation, public APIs are exposed in UserManager.

- While creating the policy, ensure that the attributes used in generating the username are defined in the request data set. For information about request data set, see "Request Dataset" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

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:

Table 11-9 Constants Representing Policy IDs

Policy Name

Constant

EmailIDPolicy

EMAIL_ID_POLICY

LastNameFirstInitialLocalePolicy

FIRSTNAME_LASTNAME_POLICY

FirstInitialLastNameLocalePolicy

LASTNAME_FIRSTNAME_POLICY

LastNameFirstInitialPolicy

FIRSTINITIAL_LASTNAME_POLICY

FirstInitialLastNamePolicy

LASTNAME_FIRSTINITIAL_POLICY

LastNameFirstNamePolicy

FIRSTINITIAL_LASTNAME_LOCALE_POLICY

FirstNameLastNamePolicy

LASTNAME_FIRSTINITIAL_LOCALE_POLICY

DefaultComboPolicy

DEFAULT_COMBO_POLICY

LastNamePolicy

LASTNAME_POLICY

LastNameLocalePolicy

LASTNAME_LOCALE_POLICY

FirstNameLastNamePolicyForAD

FIRSTNAME_LASTNAME_POLICY_FOR_AD

LastNameFirstNamePolicyForAD

LASTNAME_FIRSTNAME_POLICY_FOR_AD

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-6:

Figure 11-6 The Default Username Policy Configuration

Description of "Figure 11-6 The Default Username Policy Configuration"

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.3 Releasing the Username

The username is released in the following scenarios:

- When the request is approved, and the user is successfully created in Oracle Identity Manager and provisioned to LDAP, and the username from the reserved table is removed. The reserved username is removed after successful user creation after the approvals. The reserved entry in LDAP is removed and the actual user is created.

- If the request is rejected, then the reserved entry of username in LDAP and Oracle Identity Manager are removed.

- If the request fails while or before creating a user in Oracle Identity Manager or LDAP, then the reserved username is deleted.

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:

- Common Name Generation for Create User Operation

- Common Name Generation for Modify User Operation

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:

Table 11-10 RDN Modification Scenarios

Referential Integrity in LDAP

XL.IsReferentialIntegrityEnabled

Result of Modify Operation (modrdn)

Disabled

FALSE

Oracle Identity Manager generates an error and operation fails.

Disabled

TRUE

Modify operation passes from Oracle Identity Manager and RDN is changed in LDAP. However, the group references are not updated and are stale. This configuration is not recommended.

Enabled

FALSE

Oracle Identity Manager generates an error and modify operation fails. This property must be set to TRUE in Oracle Identity Manager because referential integrity is enabled in LDAP.

Enabled

TRUE

Modify operation passes and RDN is updated. In addition, the references for the DN are updated in LDAP.

Multiple directories with roles and users stored in separate directories.

Referential integrity property is not relevant here.

FALSE

Modify operation fails from Oracle Identity Manager. This is not supported by LDAP. Therefore, FALSE is the recommended value in Oracle Identity Manager for the property.

Multiple directories with roles and users stored in separate directories.

Referential integrity property is not relevant here.

TRUE

Modify operation passes and RDN is modified. However, because LDAP does not support referential integrity in multiple directories, the group references are stale and must be manually updated.

12 Managing Roles

As an administrator, you use roles to create and manage the records of a collection of users to whom you want to permit access to common functionality, such as access rights, roles, or permissions.

Roles can be independent of an organization, span multiple organizations, or contain users from a single organization.

Using roles, you can:

- View the menu items that the users can access through Oracle Identity Manager Administration Web interface.

- Assign users to roles.

- Assign a role to a parent role

- Designate status to the users so that they can specify defined responses for process tasks.

- Modify permissions on data objects.

- Designate provisioning policies for a role. These policies determine if a resource object is to be provisioned to or requested for a member of the role.

- Assign or remove membership rules to or from the role. These rules determine which users can be assigned or removed as direct membership to or from the role.

- Map users (via roles) to access policies for automating the provisioning of target systems to the users. See Chapter 16, "Managing Access Policies" for details.

This chapter describes roles and functionalities related to roles in the following sections:

- Role Membership Inheritance

- Role Permission Inheritance

- Role Entity Definition

- Default Roles

- Role Management Tasks

- Managing Authorization for Roles

- Request-Based Role Grants

12.1 Role Membership Inheritance

Membership inheritance means that the members of the inheritor role inherit from the inherited role. For example:

Note:

The child role that inherits membership from its parent role is called the inheritor role. The parent role from which the inheritor role inherits membership is called the inherited role.

- Role B inherits memberships from Role A. Role B is parent role to Role A.

- Role C also inherits memberships from Role A. Role C is also parent role of Role A.

In this example, all members of Role A are also implicit or indirect members of Role B and Role C, but members of Role B are not automatically members of Role A. In other words, Role B and Role C are the parents of Role A. Similarly, Role A is the child of Role B and Role C. A real example for this is that the Employee Role (Role B) inherits memberships from the Manager Role (Role A).

Role membership inheritance is described with the help of the following scenario:

- The role CEO is a parent role of the Manager role.

- The role Manager is a parent role of the Employee role.

- The role Software Architect is a parent role of the Software Engineer role.

- The role Software Engineer is a parent role of the Employee role.

- The Employee role has two parent roles - the Manager role and the SoftwareEngineer role.

Figure 12-1 shows the parent and child roles in this example, along with the membership inheritance:

Figure 12-1 Role Membership and Permission Inheritance

Description of "Figure 12-1 Role Membership and Permission Inheritance"

Each user in a parent role automatically becomes a member in any of its child roles. If that child role is itself a parent, then the user is also added to its child roles, and so on. This continues until there are no more child roles. For example, a CEO is a manager and is automatically a member of the Manager role. Similarly, a manager is automatically an employee. This is why a member added to a parent role gets inherited by its children roles, and so on. This explains why the direct membership of the Employee role is empty, and considering membership inheritance, the Employee role has more members than all other roles.

12.2 Role Permission Inheritance

Permission inheritance means that the permissions of the inheritor role inherit from the inherited role. For example:

- Role B inherits permissions from Role A.

- Role C also inherits permissions from Role A.

In this example, Role B and Role C are the children of Role A. Similarly, Role A is also the parent of Role B and Role C.

A real example for this is that the Manager role inherits permissions from the Employee role.

The Administrative and User Console represents role permission inheritance through the following sections in the Hierarchy tab:

See Also:

"The Hierarchy Tab" for more information about the Hierarchy tab

- Inherited From: Displays the parent roles from which the open role is inherited. The base role has the same permissions and privileges on the members as the inherited roles. Only inherited roles can be added or removed from the base role, but the base role cannot be added or removed from the inherited role.

- Inherited By: Lists the child roles that are inherited by the open role. This is a read-only display of the roles. You can use the Open Role action to modify the relationship from the base role.

For example, you create three roles: role1, role2, and role3. Open role3 and assign role2 as the parent role. Similarly, open role2 and assign role1 as the parent role. When you open role3, the Inherited From section displays the role2 parent role, and role1 is displayed under role2. When you open role1, the Inherited By section displays the role2 child role, and role3 is displayed under role2.

A user can be a member of a role in one of the following ways:

- The member has been inherited from the parent role, which is called indirect membership.

- The user is directly assigned to the role, which is called direct membership.

- The user can be assigned directly via request in the role details page by setting the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties, which is also called direct membership. See "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about system properties.

An indirect member can be assigned as direct member. If the direct membership for a user is removed, then all membership for that role does not change because that user is still a member of that because of inheritance.

Figure 12-1 illustrates that a permission on Employee is a permission that a Manager will have. Similarly, a permission a Manager will have is a permission a CEO will have. And this is why permissions inherit upwards. In addition, a parent role can inherit permissions from multiple child roles. For example, a CEO inherits the permissions of the Manager and Software Architect roles. Therefore, membership inheritance and permission inheritance go in different directions.

12.3 Role Entity Definition

Attributes are defined for the role entity in Oracle Identity Manager. These attributes are the same for all entities, such as user, organization, role, role hierarchy, and role membership. For a list of attributes defined for the entities, see "User Entity Definition".

Note:

You cannot add your own attributes for the role entity.

This section describes the default attribute definition of the following entities:

- Role Entity

- Role Category Entity

- Role Grant Relationship

- Role Parent Relationship

12.3.1 Role Entity

The Role.xml file contains the attribute definition for the role entity. You cannot add your own attributes to the role entity.

Table 12-1 lists the default attributes for the role entity.

Table 12-1 Default Attributes for the Role Entity

Attribute Name

Category

Type

Data Type

Properties

LOV

Key

Basic

Single

Numeric

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Unique Name

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User- searchable: No

Bulk-Updatable: No

NA

Role Display Name

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Namespace

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Name

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Description

Basic

Single

Text (multi-language)

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

LDAP GUID

LDAP

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

LDAP DN

LDAP

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Key

Basic

Single

Reference to role category

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: Yes

NA

Role Owner Key

Basic

Single

Reference to Role Owner

Required: Yes

System-Can-Default: Yes

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: Yes

NA

Role Email

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

12.3.2 Role Category Entity

The RoleCategory.xml file contains the attribute definition for the role category entity. You cannot add your own attributes to the role category entity.

Table 12-2 lists the default attributes for the role category entity.

Table 12-2 Default Attributes for the Role Category Entity

Attribute Name

Category

Type

Data Type

Properties

LOV

Role Category Key

Basic

Single

Text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Name

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Role Category Description

Basic

Single

Text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

12.3.3 Role Grant Relationship

The RoleRoleRelationship.xml file contains the attribute definition for role grant relationship. You cannot add your own attributes for the role grant relationship.

Table 12-3 lists the default attributes for role grant relationship.

Table 12-3 Default Attributes for Role Grant Relationship

Attribute Name

Category

Type

Data Type

Properties

LOV

UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

USR_KEY

Basic

Single

Reference to user

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

12.3.4 Role Parent Relationship

The RoleUserMembership.xml file contains the attribute definitions for role parent relationship. You cannot add your own attributes to the role parent relationship.

Table 12-4 lists the default attributes for the role parent relationship.

Table 12-4 Default Attributes for Role Parent Relationship

Attribute Name

Category

Type

Data Type

Properties

LOV

UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

GPG_UGP_KEY

Basic

Single

Reference to role

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Bulk-Updatable: No

NA

Note:

UGP_KEY is a reference to the parent role. GPG_UGP_KEY is a reference to the child role.

12.4 Default Roles

Table 12-5 lists the default roles in Oracle Identity Manager:

Table 12-5 Default Roles in Oracle Identity Manager

Role

Description

USER CONFIGURATION ADMINISTRATORS

Members of this role have access to the UI to perform various tasks to create and manage entity attributes for user management.

SYSTEM CONFIGURATION ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks related to system configuration, such as system properties, scheduled jobs, and notification templates.

SYSTEM ADMINISTRATORS

Members of this role have full permission to create, edit, and delete records in Oracle Identity Manager, except for system records. These users can control the permissions of other users, change the status of process tasks even when the task is not assigned to them, and administer the system from the highest level.

USER NAME ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI.

SPML_App_Role

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to submit requests via the SPML interfaces.

SOD ADMINISTRATORS

Members of this role can claim a SoD check task and approve it. Default approval tasks are assigned to this role.

SELF OPERATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. It contains one user, XELSELFREG, who is responsible for modifying the privileges that users have when performing self-registration actions within Oracle Identity Manager.

Note: Oracle Identity Manager recommends that you do not modify the permissions associated with the SELF OPERATORS user role. In addition, you should not assign any users to this role.

SCHEDULER ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. The user with this role can perform all scheduler jobs administration.

ROLE ADMINISTRATORS

Members of this role have access to the UI to administer and manage roles in Oracle Identity Manager.

RESOURCE ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to manage resources.

REQUEST TEMPLATE ADMINISTRATORS

The user with this role can perform all request template administration.

REQUEST ADMINISTRATORS

Members of this role have access to the UI to perform various tasks to create and manage requests.

REPORT ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to manage reports in BI Publisher.

RECONCILIATION ADMINISTRATORS

The user with this role can perform reconciliation administration.

PLUGIN ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Member of this role have permissions to register and unregister plugins to Oracle Identity Manager.

OPERATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the pages related to organizations, users, and Task List. These users can perform a subset of functions on these pages.

NOTIFICATION TEMPLATE ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to create and manage notification templates.

IT RESOURCE ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to create and manage IT resources.

IDENTITY USER ADMINISTRATORS

Members of this role have access to the UI to perform various tasks to create and manage users in Oracle Identity Manager.

IDENTITY ORGANIZATION ADMINISTRATORS

Members of this role have access to the UI to perform various tasks to create and manage organizations in Oracle Identity Manager.

GENERIC CONNECTOR ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to configure generic connectors.

DEPLOYMENT MANAGER ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the Deployment Manager to import and export deployment configurations from an Oracle Identity Manager deployment to another.

Administrators

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. It is the administrators role for SOA.

ATTESTATION EVENT ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to manage attestation events.

ATTESTATION CONFIGURATION ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to configure attestation.

APPROVAL POLICY ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role have access to the UI to perform various tasks to create and manage approval policies.

ALL USERS

Members of this role have minimal permissions, including the ability to access the user's own user record. By default, each user belongs to the All Users role.

ACCESS POLICY ADMINISTRATORS

This role is for internal use only, meaning it is for OIM users and other users can only view it on UI. Members of this role can access the UI to perform various tasks to manage access policies.

You can modify the permissions associated with the default roles. You can also create additional roles. However, you cannot assign/remove menu items to/from any roles.

12.5 Role Management Tasks

This section discusses the following topics:

- Creating Roles

- Managing Roles

- Creating and Managing Role Categories

Note:

- A user cannot be removed from the All Users role.

- A role, SELF OPERATORS, is added to Oracle Identity Manager by default. This role contains one user, XELSELFREG, who is responsible for modifying user permissions for performing self-registration in the Administration Console.
Oracle recommends that you do not modify the permissions associated with the SELF OPERATORS role and do not assign users to this role.

12.5.1 Creating Roles

When you first create a new role, the Role Details page shows the role name. You can add information to a role by using the Additional Detail menu as described in "Managing Roles".

To create a role:

1. Login to Oracle Identity Administration.

2. In the Welcome page, under Roles, click Create Role.
Alternatively, in the Browse tab of the left pane, expand Roles, and from the Actions menu, select Create Role. Otherwise, click the Create Role icon on the toolbar.

The Create Role page is displayed.

3. Enter values in the fields. Table 12-6 lists the fields in the Create Role page.

Table 12-6 Fields in the Create Role Page

Field

Description

Role Name

The name of the role

Display Name

The role name as displayed in the UI

Email

The e-mail ID of the role

Description

The description for the role

Role Category Name

The category to which the role belongs

If a role category is not specified in this field, then the role is created in the Default category. See "Creating and Managing Role Categories" for information about role categories.

Owned By

The owner of the role

The role owner is a user who has permissions to view, modify, and delete the role without having to create custom authorization policies. See "Managing Authorization for Roles" for information about authorization policies for role management.

Note that Manage Localizations is displayed with the Display Name fields because these are multi-language fields. This means that you can enter and save attribute values in more than one language.

4. Click Save. The role is created successfully and role name, role namespace, LDAP Attributes such as LDAP GUID and LDAP DN are displayed in a new page.

12.5.2 Managing Roles

You can find roles, add information to them, and perform other administrative functions for roles.

This section discusses the following topics:

- Browsing Roles

- Searching for Roles

- Deleting Roles

- Viewing and Administering Roles

- Viewing Menu Items

- Viewing, Assigning, and Revoking Access Policies

- Viewing, Assigning, and Revoking Membership Rules

- Updating Data Object Permissions

12.5.2.1 Browsing Roles

You can browse the roles that exist in Oracle Identity Manager in the Roles tab. To browse roles:

1. In the left pane of Oracle Identity Administration, click the Browse tab.

2. Expand OIM Roles. The role categories are displayed. For more information about role categories, see "Creating and Managing Role Categories".

In the Browse tab, you can perform various tasks related to roles and role categories. For details, see "Viewing and Administering Roles".

12.5.2.2 Searching for Roles

Oracle Identity Management Administration allows you to perform the following types of search operations for roles:

- Performing Simple Search for Roles

- Performing Advanced Search for Roles

12.5.2.2.1 Performing Simple Search for Roles

To perform a simple search for roles:

1. In the left pane of Oracle Identity Administration, under Search, select Roles.

2. Specify a search criterion in the field next to the list. You can include wildcard characters (*) in your search criterion. For performance reasons, initial (prefix) wildcards will be removed. However, a trailing (prefix) wildcard will be added to all searches.

Note:

"*" is the only wildcard search allowed in Oracle Identity Management Administration.

3. Click the search icon to the right of the field. A list of roles that match the search criterion is displayed in the Search Results tab.
In the Search Results tab, you can edit and delete roles. For details, see "Viewing and Administering Roles" and "Deleting Roles".

12.5.2.2.2 Performing Advanced Search for Roles

To perform an advanced search for roles:

1. In the Welcome page, under Roles, click Advanced Search - Roles.
Alternatively, in the Browse tab for roles in the left pane, you can click the Advanced Search: Roles icon on the toolbar.

The Advanced Search: Roles page is displayed.

2. Select any one of the following options:

- All: On selecting this option, the search is performed with the AND condition. This means that the search operation is successful only 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 operation is successful when any search criterion specified is matched.

3. In the Name field, enter the role name that you want to search. You can use wildcard characters in your search criteria. Select a search comparator in the list adjacent to the Name field. The default search comparator is "Begins With". The comparator "Equals" is available in the pulldown list as an alternative.

4. Similarly, enter search criteria in all the other fields. You can add fields to the Advanced Search: Roles page. To do so, click Add Fields, and then select the field name from the list.

5. Click Search. The roles that match your search criteria are displayed in the search results table.

Note:

Clicking Search without any value returns all roles.

6. Click View and select Columns to view additional columns in the search results.

7. Click View and Reorder Columns to reorder the columns in the search results.

From the search results in the Advanced Search: Roles page, you can create new roles, edit roles, and delete roles. For details, see "Creating Roles", "Viewing and Administering Roles", and "Deleting Roles".

12.5.2.3 Deleting Roles

To delete a role:

1. Search for a role as described in "Searching for Roles". Alternatively, you can click the Browse tab for roles in the left pane.

2. Select the role that you want to delete.

3. From the Actions list, select Delete.
Alternatively, you can click the delete icon on the toolbar. A message box is displayed asking for confirmation.

4. Click OK to confirm.

Note:

You are not allowed to delete a role, which is the parent/child of some other role. To delete such a role, you must first remove the associated parent-child role relationships. Once the role is no longer involved in any role relationships, it can be deleted.

12.5.2.4 Viewing and Administering Roles

You can open the details of a role and edit the role attributes, and modify the role inheritance and membership. To open the details of a role and modify it, perform one of the following:

- In the role browse tree, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click the Open Role or Category Detail icon on the toolbar.

- In the Search Results tab of the left pane, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click the Open Role Detail icon on the toolbar.

- In the Advanced Search: Roles page, select the role that you want to open. From the Actions menu, select Open. Alternatively, you can click Open Role on the toolbar.

The details of the role is displayed in a page. The role display name is displayed at the top of the page. You can display the details of the role and modify role information in the following tabs of this page:

- The Attributes Tab

- The Hierarchy Tab

- The Members Tab

12.5.2.4.1 The Attributes Tab

The Attributes tab displays the role attributes in the following sections:

- Basic Role Information: This section displays the basic attributes of the role such as role name, role namespace, display name, e-mail, and description.

- Other Information: This section displays the information about the category to which the role belongs and the owner of the role.

- Custom Attributes: This section displays information about the user-defined fields (UDFs).

- LDAP Attributes: This section displays information about LDAP GUID and LDAP DN if Oracle Identity Manager is integrated with LDAP. These are read-only attributes.

The fields in the Attributes tab are same as available in the Create Role page. For information about all the fields in the Attributes tab, see Table 12-6, "Fields in the Create Role Page".

12.5.2.4.2 The Hierarchy Tab

The Hierarchy tab displays the role hierarchy information in the following sections:

- Inherited From: This section displays the parent roles from which the open role is inherited. The base role has the same permissions and privileges on the members as the inherited roles. Only inherited roles can be added or removed from the base role, but the base role cannot be added or removed from the inherited role.

- Inherited By: This section lists the child roles that are inherited by the open role. This is a read-only display of the roles. You can use the Open Role action to modify the relationship from the base role.

In the Hierarchy tab. you can perform the following:

- Adding a Parent Role to a Child Role

- Removing a Parent Role from a Role

- Opening a Parent/Child Role

12.5.2.4.3 Adding a Parent Role to a Child Role

To add a parent role to a role:

1. Open the role.

2. Click the Hierarchy tab.

3. Verify that the Inherited From section is active.

4. From the Actions menu, select Add Parent Role. Alternatively, click Add Parent Role on the toolbar. The Add Inherited Role to: dialog box is displayed.

5. From the Search Roles list, select a role category whose roles you want to search.

6. In the search field, specify a search criterion. You can include wildcard characters (*) in your search criterion. Then, click the search icon. A list of roles that matches your search criterion and selected role category is displayed in the Available Roles list.

Note:

"*" is the only wildcard search allowed in Oracle Identity Management Administration.

7. From the Available Roles list, select one or more roles that you want to add as parent roles. Then, click Move or Move All to move the selected roles to the Roles to Add list.

8. Click Save. The selected roles are added as parent roles to the opened role and the role hierarchy is displayed in the Inherited From section of the Hierarchy tab.

9. Select the inherited role that is added. A Summary Information of the role selected is displayed below the table.

12.5.2.4.4 Removing a Parent Role from a Role

To remove a parent role from a role:

1. In the Inherited From section of the Hierarchy tab, select the role that you want to remove.

2. From the Actions menu, select Remove Parent Role. Alternatively, click Remove Parent Role on the toolbar. A message box is displayed asking for confirmation.

3. Click OK. The inherited role is removed from the Inherited From section of the Hierarchy tab.

12.5.2.4.5 Opening a Parent/Child Role

You can open parent roles from the "Inherited From" section and child roles from the "Inherited By" section of the Hierarchy tab.

You can also open the roles that are linked parent and child roles (like grand parents and grand child roles) of the current opened role with the "Open Role" link in "Inherited From" and "Inherited By" section of the Hierarchy tab respectively.

To open a parent role:

1. In the Inherited From section of the Hierarchy tab, select the role that you want to open.

2. From the Actions menu, select Open (Open Role Detail). Alternatively, click Open (Open Role Detail) on the toolbar. A page with details about the inherited role is displayed. In this page, you can view and edit the role attributes, and modify the role inheritance and membership, assign and remove membership rules, access policies and permissions, update permissions and also to view the menu items assigned.

To open a child role:

1. In the Inherited From or Inherited By section of the Hierarchy tab, select the role that you want to open.

2. From the Actions menu, select Open (Open Role Detail). Alternatively, click Open (Open Role Detail) on the toolbar. A page with details about the inherited role is displayed.

12.5.2.4.6 The Members Tab

The Members tab displays the members assigned to the open role. This information is displayed in the following sections:

- All Members: This section displays all the members, direct and indirect, assigned to the open role.

- Direct Members: This section displays the members that are directly assigned to the open role. It also displays all members that are assigned via membership rules.

- Indirect Members: This section displays the members that are indirectly inherited by the role.

In the Members tab, you can perform the following:

- Assigning Members to a Role

- Revoking Members from a Role

- Opening Member Details

12.5.2.4.7 Assigning Members to a Role

To assign members to a role:

1. In any section of the Members tab, from the Actions menu, select Assign (Assign Users). Alternatively, click Assign User to on the toolbar. The Assign User to: dialog box is displayed.

2. Search for users by specifying a search criterion in the Search Users field and clicking the search icon. The list of users that matches your search criterion is displayed in the Available list.

Note:

An indirect member can be assigned as a direct member.

3. Select one or more users that you want to assign to the open role. Then, click Move or Move All to move the selected users to the Selected list.

4. Click Save. If the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties are set, then after clicking Save, a confirmation message is displayed in the role details page along with the request ID. Otherwise, only a confirmation message is displayed.
If a request is created, then the users are displayed as members in the Direct Members section only after the request is approved. Otherwise, the users are displayed as members immediately in the Direct Members section. Also, note that the users are displayed in the All Members section.

Tip:

- If the member users are not displayed in the Members tab immediately after they are added, then refresh the view.

- If users are created or updated to match membership rules criteria, then they are assigned directly to this role and the table must be refreshed to view those members in both sections, All Members and Direct Members.

12.5.2.4.8 Revoking Members from a Role

To revoke members from a role:

1. In any section of the Members tab, select the member that you want to revoke.

2. From the Actions menu, select Revoke (Revoke Members). Alternatively, click Revoke Members from: on the toolbar. The Revoke User from: dialog box is displayed.

3. Search for members by specifying a search criterion in the Search Users field and clicking the search icon. The list of members that matches your search criterion is displayed in the Available list.

Note:

Only direct members can be revoked except for the members that are assigned via membership rules.

4. Select one or more members that you want to revoke from the open role. Then, click Move or Move All to move the selected members to the Selected list.

5. Click Save. A confirmation message is displayed on the role details page.

6. The members that you have revoked are removed from the list of members in the Members tab.

12.5.2.4.9 Opening Member Details

To open the member user details of the open role:

1. In any section of the Members tab, select the member whose details you want to open.

2. From the Actions menu, select Open (Open Member Detail). Alternatively, click Open User on the toolbar. The user details page for the member is displayed that allows you to view and modify the member details.

12.5.2.5 Viewing Menu Items

You can display all menu items that are permitted for the role. In11g Release 1 (11.1.1), new menu items cannot be assigned to any role. By default, menu items are already assigned to some default roles in Oracle Identity Manager.

Note:

The existing menu items cannot be revoked.

To display the menu items for a role:

1. In the browse tree for roles on the left pane, select a role for which you want to display the permitted menu items.

2. From the Actions menu, select Menu Items. The Role Details >> Menu Items page is displayed with a list of menu items permitted for the selected role.

12.5.2.6 Viewing, Assigning, and Revoking Access Policies

You can display all available access policies for this role and assign and revoke access policies for the role.

To assign access policies to a role:

1. In the browse tree for roles on the left pane, select the role for which you want to assign access policy.

2. From the Actions menu or Role Details page select Access Policies. The Access Policies page is displayed.

3. To assign a new access policy, click Assign Policy. The Assign Access Policies page is displayed.
This page displays the policy name and brief description of the policy.

4. Select the Assign option for the access policies that you want to assign to this role, and then click Assign. The Confirmation page is displayed.

5. To assign the access policy, click Confirm Assign. The Access Policies page is displayed.

6. To remove this access policy, select the Delete option for the access policies that you want to remove from this role, and then click Delete. In the confirmation page, Click Confirm Delete to remove access policies from this role

12.5.2.7 Viewing, Assigning, and Revoking Membership Rules

You can display all available membership rules for this role, assign a new membership rule for the role, and remove membership rules.

To work with membership rules:

1. In the browse tree for roles, select the role for which you want to assign or revoke membership rules.

2. From the Actions menu, select Membership Rules. The Membership Rules page is displayed.

3. To assign a new membership rule, click Assign Rules. The Assign Membership Rules page is displayed. This page displays the name of the membership rule.

4. Select the Assign option for the membership rules that you want to assign to this role, and then click Assign. The Confirmation page is displayed.

5. To assign the membership rule, click Confirm Assign. Otherwise, click Cancel. The Membership Rules page is displayed.

6. To revoke this membership rule, select the Delete option for the membership rule that you want to remove from this role, and then click Delete. In the confirmation page click Conform Delete to remove the rules from this role.

12.5.2.8 Updating Data Object Permissions

Most permissions in Oracle Identity Manager concern data objects. You can define data objects as an internal object representation of tables in Oracle Identity Manager data model. In this model, the business logic is executed and responsible for inserting, updating, and deleting data from the data store. Permissions for these actions are defined at a role level. Depending on the table or data objects, these permissions can be categorized into the following:

- Explicit Insert/Update/Delete Permission Required

- Explicit Permission Not Required

12.5.2.8.1 Explicit Insert/Update/Delete Permission Required

Data objects for which explicit insert, update, or delete permission is required are the ones for which you must specify the insert, update, or delete permission by using Permissions from the Role Details page in Oracle Identity Manager Administrative and User Console to create, modify, and delete entities of these data objects.

Consider the following example: A user belongs to multiple roles and a data object is assigned to both of these roles. Suppose you want to delete an entity of this data object type. To be able to do so, you must ensure that both roles have update permission on the data object.

A user belongs to the Request Template Administrators and Request Administrators roles, and a data object is assigned to both of these roles. Suppose you want to delete an entity of this data object type. To be able to do so, you must ensure that both the Request Template Administrators and Request Administrators roles have update permission on the data object.

Table 12-7 lists the data objects listed in this category and the entities of these data objects.

Table 12-7 Data Objects Requiring Explicit Insert/Update/Delete Permissions

Data Object Type

Entities

com.thortech.xl.dataobj.tcACS

Organization.Lnk_Act_Svr

com.thortech.xl.dataobj.tcADL

Adapter Factory Logic/SetVariable tasks

com.thortech.xl.dataobj.tcADM

Adapter Factory Input/output parameters

com.thortech.xl.dataobj.tcADP

Adapter Definitions

com.thortech.xl.dataobj.tcADS

Adapter Factory Stored Procedure tasks

com.thortech.xl.dataobj.tcADT

Adapter Tasks

com.thortech.xl.dataobj.tcADU

Adapter Factory WebServices tasks

com.thortech.xl.dataobj.tcADV

Adapter Factory Variables

com.thortech.xl.dataobj.tcAPA

Attestation Process Administrators

com.thortech.xl.dataobj.tcARS

Adapter Statuses

com.thortech.xl.dataobj.tcATP

Adapter Factory Parameter Task Table

com.thortech.xl.dataobj.tcDAV

Data Object Adapter Variable

com.thortech.xl.dataobj.tcDVT

Event handlers associated with data objects

com.thortech.xl.dataobj.tcEMD

Email Definitions

com.thortech.xl.dataobj.tcERR

Error Message Definitions

com.thortech.xl.dataobj.tcEVT

Event Handlers

com.thortech.xl.dataobj.tcGPY

role Properties

com.thortech.xl.dataobj.tcLKU

Lookup Definitions

com.thortech.xl.dataobj.tcLKV

Lookup values for a lookup

com.thortech.xl.dataobj.tcOBA

Resource object authorizers

com.thortech.xl.dataobj.tcODF

Object To Process Data Flow

com.thortech.xl.dataobj.tcODV

Resource object Events

com.thortech.xl.dataobj.tcOOD

Resource Objects Organization Object Dependencies

com.thortech.xl.dataobj.tcOUD

Resource Objects User Object Dependencies

com.thortech.xl.dataobj.tcPDF

Process Integration Data Flow Mappings

com.thortech.xl.dataobj.tcPKH

Package Hierarchy

com.thortech.xl.dataobj.tcPOC

Access Policies Child Table Data

com.thortech.xl.dataobj.tcPOF

Policy parent data

com.thortech.xl.dataobj.tcPOG

roles defined on access policy

com.thortech.xl.dataobj.tcPOL

Access policy definition

com.thortech.xl.dataobj.tcPOP

Assigned Objects on access policies

com.thortech.xl.dataobj.tcPRF

Process Reconciliation Field Mappings

com.thortech.xl.dataobj.tcPTY

System Configuration

com.thortech.xl.dataobj.tcPWP

Policy Process Targets

com.thortech.xl.dataobj.tcPWR

Password Policies

com.thortech.xl.dataobj.tcPWT

Policy User Targets

com.thortech.xl.dataobj.tcRAV

Prepopulate Adapter Mappings

com.thortech.xl.dataobj.tcRCA

Reconciliation Matched Organizations

com.thortech.xl.dataobj.tcRCH

Reconciliation Event Action History

com.thortech.xl.dataobj.tcRCP

Reconciliation Event Processes Matched

com.thortech.xl.dataobj.tcRCU

Reconciliation Event Users Matched

com.thortech.xl.dataobj.tcRCX

Reconciliation Exceptions

com.thortech.xl.dataobj.tcRES

Adapter Factory Resources

com.thortech.xl.dataobj.tcRGP

Role Membership Rules

com.thortech.xl.dataobj.tcRML

Task Assignment Rules

com.thortech.xl.dataobj.tcRPG

Reports on roles

com.thortech.xl.dataobj.tcRUL

Rules

com.thortech.xl.dataobj.tcRUE

Rule Element

com.thortech.xl.dataobj.tcSDC

User defined columns on system user-defined forms

com.thortech.xl.dataobj.tcSDH

Parent child hierarchy of user defined forms

com.thortech.xl.dataobj.tcSDL

Form Definition Version Label

com.thortech.xl.dataobj.tcSDP

Form Definition Properties

com.thortech.xl.dataobj.tcSPD

IT Resources Type Parameter Definition

com.thortech.xl.dataobj.tcSRE

Association between user defined columns and pre-populate adapters

com.thortech.xl.dataobj.tcSRS

IT Resource Link

com.thortech.xl.dataobj.tcSUG

IT Resources Administrators

com.thortech.xl.dataobj.tcSVD

IT Resources Type Definition

com.thortech.xl.dataobj.tcTDV

Process Event Handlers

com.thortech.xl.dataobj.tcTLG

System Log

com.thortech.xl.dataobj.tcTSA

Schedule Task Attributes

com.thortech.xl.dataobj.tcTSK

Scheduled Tasks

com.thortech.xl.dataobj.tcUHD

Users Objects History Details

com.thortech.xl.dataobj.tcUPL

User Defined Field Lookups

com.thortech.xl.dataobj.tcUPT

User Defined Field Values

com.thortech.xl.dataobj.tcUPY

System Configuration Users

com.thortech.xl.dataobj.tcWIN

Form Information

12.5.2.8.2 Explicit Permission Not Required

Data objects for which explicit permission is not required are the ones for which permissions do not need to be defined because either there are no permissions enforced or they simply follow parent data object permissions. Data objects that use parent data object permissions follow a simple paradigm that if a role has update permissions on a parent data object, the same role will have insert, update, and delete permissions on child data objects.

Explicit permissions are required only for the objects mentioned in Table 12-7, "Data Objects Requiring Explicit Insert/Update/Delete Permissions". The rest of the data objects either have derived or implicit permissions.

While assigning data objects or fine-grained permissions to roles, Oracle Identity Manager uses the following permission model:

- To modify an insert data permission, a user who is logged in must have the insert and update permissions.

- To modify an update data permission, a user who is logged in must have the update permissions.

- To modify a delete data permission, a user who is logged in must have the insert, update, and delete permissions.

12.5.3 Creating and Managing Role Categories

Role categories are a way of categorizing roles for the purpose of navigation and authorization. Role categories are internally stored in Oracle Identity Manager as an attribute of the role and is reconciled with the multivalued business category attribute in the LDAP identity store. If the value in LDAP is empty, then the role is assigned to the system-managed Uncategorized role category. If the value in LDAP has multiple values or a single, unrecognized value, then the role reconciliation process does not reconcile the role and generates reconciliation errors in Oracle Identity Manager.

The default role categories in Oracle Identity Manager are:

- OIM Roles: All the predefined roles in Oracle Identity Manager are assigned to this category. These are roles that exist in Oracle Identity Manager by default and are primarily used for managing permissions. There will not be any corresponding entity in LDAP store for these predefined roles

- Default: A newly created role must have a role category. Therefore, if a role category is not specified at the time of creating the role, then the role is assigned to this category by default.

This section describes the following topics:

- Creating a Role Category

- Searching Role Categories

- Modifying a Role Category

- Deleting a Role Category

12.5.3.1 Creating a Role Category

To create a role category:

1. Login to Oracle Identity Administration.

2. In the Welcome page, under Roles, click Create Role Category.
Alternatively, in the Browse tab of the left pane, expand Roles, and from the Actions menu, select Create Category. Otherwise, click Create Category icon on the toolbar.

The Create Role Category page is displayed.

3. In the Category Name box, enter the name of the role category.

4. In the Description box, enter a description for the role category. This step is optional.

5. Click Save. A page is displayed with a message on the top of the page stating that the role category is created. The page consists of the Attributes and Roles tabs.
The Attributes tab displays the attributes of the role category. You can edit the fields in this tab to edit the role category.

The Roles tab displays the list of roles belonging to the role category.

12.5.3.2 Searching Role Categories

To search for role categories:

1. In the Welcome page, under Roles, click Advanced Search - Role Categories. The Advanced Search: Categories page is displayed.

2. In the Category Name field, enter a search criterion. You can enter the asterix wildcard character (*) in the search criterion.

3. From the list adjacent to the Category Name field, select a search comparator. The default search comparator is Begins With. However, Equals search comparator can be used.

4. If you want to add a field to the search condition, then click Add Fields. From the list, select Description. The Description field is added to the Advanced Search: Categories page. You can specify a search criterion in the Description field to search by description.
To remove the Description field from the search condition, click the cross icon adjacent to the Description field.

5. Click Search. The categories that match search criteria you specified are displayed in the search results table.

12.5.3.3 Modifying a Role Category

To modify a role category:

1. In the Browse tab of the left pane, expand Roles.

2. Select the role category that you want to modify.

3. From the Actions menu, select Open. Alternatively, click the Open Role or Category Detail icon on the toolbar. A page with details about the role category is displayed.

4. The Attributes tab is open by default. Edit the fields in this tab to modify basic category information such as name and description. When finished, click Apply.

5. Click the Roles tab. In this tab, you can view all roles that are assigned to this category.
To view role details assigned to a role category:

1. In the Roles tab of the role category details page, select the role that you want to view details.

2. From the Actions menu, select Open (Open Role Detail). Alternatively, you can click Open (Open Role Detail) on the toolbar. The Role Detail page for the selected role is displayed.

12.5.3.4 Deleting a Role Category

To delete a role category:

1. In the browse tree for roles in the left pane, select a role category that you want to delete.

2. From the Actions menu, select Delete. Alternatively, click the Delete icon on the toolbar. If the role category detail page is open, then click Delete Role Category on the toolbar. A message box is displayed asking for confirmation.

3. Click Yes. The role category is deleted.

12.6 Managing Authorization for Roles

When a user logs in to Oracle Identity Manager, the links, buttons, and menus associated with the actions that the user can perform are displayed. For example, on the Welcome page of Oracle Identity Manager Administration, the Advanced Search - Roles link is displayed if the user is authorized to perform advanced search for roles. The actions that the user is authorized to perform is determined by the authorization policies. These authorization policies are defined for Oracle Identity Manager and stored in Oracle Entitlements Server (OES). The policies are enforced at runtime to control the authorization to perform various tasks in the UI.

See Also:

Chapter 15, "Managing Authorization Policies" for detailed information about authorization policies

Authorization policies control the access to various operations with the help of permissions. Table 12-8 lists the permissions for role management operations:

Table 12-8 Role Management Permissions

Permission

Description

Create Role

Determines if the user can create a role

Note: This permission is not associated with a specific role.

Modify Role Detail

Determines if the user can update a specific role

Delete Role

Determines if the user can delete a specific role

View Role Detail

Determines if the user can view a specific role and the complete hierarchy of the specific role

Search for Role

Determines if the user can search for roles

Note: This permission is not associated with a specific role.

Modify Role Membership

Determines if the user can grant or revoke a specific role to a user.

Modify Role Hierarchy

Determines if the user can add or remove a child role to or from a specific role

View Role Membership

Determines the user to whom the specific role is granted

Create Role Category

Determines is the user can create a role category

Note: This permission is not associated with a specific role category or role.

Modify Role Category

Determines if the user can update a role category

Note: This permission is not associated with a specific role category or role.

Delete Role Category

Determines if the user can delete a role category

Note: This permission is not associated with a specific role category or role.

View Role Category Detail

Determines if the user can view the details of a role category

Note: This permission is not associated with a specific role category or role.

Search for Role Categories

Determines if the user can search for role categories

Note: This permission is not associated with a specific role category or role.

Note:

When a role is granted to a user, the Modify Role Membership permission must be granted to the specific role that you are trying to grant.

Permissions are enforced by authorization policies, which regulate the way permissions are granted. The default authorization policies for the role management feature allow Oracle Identity Manager to function properly. Without these policies, you cannot access or perform any task in Oracle Identity Manager. This applies to the administrators and users.

You can create custom authorization policies to enforce delegated administration by using the Authorization Policy tab of Oracle Identity Administration. The following must be specified while creating an authorization policy:

- Policy name and description

- Oracle Identity Manager feature for which the policy is being created

- Set of permissions associated with various actions

- Assignment of policy to roles decides who gets the permissions via the role membership

- Data constraint, which is a set of roles on which the actions specified in the policy can be performed. Hierarchy is supported in the data constraints. Therefore, all roles that are part of the hierarchy are included in the data constraint. This allows you to create a simple policy with only few roles listed in the constraint, but that includes a much bigger set of roles based on the hierarchy.

See Also:

- "Role Management" for information about the default authorization policies for this feature

- "Creating an Authorization Policy for Role Management" for information about creating custom authorization policies for role management

12.7 Request-Based Role Grants

You can configure Oracle Identity Manager to generate a request when a role grant is performed. This request is subject to approval, and therefore, the role grant takes place only when the role grant request has been approved. In addition, if Segregation of Duties (SoD) check for role grants is enabled, then you must also configure request-based role grants. However, request-based role grant can be enabled without enabling SoD check for role grants.

See Also:

"Using Segregation of Duties (SoD)" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about SoD

To configure request-based role grants, you must set the values of the XL.RM_REQUEST_ENABLED and XL.RM_ROLE_ASSIGN_TEMPLATE system properties. For a description of these system properties and possible values, see "System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

If the XL.RM_REQUEST_ENABLED system property is not present or no legal value has been specified for this property, then role grants are performed without any request being generated. If XL.RM_REQUEST_ENABLED is true, and XL.RM_ROLE_ASSIGN_TEMPLATE has not been set or has an illegal value, then an error message is displayed, no role grant is performed, and a role request is not generated.

After a role grant request is generated, the request ID is displayed in the Administrative and User Console. This is for tracking the request in the Self Service or Advanced Administration.

Role grant requests have the following details:

- Request ID: Automatically generated

- Request Type: Based on the request template

- Request Status: Assigned

- Date Requested: Current timestamp

- Effective Date: Current timestamp

- Requester: Null

- Beneficiary: Null

- Justification: Null

13 Managing Organizations

An organization entity represents a logical container of entities such as users and other organizations in Oracle Identity Manager.

Organizations are containers that can be used for delegated administrative models. In addition, an organization defines the scope of other Oracle Identity Manager entities, such as users. Oracle Identity Manager can have a flat organization structure or a hierarchical structure, which means that an organization can contain other organizations. The hierarchy represents departments, geographical areas, or other logical divisions facilitating management of Oracle Identity Manager entities.

To scale the ability to manage a large number of roles and people in an organization of a significant size by using delegated administration, Oracle Identity Manager provides the ability to define delegated administration policies based on the membership of an object within a hierarchy. This also supports recursive organization membership, such as the hierarchy shown in Figure 13-1:

Figure 13-1 Recursive Organization Membership

Description of "Figure 13-1 Recursive Organization Membership"

If a hierarchical delegated administration policy is defined to provide Delegated Administrator1 the permission to reset password starting from Engineering, then the permission is granted for Employee1, Employee2, Employee3, and Employee4. If the membership root is Development, then Bob has the permission for Employee2 and Employee3 only.

The functional description of the organization services and the UI components that support these services are described in the following sections:

- Organization Entity Definition

- Organization Management Tasks

- Organization Management Authorization

13.1 Organization Entity Definition

In Oracle Identity Manager, attributes are defined by default for the organization entity. These attributes are the same for all entities, such as user, organization, role, role hierarchy, and role membership. For a list of attributes defined for the entities, see "User Entity Definition".

Table 13-1 lists the default attributes of the organization entity:

Table 13-1 Default Attributes of the Organization Entity

Attribute Name

Category

Type

Data Type

Display Type

Properties

Organization Name

Basic

Single

String

Single line text

Required: Yes

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Type

Basic

Single

String

LOV

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

Parent Organization

Basic

Single

String

Single line text

Required: No

System-Can-Default: No

System-Controlled: No

Encryption: Clear

User-Searchable: Yes

Status

Basic

Single

String

Single line text

Required: Yes

System-Can-Default: Yes

System-Controlled: Yes

Encryption: Clear

User-Searchable: Yes

13.2 Organization Management Tasks

The tasks related to organization management are performed in the Organization Management section of Oracle Identity Management Administration. The tasks are described in the following sections:

- Searching Organizations

- Browsing Organizations

- Creating an Organization

- Viewing and Modifying Organizations

- Disabling and Enabling Organizations

- Deleting an Organization

13.2.1 Searching Organizations

Oracle Identity Administration allows you to perform the following types of organization search operations:

- Performing Simple Search

- Performing Advanced Search

Note:

The organizations that are displayed in the search result when you search for organizations, is controlled by the XL.EnableOrgPermissionCheck system property. See "System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about this system property.

13.2.1.1 Performing Simple Search

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

To perform a simple search for organizations:

1. Login to Oracle Identity Administration.

2. In the Administration tab on the left pane, from the drop-down list, select Organizations.

3. In the Search field, enter an organization name as a search criterion. You can include wildcard characters (*) in your search criterion. For performance reasons, initial (prefix) wildcards will be removed. However, a trailing (prefix) wildcard will be added to all searches.

4. Click the search icon. In the Search Results tab, the search result is displayed in a table that shows the organization names that matched the search criterion. Figure 13-2 shows the search results table:

Figure 13-2 Organization Search Result

Description of "Figure 13-2 Organization Search Result"

13.2.1.2 Performing Advanced Search

Advanced search for organizations allows you to specify more complex search criteria than the simple search operation. The results are displayed in search results table.

To perform advanced search for organizations:

1. Login to Oracle Identity Administration.

2. In the Welcome page, under Organizations, click Advanced Search - Organizations. The Advanced Search page is displayed on the right pane.

3. Select any one of the following:

- All: Search is performed with the AND condition. This means that the search operation is successful only when all the search criteria specified are matched.

- Any: Search is performed with the OR condition. This means that the search operation is successful when any search criterion specified is matched.

4. In the Organization Name field, enter the organization name search attribute that you want to search. To do so, select a search comparator. The default search comparator is "Begins With". The comparator "Equals" is available in the pulldown list as an alternative. See "Search Comparators" for more information about search comparators.
You can use wildcard characters to specify the organization name.

5. From the Organization Customer Type list, select the organization type. The organization type can be Branch, Department, or Company.

6. From the Add Fields button, select Organization Status.

7. From the Organization Status list, select the organization status, which can be Active, Deleted, or Disabled.

8. Click Search. The results are displayed in the search results table, as shown in Figure 13-3. The search results table displays the organization name, parent organization, organization customer type, and organization status.

Figure 13-3 Advanced Search

Description of "Figure 13-3 Advanced Search"

13.2.2 Browsing Organizations

You can browse data in the Organizations section in Oracle Identity Manager Administration. The browse functionality is available in the left pane of the UI.

Using the browse operation, you can navigate through the organization tree in the system, starting at the root organization. If there are multiple organization trees, then all the trees are displayed. Each tree starts at a root organization node, which has no parent organization. The users defined in the organization are not displayed as nodes in the tree.

To browse through organizations, in the left pane of Oracle Identity Manager Administration, under the Browse tab, click Organization. All the organizations in Oracle Identity Manager are displayed in the browse list, as shown in Figure 13-4:

Figure 13-4 Organization Browse List

Description of "Figure 13-4 Organization Browse List"

The organization browse list shows the organizations trees with the root and child organizations.

In the organization browse list, you can perform the following:

- Create an organization. See "Creating an Organization".

- Open the details of an organization. See "Viewing and Modifying Organizations".

- Delete an organization. See "Deleting an Organization".

- Manage administrative roles: See "Managing Administrative Roles".

13.2.3 Creating an Organization

You create an organization by using the Create Organization page. You can access this page only if you are authorized to create an organization.

Note:

You are allowed to create an organization only if you have the Create Organization privilege for one or more organizations.

To create an organization:

1. Open the Create Organization page. To do so, perform any one of the following:

- In the Welcome page of Oracle Identity Manager Administration, under Organizations, click Create New Organization.

- In the left pane, click the Browse tab. Under Organizations, from the Action menu, select Create. You can also click the Create icon on the toolbar.

- In the left pane, click the Search Results tab with Organizations selected in the search list. From the Actions menu, select Create. You can also click the Create icon on the toolbar.

- In the Advanced Search: Organization page, from the Actions menu, select Create Org, or click Create on the toolbar.

Figure 13-5 shows the Create Organization page.

Figure 13-5 The Create Organization Page

Description of "Figure 13-5 The Create Organization Page"

2. Enter values in the fields in the Create Organization page. Table 13-2 lists the fields in the Create Organization page:

Table 13-2 Fields in the Create Organization Page

Field

Description

Name

The name of the organization

Type

The type of the organization, either Company, Department, or Branch

Parent Organization

The organization to which the newly created organization will belong

3. In the Name field, enter the name of the organization.

4. In the Type field, select the type of the organization, such as Company, Department, or Branch.

5. Specify the parent organization to which the newly created organization will belong. To do so:

1. Click the search icon next to the Parent Organization field. The Search: Organizations dialog box is displayed, as shown in Figure 13-6:

Figure 13-6 The Search: Organizations Dialog Box

Description of "Figure 13-6 The Search: Organizations Dialog Box"

2. Select any one of the following options:

- All: On selecting this option, the search is performed with the AND condition. This means that the search operation is successful only 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 operation is successful when any search criterion specified is matched.

3. In the Organization Name field, enter the organization name that you want to search. You can use wildcard characters in your search criteria. Select a search condition in the list adjacent to the Organization Name field. The search conditions include "Equals" or "Begins With".

4. In the Organization Customer Type field, enter the organization type of the parent organization. You can use wildcard characters in your search criteria. Select a search condition in the list adjacent to the Organization Customer Type field.

5. Click Search. The organizations that match the search criteria you specified are displayed in the search results table.

6. From the search results table, select the organization that you want to specify as the parent organization.

7. Click Finish. The selected organization is added as the parent organization.

6. Click Save to create the organization.

13.2.4 Viewing and Modifying Organizations

The view organization operation allows you to view detailed organization profile information in the User Details page. You can view this page only if you are authorized to view the organization profile as determined by the authorization policy on the View Organization Detail privilege. If you have the authorization to modify the organization, then you can also modify the organization by using this page.

Note:

The organization details page for the organization entity is auto-generated by the system based on configuration and fine-grained authorization. In Oracle Identity Manager, there is no mechanism to override the system-generated page with a custom-defined page.

To open the details of an organization, perform any one of the following:

- In the left pane of Oracle Identity Manager Administration, click the Browse tab. Under Organization, select the organization whose details you want to display. From the Actions menu, select Open. Alternatively, click the Open icon on the toolbar.

- Perform a simple search for the organization whose details you want to display. From the search result, select the organization. From the Actions menu, select Open. Alternatively, click the Open icon on the toolbar.

- Perform an advanced search for the organization whose details you want to display. From the advanced search result, select the organization, and from the Actions menu, select Update Org. Alternatively, click Open on the toolbar.

The organization details page is displayed, as shown in Figure 13-7:

Figure 13-7 The Organization Details Page

Description of "Figure 13-7 The Organization Details Page"

You can perform administrative organization modifications in the organization details page. The modification is divided across the different sections of the organization details page, which means that modifications done in each section are independent of each other and must be saved individually. The modification for each section is described in the following sections:

Note:

You must have "organization create" permission to update or delete organizations.

- Modifying Organization Attributes

- Viewing Child Organizations

- Viewing User Information

- Modifying Resources

13.2.4.1 Modifying Organization Attributes

The Attributes tab, as shown in Figure 13-7, of the organization details page displays attributes of the organization. If you are authorized to modify the organization profile as determined by authorization policy on the Modify Organization Profile privilege, then the organization details page opens in editable mode and you can modify organization information. You can modify the values for the attributes, and then click Save to save the changes.

Whether or not the logged-in user is allowed to modify the organization is controlled by authorization policies. If you are not allowed to modify the organization, then the organization details page is displayed in read-only mode with no editable fields. See "Organization Management Authorization" for information about authorization of the organization management feature.

Note:

The Status attribute in the organization details page is read-only.

13.2.4.2 Viewing Child Organizations

The Hierarchy tab is a read-only tab that displays a list of child organizations that the selected organization has. For each child organization in the list, the following are displayed:

- Organization name

- Type

- Status

From the Hierarchy tab, you can open the details of a child organization by selecting the organization, and selecting Open from the Actions menu. Alternatively, you can click Open on the toolbar, or simply click the name of the organization.

To modify a child organization, click the child organization name that you want to modify. The organization details page for the selected organization is displayed, by using which you can modify the details of that organization.

13.2.4.3 Viewing User Information

The Members tab is a read-only tab that displays a list of users in the selected organization. For each user in the list, the following are displayed:

- User Name

- First Name

- Last Name

- Manager Name

From the Members tab, you can open the details of a user by selecting the user, and selecting Open from the Actions menu. Alternatively, you can click Open on the toolbar, or simply click the name of the user.

Tip:

You can add or remove users to and from organizations by using the Attributes tab of the user details page. For more information, see "The Attributes Tab".

13.2.4.4 Modifying Resources

The Resources tab displays the permitted resources for the selected organization. You can select one or multiple resources in the list, and then perform the following:

- Provisioning Resources

- Revoking Resources

13.2.4.4.1 Provisioning Resources

To provision resources to the organization:

1. From the Actions menu, select Provision. Alternatively, click Provision on the toolbar. This brings up a wizard " Step 1: Select a Resource".

2. Search for the resource that you want to provision. Select the resource and click Continue.

3. In the Step 2: Verify Resource Selection page, the resource that you selected for adding to the organization is displayed. Verify the information and click Continue. Provisioning the selected resource to the organization starts.

4. Close the Provision Resource to Organization wizard. The resource is added to the Hierarchy tab.

Tip:

If the provisioned resource is not displayed in the Hierarchy tab, then click Refresh on the toolbar.

13.2.4.4.2 Revoking Resources

To revoke a resource:

1. Select the resource that you want to remove.

2. From the Actions list, select Revoke. Alternatively, click Revoke on the toolbar. A message is displayed asking for confirmation.

3. Click OK to confirm.

13.2.5 Disabling and Enabling Organizations

Note:

- You cannot disable organizations with child orgs or users. You can force delete it only by setting the system property ORG.DISABLEDELETEACTIONENABLED to true. Once you set the property, the users and sub orgs will be deleted while deleting the parent org.

- You can disable an organization only if you have the "Write" permission for that organization.

To disable an organization with enabled state:

1. In the organization details page, click Disable Organization on the top of the page. A message is displayed asking for confirmation. Alternatively, in the simple search result for organizations, select the organization, and from the Actions menu, select Disable.

2. Click OK to confirm. A message is displayed stating that the organization is successfully disabled.

3. Click OK.

To enable an organization with disabled state:

1. In the organization details page, click Enable Organization on the top of the page. Alternatively, in the simple search result for organizations, select the organization, and from the Actions menu, select Enable. A message is displayed asking for confirmation.

2. Click OK to confirm. A message is displayed stating that the organization is successfully enabled.

3. Click OK.

Note:

You can enable an organization only if you have the "Write" permission for that organization.

13.2.6 Managing Administrative Roles

The organization details page allows you to view and define a list of administrative roles and associated permissions that can administer the selected organization. To assign administrative roles to an organization, you must have the appropriate permission to create an organization. To assign permission to create organization:

1. On the role detail page for the role to which you want to assign administrative privileges for organizations, click Data Object Permissions. The Role Details >> Permissions page is displayed.

2. Click Assign. The Assign Permissions page is displayed with a list of permission names that you can select to assign the permissions to the role.

3. For the Organizations permission, select the Allow Insert option. This grants the "create organization" permission to the orgadmin role. Then select the Assign option to the right of the "Organizations" permission.

4. Click Assign. A message is displayed asking for confirmation.

5. Click Confirm Assign. The permission is assigned to the role.

To assign administrative roles to an organization:

Note:

The "Insert" permission is a prerequisite to Write and Delete permissions. Expanding the "Insert" permission allows you to create new organizations. The "Write" permission allows to update, enable, and disable organizations. The "Delete" permission enables to delete the organization.

1. Open the Administrative Roles page by selecting any one of the following:

- In the organization simple search result, select an organization. From the Actions menu, select Administrative Roles.

- In the Browse tab on the left pane, select an organization. From the Actions menu, select Administrative Roles.

- In the organization detail page, click Administrative Roles.

2. On the Administrative Roles page, in the Filter By Role Name, enter a search criterion to search for administrative roles that can administer the organization. Then, click Search. A list of roles with associated permissions are displayed.

3. To unassign any role from the organization, select the Unassign option to the right of the administrative role, and click Unassign.

4. To assign an administrative role to the organization:

1. Click Assign. The Assign page is displayed with a list of available roles.
You can filter the role names by entering a search criteria in the Filter By Role Name box, and clicking Find.

Note that the Read options are selected by default for all the roles.

2. Select the Write, Delete, and Assign options for the administrative roles to provide write, delete, and assign administrative permissions respectively.

3. Click Assign.

5. To update permissions for the administrative roles:

1. Click Update Permissions. The Update page is displayed with a list of administrative roles, whose permissions you can modify.
You can filter the role names by entering a search criteria in the Filter By Role Name box, and clicking Find.

Note that the Read options are selected by default for all the roles.

2. Select or deselect the Write and Delete options for the administrative roles to modify the write and delete permissions respectively.

3. Click Update.

6. When finished, close the Administrative Roles page. Figure 13-8 shows the Administrative Roles page.

Figure 13-8 Assign Administrative Roles

13.2.7 Managing Permitted Resources

The Permitted Resources page allows you to assign and update a list of permitted resources to the users of the selected organization.

1. To assign permitted resources to the users in the selected organization:

1. In the Browse tab on the left pane, select an organization. From the Actions menu, select Open.

2. In the organization detail page, click Permitted Resources.

3. In the Permitted Resources page, select the resources and click Assign.

2. To update the resources allowed to the selected organization:

1. In the Browse tab on the left pane, select an organization. From the Actions menu, select Open.

2. In the organization detail page, click Permitted Resources.

3. In the Permitted Resources page, select the resources and click Update.

Figure 13-9 shows the Assign Permitted Resources page.

Figure 13-9 Assign Permitted Resources

13.2.8 Deleting an Organization

Note:

- You cannot delete organizations with child orgs or users. You can force delete it only by setting the system property ORG.DISABLEDELETEACTIONENABLED to true. Once you set the property, the users and sub orgs will be deleted while deleting the parent org.

- You can delete an organization only if you have the "Delete" permission for that organization.

- The deleted record would still exist in the database, marked deleted.

To delete an organization:

1. In the advanced search result for organizations, select the organization that you want to delete.

2. From the Actions menu, select Delete. A message is displayed asking for confirmation. Alternatively, in the simple search result for organizations, select Delete from the Actions menu. Otherwise, in the Browse tab, select Delete from the Actions menu, or on the organization details page, click Delete Organization.

3. Click OK to confirm. A message is displayed stating that the organization is successfully deleted.

4. Click OK.

13.3 Organization Management Authorization

Authorization of the organization management feature is based on organization administrative roles. The following sets of distinct permissions is required by a role to manage an organization:

- The role must have the following data object permission on organization entities:

- Insert - This enables the user (with this role) to create new organizations and manage them.

- Enable/Disable/Update

These permissions are not specific to a particular organization.

- When role is assigned as an administrative role for an organization, the following permissions are required:

- "Read and View" permissions are implicit by virtue of being administrative role

- Write

- Delete

These permissions are configured per organization.

Permission to get access to Oracle Identity Manager Administration from Oracle Identity Manager Self Service is governed by "menu item" permissions. When the user has access to Oracle Identity Manager Administration, the user is allowed to browse users, roles, and organizations.

Second level menus for edit, view, and delete actions on user and role entities are derived from the OES policies, such as create, update, delete on user and role respectively.

Similarly, second level menus to edit, view, and delete organizations is derived from "orgadmin role" and "data-object" permissions on organization entity type.

In Oracle Identity Manager 11g Release 1 (11.1.1), "delegated administration" permissions are managed by using Oracle Entitlements Server (OES) authorization policies. These OES policies for user management can be used to control:

See Also:

Chapter 15, "Managing Authorization Policies" for information about OES authorization policies

- Under which organizations you can create or modify users

- Data constraints can specify that you can change users in a set of organizations with or without hierarchy.

Together these capabilities give us the delegated administrative model.

To configure a delegated administrator for an organization:

1. Define a custom authorization policy to manage users and set organization constraints. Organization constraints can be hierarchy aware. See "Creating Custom Authorization Policies" for information about creating custom authorization policies and setting data constraints.

2. Add the user to the role specified in the custom policy. See "Adding and Removing Roles" for information about adding a user to a role.

3. To configure the role as organization administrator, first create a role. See "Creating Roles".
When you create the orgadmin role, the role detail page for this role is displayed.

4. Assign this orgadmin role "data object" permissions on the organization type. With this "data object" permission, the user (with this role), can create new organizations and manage them. See "Managing Administrative Roles" for information about assigning "create organization" permission to a role.

5. Select an organization and assign the orgadmin role as administrative role for the organization. This step would give the user the ability to manage the selected organization. Manage permissions include update, enable, disable, and delete. See "Managing Administrative Roles" for information about assigning administrative roles to an organization.

14 Creating and Searching Requests

A User in Oracle Identity Manager can manage Requests by creating, searching, or performing other operations on requests from Oracle Identity Manager Advanced Administration if the user belongs to "REQUEST ADMINISTRATORS" group.

This chapter describes the request management feature in the following sections:

See Also:

"Managing Requests" for information about request management concepts and tasks

- Creating Requests by Using Oracle Identity Manager Advanced Administration

- Searching and Tracking Requests

14.1 Creating Requests by Using Oracle Identity Manager Advanced Administration

You can log in to Oracle Identity Manager Advanced Administration and create requests for yourself and for others if your role has the appropriate privileges. You can also create requests by using Oracle Identity Manager Self Service.

Creating requests is described with the help of the following scenarios:

- Creating a Request To Create a User

- Creating a Request to Provision a Resource to Users

- Creating a Request to Deprovision Resources

14.1.1 Creating a Request To Create a User

To create a request to create a user:

1. In Oracle Identity Manager Advanced Administration, click the Administration tab, and then click Requests.

2. From the Actions menu on the left pane, select Create Request. Alternatively, you can also click the Create Request icon on the toolbar. The Select Request Template page of the Create Request wizard is displayed.

Note:

The steps in the Create Request wizard are dynamically generated based on the selection of the request template in the first step.

3. From the Request Template list, select the request template based on which you want to create the request. The dropdown list shows all the default request templates as well as the custom templates that are created based on the request types. In this example, select Create Contractor, and then click Next.

Note:

- The Create Contractor request template is not a default request template and is available for selection when a request template with the same name is created based on the privileges you have. For the purpose of this scenario, this request template has been created based on the Create User request type for creating user accounts for contract employees. For information about creating this request template, see "Creating a Request Template Based on the Create User Request Type"".

- The Create Role, Modify Role, and Delete Role request templates are not available in the Request Templates list. This is because request creation by using any request template that are based on the Create Role, Modify Role, and Delete Role request types are supported from the APIs, but not in the UI. However, you can search for these request templates in the Request Templates tab. In addition, the Create Role, Modify Role, and Delete Role request types can be used to create approval policies and new request templates.

4. In the Enter Details page, specify values for the user attributes. The fields for the user attributes are displayed as defined in the Create Contractor request template. For example, the Middle Name attribute is not displayed if you have already specified a value for it at the template level. For the Organization attribute, an LOV is available, whose values are also defined at the template level. For details about specifying these values, see "Creating a Request Template Based on the Create User Request Type".
After specifying values for the user attributes, click Next.

5. In the Enter Additional Data page, enter the value of the attribute that is specified as additional data in the request template that you are using to create this request. In this example, Date of Birth is specified as an additional attribute in the request template. Enter a value in the Date of Birth field, and then click Next.

Note:

The Enter Additional Data page is displayed dynamically based on the additional data specified in the request template.

6. In the Confirm page, specify values for the Effective Date and Justifications fields. Effective date is the date from which the request will be active after approval. For example, after a create user request is approved, the user is created in Oracle Identity Manager on the date specified in the Effective Date field. The Justification field is a justification for creating the request that might help the approver in approving or rejecting the request.
On clicking Finish, a request to create a user based on the Create Contractor request template is created.

14.1.2 Creating a Request to Provision a Resource to Users

To create a request to provision a resource to one or more users:

Note:

The following request types are similar in nature in terms of request creation and execution:

- Provision Resource

- Modify Provisioned Resource

1. In Oracle Identity Manager Advanced Administration, click the Administration tab, and then click the Requests tab.

2. From the Actions menu on the left pane, select Create Request. The Select Request Template page of the Create Request wizard is displayed. The steps in this wizard are dynamically generated based on the selection of the request template in the first step.

3. From the Request Template list, select the request type or request template based on which you want to create the request. In this example, select Provision E-Business Resource, and then click Next.

Note:

The Provision E-Business Resource request template is not a default request template and is available for selection when a request template with the same name is created based on the privileges you have. For the purpose of this scenario, this request template has been created based on the Provision Resource request type for provisioning an E-Business resource to a user. For information about creating this request template, see "Creating a Request Template Based on the Provisioning Resource Request Type"

4. In the Select Users page, specify a search criteria in the fields to search for the users that you want to provision the resource, and then click Search. A list of users that match the search criteria you specified is displayed in the Available Users list.

5. From the Available Users list, select one or more users to whom you want to provision the resource. You can select one or more users that are your direct reports. In other words, you can select one or more users for whom you are the manager as specified in the user's profiles.
Click Move to include your selection in the Selected Users list, and then click Next.

Note:

In this page, available users list is shown based on the authorization policies for user entities. The users cannot be restricted from the request templates.

6. In the Select Resources page, search for the available resources. From the Available Resources list, select the resources that you want to provision, click Move to include the selected resources in the Selected Resources list. In this example, select E-Business RO as the resource to be provisioned, and then click Next.

Note:

Only the E-Business RO resource is displayed in the Selected Resources list because the Provision E-Business Resource request template is created only for provisioning the E-Business resource. The resources are displayed in the Available Resources list based on the resource selection in the request template.

7. In the Resource Details page, specify values for the attributes of the resource.
In this example, you can select the life span of the E-Business resource being provisioned to the selected user or users. In the Life Span Type lookup, select a life span type, such as Short term, Mid term, or Long term. In the Server lookup, select the name of the E-Business server to connect to. For the Oracle Apps User Responsibilities parent attribute, you can enter multiple sets of values for the Responsibility Start Date, Responsibility End Date, and Responsibility Name child attributes. To do so, select values in the fields, and then click Add. Repeat entering another set of values in the Responsibility Start Date, Responsibility End Date, and Responsibility Name fields, and then click Add. For information about defining parent and child attributes, see "Creating a Request Template Based on the Provisioning Resource Request Type".

Note:

In this page, the attributes are picked up from the request dataset. See "Step 1: Creating a Request Dataset for the Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about request datasets.

Specify values for all other resource attributes, and then click Next.

If you select multiple resources in the Select Resources page, then the Resource Details page for each selected resource is displayed one by one. For instance, in the Select Resources page, you select the E-Business and Active Directory resources. The Resource Details page for the E-Business resource is displayed. Enter values for all attributes of the E-Business resource, and click Next. Then, the Resource Details page for the Active Directory resource is displayed. Specify values for all attributes of the Active Directory resource, and click Next.

8. If the selected resource has dependent resources, then the steps to select the dependent resources are displayed. Select the dependent resources, click Next.
A resource object can have a dependency on other resource objects. During creation of provision resource request (for self or others), if the dependent resources are not already provisioned, then these dependent resources are automatically added to the request. This is applicable to the Provision Resource and Self Provision Resource request types.

Dependent resources can of the following types:

- Single beneficiary: During creation of a provision resource request for single user, if the dependent resources are not already provisioned, then those dependent resources are automatically added to the request.
Suppose the resource objects DB, AD, and Exchange are created in such a way that Exchange has dependency on AD, and AD has dependency on DB. Single beneficiary dependent resources is described with the help of the following examples:

- Example 1: User Jane does not have any of the resources. During self provision resource request, Jane selects Exchange as a resource in the Select Resources step. Because Jane does not have the dependent resources AD and DB, the request UI automatically adds the resource details collection steps for the resources AD and DB along with the resource Exchange.

- Example 2: User John has DB resource provisioned. You want to provision the resource Exchange to John. During the provision resource request, you select John in the Select Users step and Exchange in the Select Resources step. Because John does not have the dependent resource AD provisioned, the request UI automatically adds the resource details collection step to the resource AD along with the resource Exchange. Resource DB is not added because John already has DB provisioned.

- Example 3: User Brad does not have any resources. During self provision resource request, Brad selects DB as a resource in the Select Resources step. Resource details collection step for only the resource DB is shown because the DB resource does not have any dependency.

- Multiple beneficiary: During creation of a provision resource request for multiple users, if any of the users doesn't have dependent resources provisioned, then those dependent resources will be automatically added to the request. These dependent resources will be added to only to those beneficiaries that doesn't already have these resources provisioned.
Suppose the resource objects DB, AD, and Exchange are created in such a way that Exchange has dependency on AD, and AD has dependency on DB. Multiple beneficiary dependent resources is described with the help of the following examples:

- Example 1: Users Jane and John do not have any resources provisioned. You want to provision the resource Exchange to Jane and John. During the provision resource request, you select Jane and John in the Select Users step and Exchange in the Select Resources step. Because both the beneficiaries do not have the dependent resources AD and DB provisioned, the request UI automatically adds the resource details collection step to the resources AD and DB along with the resource Exchange. In this request, the resources AD and DB are added to both the beneficiaries Jane and John.

- Example 2: User Jerry does not have any resource provisioned. User Katie has resource DB provisioned. You want to provision the resource Exchange to Jerry and Katie. During the provision resource request, you select Jerry and Katie in the Select Users step and Exchange in the Select Resources step. Because Jerry (one of the beneficiaries) does not have the dependent resources AD and DB provisioned, the request UI automatically adds the resource details collection step for the resources AD and DB along with the resource Exchange. In this request, the resource AD is added to both the beneficiaries Jerry and Katie. However, the resource DB is added to only Jerry but not to Katie because Katie already has the resource DB provisioned.

9. In the Justification page, you can specify values for the following fields, and then click Finish to submit the request.

- Effective Date: Enter the date when you want the underlying operation of the request to be executed after approval. For example, if you specify September 15 as the effective date for provisioning a laptop to a user, then the laptop is not provisioned to the user before September 15 even if the request is approved. The resource is provisioned on September 15. If the request is approved after September 15, then the resource is provisioned with immediate effect.

- Justification: Enter a justification for creating the request.

If you have selected a user to provision the resource, then the request is available for approval. If you have selected multiple users to provision the resource, then the request is broken into multiple child requests for operation level approval, and each child request can be approved or rejected independently.

14.1.3 Creating a Request to Deprovision Resources

To create a request to deprovision one or more resources:

Note:

The following request types are similar in nature in terms of request creation and execution:

- Enable Provisioned Resource

- Disable Provisioned Resource

- De-Provision Resource

1. In the Welcome page of Oracle Identity Manager Advanced Administration, under Administration, click Search Requests. Alternatively, you can click the Administration tab, and then click Requests.

2. From the Actions menu, select Create Request. Alternatively, you can click the create request icon on the toolbar. The Select Request Template page of the Create Request wizard is displayed. The steps in this wizard are dynamically generated based on the selection of the request template in the first step.

3. From the Request Template list, select De-Provision Resource. Then, click Next.

4. In the Select Users page, search for the users. Select one or more users from the Available Users list from whom you want to deprovision a resource. Click Move to move the users to the Selected Users list, and then click Next.

5. In the Select Resources page, search for the resources. Select one or more resources that you want to deprovision. Click Move to move the resources to the Selected Resources list. Then, click Next. The Justification page is displayed.

6. In the Effective Date field, specify a date on which you want the resource to be deprovisioned.

7. In the Justification field, enter a justification for the deprovisioning operation.

8. Click Finish. The request to deprovision one or more resources is created.

Note:

Resource search in Select Resources page lists all the resources provisioned to user selected in Select Users page. If multiple users are selected, then search shows common resources provisioned to all selected users.

14.2 Searching and Tracking Requests

You can login to Oracle Identity Manager Administration and search for requests to view a list of requests. You can perform simple search and advanced search for requests. You can also view the details of each request.

This section contains the following topics:

- Searching Requests

- Viewing Request Details

14.2.1 Searching Requests

To perform a simple search for requests:

1. Login to Oracle Identity Manager Advanced Administration.

2. In the Welcome page, under Administration, click Search Requests. Alternatively, you can click the Requests subtab under the Administration tab.

3. In the left pane, click the icon next to the Search field. A list of available requests are displayed in the search results table in the left pane with details such as request ID, request type, and request status. You can sort the requests based on Request ID and Request Type.

Note:

- Sorting on Request ID is string-based and not number-based.

- For request search based on the Requester/Beneficiary fields, enter requester/beneficiary user login ID.

To perform an advanced search for requests:

1. In the left pane of the Requests section in Oracle Identity Manager Advanced Administration, click Advanced Search. The Advanced Search 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 requests with 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 requests with 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. To include a field in your search criteria, click Add Fields, and then select the field from the list. A cross icon is displayed only for the field added by using Add Fields. To discard such a field from your search, click the cross icon next to the field.

5. Click Search. The search results table is displayed with details about request ID, request type, status, date requested, and requester, as shown in Figure 14-1. You can sort the requests based on request ID, request type, request status, and date requested.

Note:

Sorting on Request ID is string-based and not number-based.

Figure 14-1 Advanced Search Results

Description of "Figure 14-1 Advanced Search Results"

14.2.2 Viewing Request Details

From the search results tables of the simple and advanced search, you can view the details of the requests for tracking. To do so, select a request in the search results table. From the Actions menu, select Open Request Detail. The Request Details page for the selected resource is displayed.

Figure 14-1 lists the fields in the Request Information section of the Request Details page:

Table 14-1 Fields in the Request Details page

Field

Description

Request ID

An ID to uniquely identify the request

Request Type

The type of request or the request type based on which the request is created

Status

The status in which the request is currently in

Note: Status shows the current request status. A link is displayed if the status is Request Failed or Request Completed with Errors, which can be clicked to see the reason for the failure.

Date Requested

The date of creation of the request

Effective Date

The date from which the operation requested will be active

Requester

The user who created the request

Beneficiary

The user for whom the request is created

Justification

The reason for creating the request

Parent Request ID

The request ID of the parent request if the request whose details is displayed is a child request

Note:

From the Request Details page, you can close the request by selecting Close Request from the Actions menu at the top of the page. For information about closing requests, see ""Closing Requests"".

The Request Details page displays the following tabs:

- The Requested Resources or Users or Requested Roles Tab

- The Request Comments Tab

- The Request History Tab

- The Approval Tasks Tab

- The Child Requests Tab

14.2.2.1 The Requested Resources or Users or Requested Roles Tab

This tab is displayed in the Request Details page depending on the type of request. For example, the Requested Resources tab is displayed in the Request Details page when the request type is Provision Resource. Similarly, the Users or Requested Roles tabs are displayed when the request types are Create User or Assign Roles respectively.

Figure 14-2 shows the Requested Roles tab:

Figure 14-2 The Requested Roles Tab

Description of "Figure 14-2 The Requested Roles Tab"

In the Requested Resources tab that is displayed for the resource request types, you can view the details of the resources associated with the request. The details include beneficiary, resource name, and resource details. To view resource details, click the View Details link for a particular resource. The Resource Details window is displayed, as shown in Figure 14-3:

Figure 14-3 The Resource Details Window

Description of "Figure 14-3 The Resource Details Window"

14.2.2.2 The Request Comments Tab

This tab displays any comments provided with the request that can help the approver take actions on the request. This tab also allows you to add a new comment to the request. To add a comment:

1. In the Request Comments tab, from the Actions list, select Add Comment. The New Comment dialog box is displayed.

2. In the Comments field, enter the comment for the request.

3. Click Save. The comment is added and is displayed in the Request Comments tab, as shown in Figure 14-4:

Figure 14-4 The Request Comments Tab

Description of "Figure 14-4 The Request Comments Tab"

14.2.2.3 The Request History Tab

This tab displays the history of the request, such as the request status, the date when the request is updated, and by whom the request is updated.

Figure 14-5 shows the Request History tab.

Figure 14-5 The Request History Tab

Description of "Figure 14-5 The Request History Tab"

Note:

If an approver is not specified for a request, then the Updated By column in the Request History tab displays Internal User. This is the OIMINTERNAL user, which is an Oracle Identity Manager system user. All the internal request status updates are performed as Internal User.

14.2.2.4 The Approval Tasks Tab

This tab shows the status of tasks that have been assigned to people in connection with the request.

Figure 14-6 shows the Approval Tasks tab. Two tasks are shown: Requester manager approval for Request ID 82 and Beneficiary manager approval for Request ID 82. Note that for tasks that are assigned to multiple approvers in a sequence (that is, Assignee 1, then Assignee 2), the Assignee column only shows the name of the person who currently has the task assigned (or, if the task sequence has been completed, then it shows the name of the last person who worked on the task).

Figure 14-6 The Approval Tasks Tab

Description of "Figure 14-6 The Approval Tasks Tab"

14.2.2.5 The Child Requests Tab

This tab is displayed only for a bulk/parent request. It displays the child requests that are created for the bulk/parent request.

Part IV

Policy Administration

This part describes Oracle Identity Manager delegated administration functionalities by using the policy administration features.

It contains the following chapters:

- Chapter 15, "Managing Authorization Policies"

- Chapter 16, "Managing Access Policies"

- Chapter 17, "Managing Request Templates"

- Chapter 18, "Managing Approval Policies"

- Chapter 19, "Managing Attestation Processes"

15 Managing Authorization Policies

Oracle Identity Manager controls access to the application by the users to allow or prevent the users to perform various operations in the application. This is controlled by the authorization engine embedded in Oracle Identity Manager with the help of authorization policies. The purpose of authorization policies is to control user's access to Oracle Identity Manager application, which includes data, UI, and API. The authorization policies determine at runtime whether or not a particular action is allowed. You can define authorization policies that satisfy the authorization requirements within Oracle Identity Manager.

In earlier releases of Oracle Identity Manager, each Oracle Identity Manager feature defines and manages its own authorization policy UI and backend implementation. In Oracle Identity Manager 11g Release 1 (11.1.1), authorization policy management is centralized as an administrative feature. Oracle Identity Manager's authorization policy management and enforcement engine is now based on an embedded version of Oracle Entitlements Server (OES), Oracle's industry-leading fine-grained entitlements administration product. These authorization policies secure access control to the Oracle Identity Manager application, thereby defining "who can do what" inside the application. This centralized definition of authorization policies continues to provide context-sensitive authorizations for each feature as explained in the following sections:

- Authorization Policy

- Creating and Managing Authorization Policies

- Authorization Policies for Oracle Identity Manager Features

15.1 Authorization Policy

You can define and manage authorization policies in the Authorization Policies section of the Oracle Identity Administration. This section is available to users who have the Manage Authorization Policies privilege.

See Also:

"Adding and Removing Roles" and "Viewing and Administering Roles" for information about assigning roles and privileges

The following are the structural components of an authorization policy:

- Identifying details: Each authorization policy must have a name and description.

- Oracle Identity Manager feature: Each authorization policy is defined for a specific feature in Oracle Identity Manager. Features are well-defined components in Oracle Identity Manager such as user management and role management. The authorization requirements of multiple features cannot be covered by a single authorization policy.

- Assignee: This is the role or roles that a policy grants privileges to. You can grant privileges to one or more roles for each policy. All members of the role (direct or indirect through inheritance) are granted the privileges by the authorization policy. For the user management feature, a rule based on the manager relationship is supported. Here, all the users that are in the management chain of the user being acted on are the assignees of the authorization policy.

Note:

- For information about inheritance of role membership, see Chapter 12, "Managing Roles".

- To assign policies based on user attributes, you can configure auto-group membership rules and assign policies to that role. See "Viewing, Assigning, and Revoking Membership Rules" for details.

Assignee can include additional conditions that must be fulfilled by the assignee. This is a way of making the authorization policy context aware. For example, for the user management feature, a condition can state that for the assignee to have the privileges, the assignee must be a member of the same organization listed in the data security.

- Privileges: These are the privileges that the assignees are granted. The list of privileges is defined by the feature for which this policy is being defined. For example, the user management feature defines privileges such as Search for Users, View User Detail, and Modify User Profile. For a complete list of privileges for the user management feature, see "Privileges".
Some privileges also support fine-grained attribute-level controls that define which specific entity attributes of the feature are further granted to the assignee. For instance, for the View User Detail privilege, the policy can further define which of the attributes on the user entity can be viewed by the assignee at run time. Not all privileges support attribute-level details. For example, the Delete User privilege does not require or support any attribute-level details.

- Data security: These are the entities managed by the feature over which a privilege is granted to the assignee. This section is optional based on whether or not the feature for which the authorization policy is being defined supports data security. The data security is expressed in the form of an entity selection criteria or a search criteria that is used to determine the entities over which the privilege is granted. The data security can also be a list of specific entities. The data security capabilities depend on the feature. For instance, the criteria can specify that the assignee is granted privileges over the users belonging to a list of organizations. This criteria can provide additional security settings that apply to the data security. For example, in the user management feature, an instruction can be that the organization condition applies down the hierarchy so that users in the specified organization and all child organizations are in scope for this data security policy.

15.2 Creating and Managing Authorization Policies

Using the Administrative and User Console, you can perform the following tasks related to authorization policies:

- Searching Authorization Policies

- Creating Custom Authorization Policies

- Creating Authorization Policies Based on Existing Policies

- Viewing and Modifying Authorization Policies

- Deleting Authorization Policies

Note:

Creation, modification, or deletion of authorization policies does not come into effect immediately, but takes approximately 5 to 10 seconds to come into effect.

15.2.1 Searching Authorization Policies

You can perform simple or quick search and advanced search operations for existing authorization policies. These operations are described in the following sections:

- Simple Search

- Advanced Search

15.2.1.1 Simple Search

To perform simple search for authorization policies:

1. Login to the Administration console with credentials that have the Manage Authorization Policies privilege.

2. In the left pane, click Authorization Policy tab.

3. Verify that Policy is selected in the lookup.

4. In the text box, enter a search criteria for authorization policies. For example, you can enter the name of the authorization policy you want to find. You can also use wildcard characters in the search criteria, such as the asterix (*) character to search all authorization policies.

5. Click the Search icon. You can include wildcard characters (*) in your search criterion. For performance reasons, initial (prefix) wildcards will be removed. However, a trailing (prefix) wildcard will be added to all searches.

Note:

Authorization policy search is case sensitive, so you must ensure proper case while entering search criteria.

Figure 15-1 shows the result of the authorization policies simple search:

Figure 15-1 Authorization Policy Simple Search

Description of "Figure 15-1 Authorization Policy Simple Search"

15.2.1.2 Advanced Search

To perform advanced search for authorization policies:

1. In the Welcome page, under Authorization Policies, click Advanced Search - Authorization Policies. Alternatively, you can click the Authorization Policy tab, and then click Advanced Search link on the left pane. The Advanced Search page is displayed.

2. Select any one of the following options:

- All: On selecting this option, the search is performed with the AND condition. This means that the search operation is successful only 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 operation is successful when any search criterion specified is matched.

3. In the Policy Name field, enter the authorization policy name that you want to search. To do so, select a search comparator in the list adjacent to the Policy Name field. The default search comparator is "Contains". Other comparators are available in the pulldown list as an alternative.

4. In the Role Name field, enter the name of the role to which the policies are assigned. You can use wildcard characters in your search criteria. Select a search condition in the list adjacent to the Role Name field.

5. In the Entity Type field, select the entity type for whom the authorization policies are defined.

6. Click Search. The search results are displayed in the search results table, as shown in Figure 15-2:

Figure 15-2 Authorization Policy Advanced Search

Description of "Figure 15-2 Authorization Policy Advanced Search"

15.2.2 Creating Custom Authorization Policies

Oracle Identity Manager Administration allows you to create custom authorization policies for the following Oracle Identity Manager components:

- User Management

- Role Management

- Authenticated Self Service User Management

This section describes authorization policy creation in the following topics:

- Creating an Authorization Policy for User Management

- Creating an Authorization Policy for Role Management

- Creating an Authorization Policy for Authenticated User Self Service

15.2.2.1 Creating an Authorization Policy for User Management

You can create custom authorization policies for user management to control access to user management operations. For example, you can specify that the users belonging to a particular role can search for all users or users belonging to a specific organization, and view a set of selected user attributes.

To create an authorization policy for user management:

1. Login to the Administrative and User Console, and click Administration.

Note:

You must be a member of the System Administrators role to create, modify, delete, search authorization policies.

2. On the Welcome page, under Authorization Policies, click Create Authorization Policy. Alternatively, you can click the Authorization Policy tab, and then click the Create Authorization Policy icon on the toolbar, or select Create from the Actions menu. The Basic Policy Information page of the Create Policy wizard is displayed, as shown in Figure 15-3:

Figure 15-3 The Basic Policy Information Page

Description of "Figure 15-3 The Basic Policy Information Page"

Note:

In the Basic Policy Information page of the Create Policy wizard, only the Basic Policy Information, Policy Settings and Confirmation Nodes are shown at the top of the page. The other Nodes of the wizard are dynamically generated based on your selection in the Entity Name field.

3. In the Policy Name field, enter the name of the authorization policy.

4. In the Description field, enter a description of the authorization policy.

5. To create an authorization policy for user management, in the Entity name field, select User Management.

6. Click Next. The Permissions page is displayed, as shown in Figure 15-4:

Figure 15-4 The Permissions Page

Description of "Figure 15-4 The Permissions Page"

In this page, you can select permissions that you want to enable in the authorization policy.

7. In the Permissions table, select the check boxes in the Enable column. If you want to enable all permissions for the authorization policy, then select Enable All Permissions at the top of the table.
To allow permission to be used only on a specific set of attributes, you can click Edit Attribute.

8. Click Next. The Data Constraints page of the Authorization Policy wizard is displayed, as shown in Figure 15-5:

Figure 15-5 The Data Constraints Page

Description of "Figure 15-5 The Data Constraints Page"

In this page, options for the feature selected on the Entity Name field in step 1 are displayed.

9. Select one of the following:

- All Users: Select this option to specify all the users in Oracle Identity Manager for which the authorization policy is created.

- Users that are members of selected Organizations: Select this option to specify organizations for whose members you want to create the authorization policy.

10. If you select the Users that are members of selected Organizations option, then you must specify one or more organizations. To do so:

1. Click Add Organization. The Add Organization dialog box is displayed.

2. Click the Search icon to display the list of organizations in the Available Organizations list.

3. From the Available Organizations list, select one or more organizations, and then click the Move or Move All buttons to move the selected organizations to the Organizations to Add list.

4. Click Save. The selected organizations are added in the table in the Data Constraints page.

11. Under Organization Security Setting, select Hierarchy Aware (include all child organizations) to specify that the authorization policy is applicable to users who are members of all the child organizations of the selected organizations.

12. Click Next. The Policy Assignment page of the Authorization Policy wizard is displayed, as shown in Figure 15-6:

Figure 15-6 The Policy Assignment Page

Description of "Figure 15-6 The Policy Assignment Page"

13. Under Assign by Rule, select Management Chain of User to assign the direct and indirect managers of the user to the authorization policy.

14. To assign roles to the authorization policy:

1. Click Add. The Assign Roles dialog box is displayed.

2. Click the Search icon to display the list of roles in the Available Roles list.

3. From the Available Roles list, select one or more roles, and then click the Move or Move All buttons to move the selected roles to the Organizations to Add list.

4. Click Save. The selected roles are added to the table in the Assignment page.

Note:

To remove a role from the table in the Assignment page, click Remove.

15. Under Assignment Security Setting, select Assignee must be a member of the User's Organization to specify that the authorization policy is to be applied only for the users that are members of the same organization in which the policy is applied.

16. Click Next. The Confirmation page of the Authorization Policy wizard is displayed with details specified in the steps of the wizard.

17. Click Finish. The authorization policy is created.

15.2.2.2 Creating an Authorization Policy for Role Management

You can create custom authorization policies for role management to control the access to role management operations. For example, you can specify that users belonging to a particular role can search for roles and role categories and view role details and role category details for all roles or for some selected roles. But the users belonging to that particular role will not be allowed to perform other role management operations.

To create an authorization policy for Oracle Identity Manager role management feature:

1. On the Welcome page of Oracle Identity Administration, under Authorization Policies, click Create New Policy. Alternatively, you can:

- Click the Authorization Policy tab, and then click the Authorization Policy icon on the toolbar.

- From the Actions menu, select Create.

The Basic Policy Information page of the Authorization Policy wizard is displayed.

Note:

The pages in the Create Policy wizard are dynamically generated based on the Entity Name selection in the Basic Policy Information page.

2. In the Policy Name field, enter the name of the authorization policy.

3. In the Description field, enter a description of the authorization policy.

4. In the Entity Name field, select an entity name based on the authorization feature you want the assignee to have. To create an authorization policy for role management, select Role Management.

5. Click Next. The Permissions page is displayed.

6. Select the permissions that you want to enable for the authorization policy. To select all permissions, select Enable All Permissions at the top of the table.

7. Click Next. The Data Constraints page is displayed.

8. Select any one of the following options::

- All Roles: To specify that the authorization policy is applicable to all roles in Oracle Identity Manager including all the child roles.

- Selected Roles: To specify that the authorization policy is applicable to selected roles only.

The roles selected in the Data constraint page are roles on which action is to be performed.

9. If you select the Selected Roles option, then you must select the roles for which the authorization policy is been created. To do so:

1. Click Add Role. The Assign Roles dialog box is displayed.

2. Click the Search icon to display all roles in the Available Roles list.

3. Select the roles for which you want to apply the authorization policy.

4. Click the Move or Move All buttons to move the roles to the Roles to Assign list.

5. Click Save. The selected roles are added to the Data Constraints page of the Authorization Policy wizard.

10. To remove a selected role from the Data Constraints page:

1. Select the role, and then click Remove. A message box is displayed asking for confirmation.

2. Click OK to confirm.

11. In the Data Constraints page, under Role Security Setting, select Hierarchy Aware (Include all Parent Roles) to specify that the authorization policy is applicable to Roles, which are added as parent Roles.

12. Click Next. The Policy Assignment page is displayed. In this page, you can add and remove roles as described in steps 10 and 11.
Roles selected in the Policy Assignment page are roles whose direct and indirect members will perform the action based on the policy.

13. Click Next. The Confirmation page is displayed with Basic Policy Information and details about permissions, data constraints, and assignments.

14. Click Finish. The authorization policy is created.

15.2.2.3 Creating an Authorization Policy for Authenticated User Self Service

You can create custom authorization policies for authenticated user self service to control the access of user self service operations. For example, if you want to make a few self profile attributes available for modification by a user or a group of users but do not want the users to modify some other self profile attributes, then create a custom authorization policy for user self service with permission to modify a set of user profile attributes, and assign roles to the policy. The users who belong to the assigned roles will have permission to modify the self profile attributes as specified in the authorization policy.

To create an authorization policy for authenticated user self service:

1. On the Welcome page of Oracle Identity Administration, under Authorization Policies, click Create New Policy. Alternatively, you can:

- Click the Authorization Policy tab, and then click the Authorization Policy icon on the toolbar.

- From the Actions menu, select Create.

The Basic Policy Information page of the Authorization Policy wizard is displayed.

Note:

The pages in the Create Policy wizard are dynamically generated based on the Entity Name selection in the Basic Policy Information page.

2. In the Policy Name field, enter the name of the authorization policy.

3. In the Description field, enter a description of the authorization policy.

4. In the Entity Name field, select an entity name based on the authorization feature you want the assignee to have. To create an authorization policy for role management, select Self Service User Management.

5. Click Next. The Permissions page is displayed.

6. Select the permissions that you want to enable for the authorization policy. For example, if you want to allow the user to modify self profile, then select Modify User Profile.
To select all permissions, select Enable All Permissions at the top of the table.

7. You can modify some permissions that have attribute-level settings. To do so:

1. Select the permission, for example, Modify User Profile, and click Edit Attributes on the toolbar. The Attribute Settings window is displayed with a list of all user attributes.

2. Select the attributes that you want to allow the user to modify, and click Save.

8. Click Next. The Policy Assignment page is displayed with a table that contains the roles that are assigned to this policy.

9. To add a role to the policy, click Add. Alternatively, from the Actions menu, select Add.
The Assign Roles window is displayed.

10. Search for role in the Assign Roles window, select the role or roles that you want to assign to the policy, and click Add. The role is added to the policy assignment table.
The authorization Policy will be enabled for all the members of the assigned roles.

To remove a role from the policy, select the role in the policy assignment table, and click Remove.

11. Click Next. The Confirmation page is displayed with Basic Policy Information and details about permissions, data constraints, and assignments.

12. Click Finish. The authorization policy is created.

15.2.3 Creating Authorization Policies Based on Existing Policies

You can create an authorization policy by using the general, permissions, data constraints, and assignment information from another authorization policy already existing in Oracle Identity Manager. To do so:

1. Search for the authorization policy from which you want to use information to create another policy.

2. Select the policy. From the Actions menu, select Create Like. The Authorization Policy wizard is displayed.

3. In the Basic Policy Information page, edit the Policy Name, Description, and Entity Name fields to specify new values.

4. Perform the steps to complete the wizard as described in "Creating Custom Authorization Policies".

15.2.4 Viewing and Modifying Authorization Policies

You can view and modify authorization policies, and change the general information, permissions, data constraints, and assignments of the authorization policies. To do so:

Note:

The options for authorization policy modification changes dynamically based on the entity type selected for the policy. In this procedure, the example of an authorization policy for role management is used.

1. In the Authorization Policy tab of the Administration Console, in the left pane, search for authorization policies. The policies matching the search criteria are displayed in the search results table.

2. Click an authorization policy. Alternatively, you can select an authorization policy, and from the Actions menu, select Open. The page that allows you to view and modify authorization policy details is displayed. The General tab of the page is displayed by default, with details about the policy name, description, entity name, permissions, data constraints, and assignment.

3. Edit the Policy Name and Description fields to update the authorization policy name and description.

Note:

You cannot change the entity name of an authorization policy after the policy is created.

4. Click the Permissions tab. In this tab, you can check the permissions that you want to enable in this policy. To do so, select the permissions from the table, or select Enable All Permissions to enable all permissions.
Some permissions have attribute-level settings. To modify the attribute-level settings, click Edit Attributes.

5. Click the Data Constraints tab. In this tab, you can modify the roles that the user must be a member of for this authorization policy.

6. Select any one of the following options:

- All Roles: To specify that the authorization policy is applicable to all roles in Oracle Identity Manager including all the child roles.

- Selected Roles: To specify that the authorization policy is applicable to selected roles only.

7. If you select the Selected Roles option, then you must select the roles for which the authorization policy is been created. This tab also allows you to remove selected roles. To add or remove roles, perform the steps described in steps 10 or 11 respectively of "Creating an Authorization Policy for Role Management".

8. Select Hierarchy Aware (include all Parent Roles) to specify that all the parent roles of the selected roles must be selected for the authorization.

Note:

Steps 6 through 8 are applicable for authorizations policies for roles.

9. Click the Assignment tab. This tab displays the roles that are assigned to this policy.
You can add or remove the assignment by performing steps 10 or 11 respectively of "Creating Custom Authorization Policies" and "Creating an Authorization Policy for Role Management".

10. Click Apply to save changes.
Alternatively, click Revert to refresh the page with old values.

See Also:

"Disabling Access to Features Through the Authorization Policies" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about disabling or hiding features by using authorization policies

15.2.5 Deleting Authorization Policies

To delete an authorization policy:

1. In the Authorization Policy tab of the Administration Console, search for the authorization policy that you want to delete.

2. Select the policy. From the Actions menu, select Delete. A message box is displayed asking for confirmation.

3. Click OK to confirm deletion.

15.3 Authorization Policies for Oracle Identity Manager Features

This section describes the authorization policy components for the following Oracle Identity Management features:

- User Management

- Authenticated User Self Service

- Role Management

- Authorization Policy Management

- User Management Configuration

- Reconciliation Management

- Scheduler

- Request Template Management

- Request Creation By Using Request Templates

- Approval Policy Management

- Notification Management

- System Properties

- Diagnostic Dashboard

- Plug In

15.3.1 User Management

The components of the authorization policies defined for the user management feature and the default authorization policy are described in the following sections:

- Assignee

- Functional Security

- Data Security

- Default Authorization Policies

See Also:

Chapter 11, "Managing Users" for information about the user management feature

15.3.1.1 Assignee

The assignee of the policy can be a set of roles. The policy is assigned to each role in the set of policies. In addition, a rule for selecting the management chain of the user being managed as an assignee is supported. There is no ability to restrict this to just the direct manager of the user being managed.

The Assignee must be a member of security setting restricts the grant to the users who are also members of the organizations or roles being granted privileges over. If assignee belongs to multiple organization hierarchies, then a match to at least one organization hierarchy must provide the grant.

15.3.1.2 Functional Security

Multiple privileges are defined for the user management feature such as Search for Users and View User Detail.

Note:

- Any user management policy that provides the Search User permission must also provide the View User Details permission.

- For a complete list of privileges for the user management feature, see "Privileges".

The following privileges support the fine-grained attribute-level controls, in which the user is able to select the specific attributes applicable to that operation:

- View User Detail

- Modify User Profile

The list of attributes are based on the list of attributes defined for the user entity.

15.3.1.3 Data Security

For the user management feature, data security is defined as the list of organizations whose members the assignee has privileges over. The set of users being managed by the authorization policy cannot be specified by attribute filtering.

If the Hierarchy Aware option is selected, then the organization and role hierarchies are taken into account when determining the data security.

15.3.1.4 Default Authorization Policies

There are two default authorization policies for the user management feature. Users are not allowed to modify or delete these policies. 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, Full Name, and Display Name attributes. If these attributes are not provided, the user might not be fully viewable or editable.

The following table lists the default authorization policy details for user management:

Policy Name

Assignee

Functional Security

Data Security

Description

User Management Administration Policy:

System Administrators and Identity User Administrators roles

The permissions include:

Change User Password

Create User

Delete User

Evaluate Access Policies

Modify OIM Account Status

Modify User Profile

Modify User Proxy Profile

Modify User Status

Provision Resource to User

Search User

View User Details

View User Requests

Note: The Modify User Profile and View User Details have associated attribute settings. For both the permissions, the attribute setting is All Attributes.

All Users organization

Assignee must be a member of the User's Organization: No

Hierarchy Aware: Yes

Allows users with the SYSTEM ADMINISTRATORS or IDENTITY USER ADMINISTRATORS role to access all User Management actions

User Management Search Policy

Request Template Administrators, Request Administrators, Approval Policy Administrators, and Reconciliation Administrators roles

The permissions are:

Search Users

View User Details: This has associated attribute settings. They are:

Display Name, First Name, Full Name, GUID, Last Name, Organization, and User Login

All Organizations

Assignee must be member of the User's Organization: No

Hierarchy Aware: Yes

Allows users with the REQUEST ADMINISTRATORS, RECONCILIATION ADMINISTRATORS, REQUEST TEMPLATE ADMINISTRATORS, or APPROVAL POLICY ADMINISTRATORS roles to search based on GUID and User Login

User Management All Users Policy

ALL Users role

The permission is:

View User Details: This has associated attribute settings. They are:

Display Name, First Name, Full Name, GUID, Last Name, Organization, and User Login

All Organizations

Assignee must be member of the User's Organization: No

Hierarchy Aware: Yes

Allows users with the ALL USERS role to access all User Management actions

User Management policies for Managers

ALL Users role

The permissions are:

Search User

View User Details

All Organizations

Assignee must be member of the User's Organization: No

Hierarchy Aware: Yes

Allows managers to search and view their reportees

15.3.2 Authenticated User Self Service

Authorization policies are used to control the following areas of authenticated self service:

- Authorization for Profile Attributes

- Authorization for Role Requests

- Authorization for Resource Requests

- Authorization for Proxies

- Default Authorization Policies

See Also:

Chapter 8, "Managing Profile", Chapter 9, "Managing Tasks", and Chapter 10, "Managing Requests" for information about the authenticated user self service feature

15.3.2.1 Authorization for Profile Attributes

The attributes displayed on the My Profile page of Oracle Identity Manager Self Service are controlled by using the VIEW_USER_DETAILS and MODIFY_USER_DETAILS privileges from the Self Service User Management OES authorization policies. If multiple policies are applicable, then the list of attributes on which the user has permissions is a union of the attributes determined by individual policies.

By default, the All Users and System Administrators roles have permissions to view and modify a set of attributes. The All users and System Administrators roles have permissions to view the following attributes:

Email, Display Name, First Name, Last Name, Locale, Middle Name, Telephone Number, Time Zone, User Login, Manager, Identity Status, and Account Status

The All users and System Administrators roles have permissions to modify the following attributes:

Email, Display Name, First Name, Last Name, Locale, Middle Name, Telephone Number, Time Zone, and User Login

If the user has view and modify privileges for an attribute, then the attribute is displayed as editable on the My Profile page. If the attribute has view permission only, then it is displayed as read-only. The request to modify self profile is submitted by using the Modify Self Profile request template. The request dataset for this request template is the same as that for the Modify User request template.

See Also:

"Configuring Requests" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for detailed information about requests models, request templates, and request datasets

To display additional attributes on the user's profile:

1. Create a custom self service authorization policy with view and/or modify user profile permission having default or custom additional attributes. See "Creating Custom Authorization Policies" for information about creating custom authorization policies.

2. Assign the custom authorization policy to the All Users and System Administrators roles because the administrator user does not have All Users role by default.

3. If the additional attribute is set to modify user profile permission in the policy, then update the request dataset for the Modify Self Profile, that is, ModifyUserDataset.xml to include the attribute. The entry in dataset is made for the attribute to be rendered on the Modify Self Profile page.

Note:

Ensure that the additional attribute has the visible property set.

15.3.2.2 Authorization for Role Requests

There is no permission defined for requesting and viewing roles as self service operations. However, while requesting for roles, only those request templates are displayed that the user is authorized to access. The request management feature controls this. While searching for roles during the request operation, the user is allowed to select from only those roles that the user is authorized to search and view. This is controlled by role management policies.

The roles available for the user in the list of roles on the Request Roles page are the result of intersection of the roles provided in the request template and roles that the user has search permission for. For example, if the request template has roles Role1, Role2, and Role3 and the user has search permission on Role2 and Role3, then Role2 and Role3 are displayed in the list of roles. Similarly, if the user has search permission over Role1, Role2, and Role3 and the request template has roles Role2 and Role3, then Role2 and Role3 are displayed in the list of roles.

The user can request for all the roles for which the user has search permission. This is controlled by general authorization policy defined by role management. While creating a request for a role, the user must search and select the roles.

15.3.2.3 Authorization for Resource Requests

There is no permission defined for requesting and viewing resources as self service operations. However, for requesting and viewing resources, the resource must be configured so that self requesting for that resource is allowed. This is done by selecting the Self Request Allowed option in the Resource Objects form in Oracle Identity Manager Design Console.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the Resource Objects form in Oracle Identity Manager Design Console

15.3.2.4 Authorization for Proxies

To add, modify, and remove proxy operations, authorization checks are required in the authenticated self service APIs along with a new MODIFY_SELF_USER_PROXY_PROFILE privilege in the default authorization policy for self service user management. The authenticated self service API first checks for this privilege. If the user is authorized to perform the proxy operation, then the authenticated self service API calls the corresponding APIs for user management.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about Oracle Identity Manager APIs

The Modify Self User Proxy Profile permission is required to allow adding, modifying, and removing proxies.

15.3.2.5 Default Authorization Policies

The following table lists the default authorization policy details for authenticated self service:

Policy Name

Assignee

Functional Security

Data Security

Description

Self Assign Roles

ALL USERS role

The permission is:

Initiate Request

None

Allows users with ALL USERS role to access the Self Assign Roles request template

Self De-Provision Resource

ALL USERS role

The permission is:

Initiate Request

None

Allows users with ALL USERS role to access Self Modify Provisioned Resource request template

Self Modify Provisioned Resource

ALL USERS role

The permission is:

Initiate Request

None

Allows users with ALL USERS role to access Self Remove Roles request template

Self Remove Roles

ALL USERS role

The permission is:

Initiate Request

None

Allows users with ALL USERS role to access Self Assign Roles request template

Self Service User Management All Users Policy

ALL USERS and SYSTEM ADMINISTRATORS roles

The permissions are:

Modify Self User Proxy Profile

Modify User Profile: This has associated attribute settings. They are Display Name, Email, First Name, Last Name, Locale, Middle Name, Telephone Number, Time Zone, and User Name Preferred Language.

View User Details: The associated attribute settings are Account Status, Display Name, Email, First Name, Identity Status, Last Name, Locale, Manager, Middle Name, Password Expire Date, Password Expired, Password Warn Date, Password Warned, Telephone Number, Time Zone, User Login, and User Name Preferred Language.

None

Allows all users to access certain Self Service User Management actions

Self Request Resource

ALL USERS role

The permission is:

Initiate Request

None

Allows users with ALL USERS role to access Self-Request Resource request template

15.3.3 Role Management

The components of the authorization policies defined for the role management feature and the default authorization policy for this feature are described in the following sections:

- Assignee

- Functional Security

- Data Security

- Default Authorization Policies

See Also:

Chapter 12, "Managing Roles" for information about the role management feature

15.3.3.1 Assignee

The assignee of the policy can be a role or a set of roles.

15.3.3.2 Functional Security

Multiple privileges are defined for the role management feature. The privileges do not support fine-grained attribute-level controls.

15.3.3.3 Data Security

For the role management feature, data security is defined as the list of roles the assignee will have privileges over.

The Assignee Must Be Member of condition restricts the grant to assignees that are also members of the role being granted privileges over.

The Hierarchy Aware setting takes the role hierarchies into account when determining the data security.

15.3.3.4 Default Authorization Policies

The default authorization policy defined for this feature cannot be modified or deleted by users. The policies are describes in the following table:

Policy Name

Assignee

Functional Security

Data Security

Description

Role Management Administration Policy

System Administrators and ROLE ADMINISTRATORS roles

The permissions are:

Create Role

Create Role Category

Delete Role

Delete Role Category

Modify Role

Modify Role Category

Modify Role Hierarchy

Modify Role Membership

Search for Role

Search for Role Categories

View Role Category Detail

View Role Detail

View Role Membership

All Roles

This is the predefined authorization policy associated with the ROLE ADMINISTRATORS and SYSTEM ADMINISTRATORS roles.

Role Management All Users Policy

ALL USERS role

The permissions are:

Search for Role

Search for Role Categories

View Role Detail

View Role Category Detail

All Roles, in which the authorization is applied to users belonging to roles

Selected Roles, in which you can select the roles that the user must be a member of for this authorization

This is the predefined authorization policy associated with the ALL USERS role.

Role Management Role Owner Policy

ALL USERS role

The permissions are:

Delete Role

Modify Role

Modify Role Hierarchy

Modify Role Membership

Search for Role

Search for Role Categories

View Role Category Detail

View Role Detail

View Role Membership

All Roles that the assignee is the owner of.When a user creates a role, the person with the role created will become the role owner.

This is the predefined authorization policy to enable role owners to have control of their roles.

Role Management Approval and Request Policy

APPROVAL POLICY ADMINISTRATORS, REQUEST TEMPLATE ADMINISTRATORS roles, and REQUEST ADMINISTRATORS roles

The permissions are:

Search for Role

Search for Role Categories

View Role Category Detail

View Role Detail

All Roles

This is the predefined authorization policy associated with the APPROVAL POLICY ADMINISTRATORS, REQUEST ADMINISTRATORS, and REQUEST TEMPLATE ADMINISTRATORS roles.

Role Management Delegated Administration Policy

ROLE ADMINISTRATORS role

The permissions are:

Modify Role Membership

Search for Role

Search for Role Categories

View Role Category Detail

View Role Detail

View Role Membership

All Roles

This policy can be used as an example for the Delegated Role Administrator persona. You can change the assignee and the data constraint, if required.

Role Management Hierarchy Administration Policy

ROLE ADMINISTRATORS role

The permissions are:

Modify Role

Modify Role Hierarchy

Search for Role

Search for Role Categories

View Role Category Detail

View Role Detail

View Role Membership

All Roles

This policy can be used as an example for the Role Hierarchy Administrator persona. You can change the assignee and the data constraint, if required.

15.3.4 Authorization Policy Management

Access to the authorization policy management feature is controlled by a default authorization policy. This policy grants the users who belong to the System Administrators role to perform authorization policy operations, such as searching authorization policies, and creating, modifying, and deleting custom authorization policies.

Note:

The delete or disable action is controlled by feature-specific UI code, which calls AuthorizationService API to find out whether the user is allowed to perform that action. If the user has the permission, then under Action list on the left pane of the UI, the user can see Delete or Disable options enabled.

The details of the default authorization policy for this feature is the following:

- Policy Name: Authorization Management Administration Policy

- Assignee: System Administrators role

- Functional security: The supported permissions are:

- Create Authorization Policies

- Delete Authorization Policies

- Modify Authorization Policies

- Search Authorization Policies

These privileges do not support fine-grained attribute-level controls.

- Data security: This authorization policy does not support any data security. Anybody with the privileges to manage authorization policies can manage any and all authorization policies.

15.3.5 User Management Configuration

The default authorization policy for the user management configuration feature allows users with the System Administrators and USER CONFIGURATION ADMINISTRATORS roles to access all user management configuration operations. This policy has the following details:

See Also:

"Configuring User Attributes" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the user management configuration feature

- Policy name: User Management Configuration Administration Policy

- Assignee: System Administrators and USER CONFIGURATION ADMINISTRATORS roles

- Functional security: The permissions are:

- Add Category

- Add Derived Attributes

- Create Attribute

- Delete Attribute

- Delete Category

- Set Search Attributes

- Set Search Attributes

- Update Attribute

- Update Category

These permissions do not support fine-grained attribute-level controls.

- Data security: None

- Description: This policy allows users with the SYSTEM ADMINISTRATORS or USER CONFIGURATION ADMINISTRATORS roles to access all user management configuration actions.

Note:

When the user is authorized to view all attributes on the pages to create and modify users, if an UDF is created through User Management Configuration, then the UDF is displayed in the pages to create and modify users.

15.3.6 Reconciliation Management

The components of the authorization policies defined for the reconciliation management feature and the default authorization policy for this feature are described in the following sections:

- Assignee

- Functional Security

- Data Security

- Default Authorization Policy

See Also:

"Managing Reconciliation Events" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager and Chapter 4, "Deployment Configurations" for information about the reconciliation feature

15.3.6.1 Assignee

The assignee of the policy can be a role or a set of roles.

15.3.6.2 Functional Security

The reconciliation management feature defines multiple privileges from the authorization policy management area. These privileges do not support fine-grained attribute-level controls.

15.3.6.3 Data Security

This authorization policy does not support any data security. A user with the privileges to manage reconciliation events can manage all reconciliation events.

15.3.6.4 Default Authorization Policy

The following table lists the default authorization policies for the reconciliation management feature:

Policy Name

Assignee

Functional Security

Data Security

Description

Reconciliation Management Administration Policy

SYSTEM ADMINISTRATORS and RECONCILIATION ADMINISTRATORS roles

The permissions include:

Assign

Bulk Action

Create Act

Create User

Link Act

Link User

Search

View Event Details

These permissions do not support fine-grained attribute-level controls.

None

Allows users with the RECONCILIATION ADMINISTRATORS or SYSTEM ADMINISTRATORS role to access all reconciliation management actions

Reconciliation API Policy

SYSTEM ADMINISTRATORS and RECONCILIATION ADMINISTRATORS roles

The permissions are:

Create Reconciliation Event

Delete detected Accounts

Get Missing Accounts

Ignore Event

Link Event to Resource for user

Link Event to User

Process Reconciliation Event

These permissions do not support fine-grained attribute-level controls.

None

Allows users with the RECONCILIATION ADMINISTRATORS or SYSTEM ADMINISTRATORS role to access all reconciliation management actions

15.3.7 Scheduler

The default authorization policy for the scheduler feature allows users with the System Administrators and SCHEDULER ADMINISTRATOR roles to access all scheduler operations. This policy has the following details:

See Also:

"Managing Scheduled Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the Scheduler feature

- Policy Name: Scheduler Administration Policy

- Assignee: System Administrators and SCHEDULER ADMINISTRATOR roles

- Functional security: The permissions are:

- Job Create

- Job Delete

- Job Disable

- Job Enable

- Job Filter

- Job Modify

- Job pause

- Job Resume

- Job run now

- Job Search

- Job stop

- Reset Status

- Scheduler Search

- Scheduler Start

- Scheduler Stop

- Trigger Create

- Trigger Delete

- Trigger Modify

These permissions do not support fine-grained attribute-level controls.

- Data security: None

- Description: Allows users with the SYSTEM ADMINISTRATORS or SCHEDULER ADMINISTRATORS role to access all scheduler actions.

15.3.8 Request Template Management

Any user with the REQUEST TEMPLATE ADMINISTRATORS role has access to all management operations related to request templates, such as creating, deleting, modifying, and searching request templates. For information about the default authorization policy, see "Request Creation By Using Request Templates".

15.3.9 Request Creation By Using Request Templates

Each request template can be associated with a set of roles. Only the users with any of these roles are able to create a request by using this template. When a new request template is created with a list of associated roles, a new authorization policy is created internally. In addition, if the role association with any of the existing request templates is modified (adding new roles or removing existing roles), then the existing authorization policy for this template is modified.

See Also:

Chapter 17, "Managing Request Templates" for information about creating and managing request templates for request creation

The default authorization policy for creating requests by using request template allows users with the REQUEST TEMPLATES ADMINISTRATORS role to access all operations related to request templates. The policy has the following details:

- Policy name: Request Template Administration Policy

- Assignee: REQUEST TEMPLATE ADMINISTRATORS role

- Functional security: The permissions are:

- Create

- Delete

- Modify

- Search

These permissions do not support fine-grained attribute-level controls.

- Data security: None

- Description: Allows users with the REQUEST TEMPLATE ADMINISTRATORS or SYSTEM ADMINISTRATORS role to access all request template actions.

15.3.10 Approval Policy Management

The default authorization policy for the approval policy management feature allows users with the APPROVAL POLICY ADMINISTRATORS role to access all approval policy management operations. This policy has the following details:

See Also:

Chapter 18, "Managing Approval Policies" for information about the approval policy management feature

- Policy name: Approval Policy Management Policy

- Assignee: APPROVAL POLICY ADMINISTRATORS role

- Functional security: The permissions are:

- Create

- Delete

- Modify

- Search

These permissions do not support fine-grained attribute-level controls.

- Data security: None

- Description: Allows users with the APPROVAL POLICY ADMINISTRATORS or SYSTEM ADMINISTRATORS role to access all approval policy management actions.

15.3.11 Notification Management

The default authorization policy for the notification management feature allows users with the NOTIFICATION TEMPLATE ADMINISTRATORS role to access all notification management operations. This policy has the following details:

See Also:

"Managing Notification Templates" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the notification management feature

- Policy Name: Notification Management Administration Policy

- Assignee: System Administrators and NOTIFICATION TEMPLATE ADMINISTRATORS roles

- Functional security: The permissions are:

- Add Locale

- Create

- Delete

- Filter

- Lookup

- Modify

- Remove Locale

- Search

These permissions do not support fine-grained attribute-level controls.

- Data security: None

- Description: Allows users with SYSTEM ADMINISTRATORS or NOTIFICATION TEMPLATE ADMINISTRATORS role to access all notification template management actions.

15.3.12 System Properties

The default authorization policy for the system properties feature allows users with the System Administrators and SYSTEM CONFIGURATION ADMINISTRATORS roles to access all operations related to system properties. This policy has the following details:

See Also:

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

- Policy name: System Properties Administration Policy

- Assignee: System Administrators and SYSTEM CONFIGURATION ADMINISTRATORS roles

- Functional security: The permissions include:

- Create

- Delete

- Filter

- Lookup

- Modify

- Search

These permissions do not support fine-grained attribute-level controls.

- Data Constraints: None

- Description: Allows users with the SYSTEM ADMINISTRATORS or SYSTEM CONFIGURATION ADMINISTRATORS role to access all system properties actions

15.3.13 Diagnostic Dashboard

The default authorization policy for the Diagnostic Dashboard feature allows users with the System Administrators role to access the diagnostic dashboard. This policy has the following details:

See Also:

"Working With the Diagnostic Dashboard" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the Diagnostic Dashboard

- Policy name: Diagnostic Dashboard Policy

- Assignee: System Administrators role

- Functional security: The Manage Failed Tasks permission without any fine-grained attribute-level controls

- Data constraints: None

- Description: Allows users with the SYSTEM ADMINISTRATORS role to access the Diagnostic Dashboard

15.3.14 Plug In

The default authorization policy for the Plug In feature allows users with the PLUGIN ADMINISTRATOR role to register unregistered policies. This policy has the following details:

See Also:

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

- Policy name: Plugin Administrator Policy

- Assignee: PLUGIN ADMINISTRATOR and SYSTEM ADMINISTRATOR role

- Functional security: The permissions are:

- Register Plug In

- Unregister Plug In

These permissions do not support fine-grained attribute-level controls.

- Data constraints: None

- Description: Allows users with the PLUGIN ADMINISTRATORS or SYSTEM ADMINISTRATORS role to register and unregister plugins

16 Managing Access Policies

Access policies are a list of roles and the resources with which roles are to be provisioned or deprovisioned. Access policies are used to automate the provisioning of target systems to users. This is explained with the help of the following example:

A user belongs to multiple roles created in Oracle Identity Manager. Suppose a role Role1 have membership rule assigned to it. Membership rules can be designed based on the organization that the user belongs to, such as "Organization Name = "Org1". Roles can have access policies assigned to them. An access policies states which resource would be provisioned and/or denied to a role when the access policy is applicable. Therefore, when a user is created in the Org1 organization, it satisfies a membership rule and grants the Role1 role to the user. This in turn triggers the access policy assigned to the role and then provisions or denies the resources mentioned in the access policy.

This chapter describes how to create and use access policies for users and resources in Oracle Identity Manager. It contains the following sections:

- Terminologies Used in Access Policies

- Features of Access Policies

- Creating Access Policies

- Managing Access Policies

- Provisioning Multiple Instances of the Same Resource via Access Policy

16.1 Terminologies Used in Access Policies

The following terminologies are associated with access policies:

Resource

A resource is a logical entity in Oracle Identity Manager that can be provisioned to a user or an organization in Oracle Identity Manager. For example, Microsoft Active Directory (AD), Microsoft Exchange, SAP, UNIX, and Database is modeled as a resource in Oracle Identity Manager.

Resources are templated definitions that are associated with one or more workflows called Provisioning Process in Oracle Identity Manager, which model the lifecycle management, such as how to provision, revoke, enable, and disable.

Resources also have entities called forms associated with them. Forms represent a collection of attributes associated with the resource. For instance, a form associated with AD server includes attributes such as SAM Account Name, Common Name, and User Principal Name. Forms also contain an attribute of type IT Resource (see "IT Resource Type" for details).

Resources can be marked Allow Multiple, which would multiple instances of a resource to be provisioned to a user or an organization.

Account

Accounts are actual instances of a resource that are created and provisioned to a user or organization in Oracle Identity Manager. For example, an e-mail account on an Exchange server is an account (instance) of resource type Exchange.

Accounts have specific values for the attributes of the associated form.

IT Resource Type

IT resource type is a logical entity in Oracle Identity Manager used to model a physical target and all its attributes including (but not limited to) the connectivity information and the credentials required to connect to the physical computer. For example, IT resource type AD server is used to model an actual AD server.

IT Resource Instance

These are actual instances of specific IT resource type that represent the actual physical target. They also have specific values for all the attributes of the physical target, such as IP address, port, user name, and password. Two physical AD servers in a deployment are represented by two instances of IT resource type AD Server.

Account Discriminator

Account discriminator is a collection of attributes on a form that uniquely identify the logical entity on which accounts are created. This term is sometimes loosely referred to as a target. For instance, for an AD server, an account discriminator can be a combination of AD server (an attribute of type IT Resource) and Organization Name.

Typically account discriminators are attributes of type IT Resource.

Attributes are marked as account discriminators by setting the Account Discriminator property of a Form field to True.

16.2 Features of Access Policies

This section describes the various features offered by the policy engine in the following sections:

- Provisioning Options

- Revoking the Policy

- Denying a Resource

- Evaluating Policies

- Access Policy Priority

- Access Policy Data

- Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator

16.2.1 Provisioning Options

Whenever an access policy is applied, provisioning of resources can take place in any one of the following ways:

- The resources are either directly provisioned to the user without any request being generated.

- A request is created, and provisioning of resources is subject to request approval.

Using the Administrative and User Console, you can specify whether you want to create the access policy with request approval or without request approval.

In an access policy with request:

- The default process form for access policy is supported. This means that the data entered for default process form while creating access policy is used to populate request dataset.

- Mandatory fields of request dataset must be populated by one of the following:

- Process form defaults of access policy while defining access policy: This is because process form access policy defaults are used to populate corresponding request dataset.

- Prepopulate adapters defined for request dataset.

- Default data in the request dataset.

- Access policy-based request is not created if all mandatory fields of request dataset are not populated by any one of process form defaults, prepopulate adapters, or default data in request dataset.

- If request has already been created for a user for a specific resource and it is NOT in one of the following status, then new request is not created for the same user and resource combination:

- Request Closed

- Request Completed

- Request Withdrawn

- Request Failed

- Template Approval Rejected

- Request Approval Rejected

- Operation Approval Rejected

16.2.2 Revoking the Policy

Oracle Identity Manager access policies are not applied to subroles. Policies are only applied to direct-membership users (that is, users who are not in subroles) in the roles that are defined on the access policies. You can specify if a resource in a policy must be revoked when the policy no longer applies. If you do so, then these resources are automatically revoked from the users by Oracle Identity Manager when the policy no longer applies to the users.

16.2.3 Denying a Resource

While creating an access policy, you can select resources to be denied along with resources to be provisioned for roles. If you first select a resource for provisioning and then select the same resource to be denied, then Oracle Identity Manager removes the resource from the list of resources to be provisioned. If two policies are defined for a role in which one is defined to provision a resource and the other is defined to deny the resource, then Oracle Identity Manager does not provision the resource irrespective of the priority of the policies.

16.2.4 Evaluating Policies

In Oracle Identity Manager, access policies are evaluated during the run of the Evaluate User Policies scheduled job. By default, this task is disabled and scheduled to run every 30 minutes. You must enable the Evaluate User Policies scheduled job and set it to run every 10 minutes. See the "Predefined Scheduled Tasks" section in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about the Evaluate User Policies scheduled task.

Access Policies can be evaluated in the following scenarios:

- When a user is made a part of a role or removed from a role
The policy for the user is evaluated only when the Evaluate User Policies scheduled job is run.

- If the retrofit flag is set for the policy
These evaluations do not happen immediately after the action. Instead, they happen during the next run of the Evaluate User Policies schedule task. The evaluations can happen in the following scenarios:

- Policy definition is updated so that the retrofit flag is set to ON. Policies are evaluated for all applicable users.

- A role is added or removed from the policy definition. Policies are evaluated only for roles that is added or removed.

- A resource is added, removed, or the Revoke If No Longer Applies flag value is changed for the resource.
In earlier releases of Oracle Identity Manager, when the Revoke if no longer applies option is selected in an access policy and the policy is no longer applicable, both the account and entitlements (child records) associated with the access policy are revoked. However, when the flag is not selected and the policy is no longer applicable, the account remains and the entitlements are revoked. Therefore, entitlements are revoked irrespective of the value of the Revoke if no longer applies option set for the policy when policy ceases to apply.

In Oracle Identity Manager 11g Release 1 (11.1.1), the Revoke if no longer applies option works not only at the account level, but also at the entitlements level so that the entitlements are not revoked if the option is not selected. For this enhancement to work, you must set the value of the XL.AccessPolicyRevokeIfNoLongerAppliesEnhancement system property to true.

When the value of the XL.AccessPolicyRevokeIfNoLongerAppliesEnhancement system property is true, then the Revoke if no longer applies option is changed to Revoke resource and entitlements if no longer applies. When the value of this system property is false, then the Revoke if no longer applies option remains the same. By default, both the options are selected. For more information about this system property, see "Administering System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

- When policy data is updated or deleted. This includes both parent and child form data. Policies are evaluated for all applicable users.

16.2.5 Access Policy Priority

Policy priority is a numeric field containing a number that is unique for each access policy you create. The lower the number, the higher is the priority of the access policy. For example, if you specify Priority =1, it means that the policy has the highest priority. When you define access policies through Oracle Identity Manager Administrative and User Console, the value 1 is always added to the value of the current lowest priority and the resultant value is automatically populated in the Priority field. Changing this value to a different number might result in readjusting the priority of all the other access policies, thus ensuring that the priorities remain consistent. The following actions are associated with the priority number:

- If the priority number entered is less than 1, then Oracle Identity Manager will change the value to 1 (highest priority).

- If the priority number entered is greater than M, in which M is the current lowest priority, then Oracle Identity Manager will specify the value as less than or equal to M+1.

- Two access policies cannot have the same priority number. Therefore, assigning an already existing priority number to an access policy will lower the priority by 1 for all policies of lesser priority.

Conflicts can arise from multiple access policies being applied to the same user. Because a single instance of a resource is provisioned to the user through access policies, Oracle Identity Manager uses the highest priority policy data for a parent form. For child forms, Oracle Identity Manager uses cumulative records from all applicable policies.

16.2.6 Access Policy Data

There are multiple ways in which process form data is supplied for resources during provisioning. The following is the order of preference built into Oracle Identity Manager:

1. Default values from the form definition

2. Organization defaults

3. Values obtained through data flow from dataset to process form

4. Prepopulate adapters

5. Access policy data if resource is provisioned because of a policy

6. Data updated by Process Task or Entity Adapters

If a given option is available, then the rest of the options that are at a lower order of preference are overridden. For example, if Option 4 is available, then Options 3, 2, and 1 are ignored.

16.2.7 Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator

In earlier releases of Oracle Identity Manager, access policies can be used to manage only a single account for a resource object. In other words, if you already have resource provisioned to user (account has been created in the target system) and if another instance of the same resource is to be provisioned to the same user via access policy, then it is not possible in earlier releases of Oracle Identity Manager. To achieve the functionality of provisioning multiple instances of resource to a user, prior to access policy enhancement in Oracle Identity Manager 11g Release 1 (11.1.1), you must clone the connector that represents the target system in Oracle Identity Manager. Cloning of connector was error prone needed lot of effort for testing/maintenance of cloned resource. Access Policy enhancement done for provisioning of multiple instances of resource in Oracle Identity Manager 11g Release 1 (11.1.1) saves the time and effort on cloning connectors.

A target system, such as UNIX server, Active Directory (AD) server, database, SAP, or JD Edwards, is the external system to Oracle Identity Manager that must be provisioned to users in Oracle Identity Manager. The target system is represented by an entity called resource in Oracle Identity Manager. The server on which target system is installed is represented by IT resource in Oracle Identity Manager. And the login credentials provided to user accessing this target system is represented by an account in Oracle Identity Manager. A user can have multiple accounts on a single target system. For example, one account can be a service (administrator) account and another a regular account. Therefore, it is mandatory to have two accounts for a same user in a single target system. In addition, it is possible to have different instances of target system, such as multiple UNIX servers, database servers, and AD servers. As a result, it is required to create accounts on each instance of the target system for the same user. For implementation details, see "Creating Separate Accounts for the Same User and Same Resource on a Single Target System".

In Oracle Identity Manager 11g Release 1 (11.1.1), access policies can provision multiple accounts in the same target system as well as a single account in multiple instance of the same target system. While evaluating access policies and provisioning resources to user, Oracle Identity Manager checks if the resource has already been provisioned to the user or not. This is determined by checking the resource key (OBJ_KEY) of the resource provisioned to user. To have multiple instances to be provisioned through access policy, another criteria called account discriminator along with OBJ_KEY is required to distinguish the multiple instances of the same resource. Therefore, access policy checks the resource key as well as account discriminator to decide if the resource has been provisioned or not.

The account discriminator is a field on a process form (account data) that distinguishes two accounts of the same user, which can be present on the same target system or different target systems. For example:

- If user Jane.Doe is to be provisioned two accounts on two different UNIX servers, then IT resource can be used as account discriminator.

- If user John.Doe is to be provisioned two accounts on the same database instance, then distinct login IDs can be used as account discriminator.

If there are multiple resources that need to be provisioned because of access policy evaluation, a single bulk request is created. The bulk request requires a single request-level approval, but multiple operation-level approvals for which approver can approve each request individually at operation level.

See Also:

- "Bulk Requests and Child Requests" for information about bulk requests

- "Approval Levels" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about various levels of request approval

- "Provisioning Multiple Instances of the Same Resource via Access Policy" for the steps to provision data from multiple target systems

16.3 Creating Access Policies

You can define an access policy for provisioning resources to users who have roles defined in the policy by using the Access Policy Wizard.

To create an access policy:

1. Login to the Oracle Identity Manager Administrative and User Console, and navigate to Advanced Administration.

2. To open the Create Access Policies page, under Policies, click Create Access Policy.

3. Enter information in the required fields indicated with an asterisk (*), such as access policy name and description.

Note:

The following special characters are not allowed in the access policy name:

Semicolon (;)

Hash (#)

Percentage (%)

Equal to (=)

Bar (|)

Plus (+)

Comma (,)

Forward slash (/)

Back slash (\)

Single quote (')

Double quote (")

Less than (<)

Greater than (>)

4. For the Provision field, select any one of the following options:

- Without Approval: Selecting this option creates the access policy without request approval. The resources are directly provisioned to the user without any request being generated.

- With Approval: Selecting this option creates the access policy with request approval. On creating the access policy, a request is created, and provisioning of resources is subject to request approval.

5. Select Retrofit Access Policy to retrofit this access policy when it is created.

Note:

If you select Retrofit Access Policy, then the access policy is applied to all existing roles that you select in Step 13 of this procedure, after the Evaluate User Policies job runs.

If you do not select this option, then existing role memberships are not taken into consideration.

6. Click Continue.
The Create Access Policy - Step 2: Select Resources (to provision) page is displayed.

7. Specify the resource to be provisioned for this access policy.
Search for resources by using the filter search menu.

- Select the name of the resource from the results table, and then click Add.

- The names of the desired resources to provision appear in the Selected list. If you want to create an access policy that only denies resources, click Continue without selecting a resource.

- To unassign the selected resources, highlight the resource in the Selected list and click Remove.

8. Click Continue.
If there is a form associated with this resource, the subsequent pages display the required fields. Otherwise, the Create Access Policy - Step 2: Select Resources to Revoke page is displayed. It is recommended that you do not specify policy defaults for passwords and encrypted attributes.

9. Specify whether or not access policies are to be revoked if they no longer apply.
Select the check boxes for the resources you want to revoke automatically from the results table.

10. Click Continue.
The Create Access Policy - Step 3: Selected Resources (to deny) page is displayed.

11. Use this page to select resources to be denied by this access policy.
To select resources to be denied:

1. Select the resources from the results table.

2. Click Add to place the resource in the Selected list.
You must select at least one resource to deny if you have not selected any resources to be provisioned. Selecting the same resources to be denied as to be provisioned will automatically unassign them from the resources to be provisioned selection.

Similarly, in Step a, assigning the same resources to be provisioned as you have already selected to be denied will automatically remove them from the resources to be denied selection. You can remove the resources that were selected to be denied. You do this by selecting those resources from the Selected list, and clicking Remove.

3. Click Continue.

The Create Access Policy - Step 4: Select Roles page is displayed.

12. Use the Create Access Policy - Step 4: Select Group page to associate a group with the access policy.

13. To associate a role with this access policy:

- Select the role from the results table, and then click Add. You must select at least one role. The names of the selected roles appear in the Selected list.

- You can delete the role name by clicking Remove.

14. Click Continue.
The Create Access Policy - Step 5: Verify Access Policy Information page is displayed.

15. If you want to modify any of the selections you made in the preceding steps of this procedure, then click Change to go to the corresponding page of the wizard. After making the required modifications, click Continue to return to the Step 5: Verify Access Policy Information page.

16. Click Create Access Policy to create the access policy.

Note:

When you create an access policy on a resource having a process form with Password field, the password policy is not evaluated. For information about password policies, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

16.4 Managing Access Policies

You can use Oracle Identity Manager Administrative and User Console to modify information in existing access policies.

To manage access policies:

1. Click Manage Access Policies under the Policies menu.
The Manage Access Policies page is displayed.

Use the menu in the search criteria field to select an access policy attribute. You can use the asterisk (*) wildcard character to search for all access policy instances that have any value for the attribute selected. Click Search Access Policies.

The Manage Access Policies page is displayed with your search results.

2. To view the details of the Access Policy you want, click Access Policy Name.
The Access Policy Details page is displayed.

To make modifications to this access policy, use the Change link at the end of each selection category.

3. After you make the required modifications, click Update Access Policy.
This access policy is updated, and the updated information is displayed on the Access Policy Details page.

16.5 Provisioning Multiple Instances of the Same Resource via Access Policy

Provisioning multiple instances of the same resource via access policy by using account discriminator involves the following:

- Creating Separate Accounts for the Same User and Same Resource on a Single Target System

- Enabling Multiple Account Provisioning

- Provisioning Multiple Instances of a Resource to Multiple Target Systems

- Limitation of Provisioning Multiple Instances of a Resource via Access Policy

16.5.1 Creating Separate Accounts for the Same User and Same Resource on a Single Target System

Two distinct accounts can be created for the same user and same resource on a single target system via access policy. For example, it is required to create two accounts, a user account and service account on a single AD instance. The Active Directory target system is represented by the AD User resource in Oracle Identity Manager. This is implemented in the following way:

1. Create a AD User resource.

2. Create the user, such as JohnD.

3. In the process form, mark UD_ADUSER and UD_ADUSER_UID as the discriminator field so that two distinct accounts have different login IDs.

4. Create two access policies as follows:

- For regular account:
Access policy name: AP1

Associated to role: Role1

Resource to provision: AD User

Process form having Discriminator field: User ID (UD_ADUSER_UID)

Default value in access policy: Account1

- For service account:
Access policy name: AP2

Associated to role: Role2

Resource to provision: AD User

Process form having Discriminator field: User ID (UD_ADUSER_UID)

Default value in access policy: Account2

Note:

You must create a prepopulate adapter associated with dataset to generate the values for User ID so that unique values are generated for this field.

5. Assign Role1 and Role2 to JohnD. Note that you will not see the resource provisioned right after completion of role assignment. You must either wait for the Evaluate User Policies scheduled task to run automatically or you run this scheduled task manually.
When Role1 is assigned to JohnD, the Account1 account is created in the AD User target system via the AP1 access policy. When Role2 is assigned to JohnD, Account2 is created in AD User via AP2. Therefore, two distinct accounts can be created for the same user and same resource on a single target system via access policy.

16.5.2 Enabling Multiple Account Provisioning

By default, Oracle Identity Manager does not support multiple account provisioning. To enable multiple account provisioning:

1. Set the value of the XL.AccessPolicyMultipleResourceEnhancement system property to TRUE.
See "Predefined System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about this system property. See "Creating and Managing System Properties" in the same guide for information about setting the value of a system property.

2. Restart Oracle Identity Manager for the change in the system property to take effect.

When multiple account provisioning is enabled, you must define the appropriate account discriminator attributes. To do so:

1. Log in to the Design Console.

2. Update the process form as follows:

1. Expand Development Tools, and then double-click Form Designer.

2. Search and open the process form.

3. On the Form Designer tab, click Create New Version.

4. In the Create a New Version dialog box, enter a label in the Label field, and then click Save.

5. From the Current Version list, select the version that you created.

6. On the Properties tab, select the field that you want to designate as the discriminator field, and then click Add Property.

7. In the Add Property dialog box, select Account Discriminator as the property name, enter True in the Property Value field, and then click Save.

8. Click Make Version Active, and then click OK.

9. Click Save.

3. Run the Form Version Control (FVC) utility if you modified existing process forms. See "Using the Form Version Control Utility" for information about running the FVC utility.

16.5.3 Provisioning Multiple Instances of a Resource to Multiple Target Systems

The following are the broad-level steps to provision multiple instances of a resource object to multiple target systems via access policy:

1. Create an IT resource type by using the IT Resources Type Definition Form in the Oracle Identity Manager Design Console. For information about using this form, see "IT Resources Type Definition Form" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

2. Create multiple IT resource instances of the IT resource type that you created in step 1. For information about creating IT resources, see "Creating IT Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.
Here, IT resource instance is the account discriminator. See "Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator" for information about account discriminator.

3. Create a process form with a field of type that you created in step 1. For information about creating process forms, see "Developing Process Forms" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

4. Create a resource object. For information about creating a resource object, see "Creating a Resource Object" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

5. Create a process definition, and associate the resource object and process form. For information about creating a process definition, see "Creating a Process Definition" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

6. Create access policies associating a role and resource object. See "Creating Access Policies" for details.

When you have two instances of the same resource on different physical server, you can use access policy to provision both the instances of a resource to the same user, JohnD. This is described with the help of the following scenario:

You have tow AD instances, one hosted on server with IP as 10.151.14.82 and another hosted on server with IP 130.35.66.254. The user is to be provisioned to both the instances via access policy-based provisioning. To achieve this:

1. Create a AD User resource.

2. Create an IT resource with name ADServer1 that represents the server with IP address as 10.151.14.82.

3. Create an IT resource with name ADServer2 that represents the server with IP address as 130.35.66.254.

4. Mark the AD Server (UD_ADUSER_AD) process form field as the discriminator field.

5. Create two access policies as follows:

- For the account to be created on ADServer1:
Access policy name: AP3

Associated to role: Role3

Resource to provision: AD User

Process form having Discriminator field: AD Server (UD_ADUSER_AD)

Default value for ITResourceLookup field: ADServer1

- For the account to be created on ADServer2:
Access policy name: AP4

Associated to role: Role4

Resource to provision: AD User

Process form having Discriminator field: AD Server (UD_ADUSER_AD)

Default value for ITResourceLookup field: ADServer2

6. Assign Role3 and Role4 to the user JohnD.
When Role3 is assigned to JohnD, the account is created in the target system on ADServer1 via the AP3 access policy. When Role4 is assigned to JohnD, the account is created in the target system on ADServer2 via the AP4 access policy. Therefore, two distinct accounts are created for the same user and same resource on two different instances of the target system via access policy.

16.5.4 Limitation of Provisioning Multiple Instances of a Resource via Access Policy

Provisioning multiple instances of a resource via access policy has the following limitations:

- A single access policy cannot provision multiple instances of a resource to a user. Multiple access policies must be created to provision multiple instances of resource. You must create the same number of access policies as that of instances of same resource that is to be provisioned.

- If a resource object has a process form that has fields marked as account discriminator fields, then the value of these fields must be specified in any access policy that provisions that resource. Not doing this can result in behavior that cannot be determined, for example, provisioning of multiple accounts the next time policies are evaluated.

- If a resource object has a process form that has fields marked as account discriminator fields and if you use the access policy engine to provision this resource to one or more users, then the values of the account discriminator fields must remain constant throughout the lifecycle of the account. In other words, the values of the account discriminator fields must not be changed. This is because the access policy engine uses the resource object key and the account discriminator values to decide whether or not to provision a new account to the user.
By modifying account discriminator values, you modify the basis on which the provisioning decision had been taken. and the behavior of the access policy engine cannot be determined. Therefore, it is recommended that you do not modify account discriminator values. And the process form values of the account discriminator fields must not be changed.

- If access policies are configured with different account discriminator values, they provision different accounts to the user. A resource object of this type must have the Allow Multiple flag set. Otherwise, provisioning fails.

Note:

Account discriminator values that are different only in casing (for example, abc and aBc) are also treated as different values. With this data, two accounts are provisioned to the end user.

Consider the following scenario:Two access policies are provisioning the same resource with the same account discriminator data. The policies are applied through a request.

These two policies apply to a user, and policies are re-evaluated for the user. Here, only one resource is provisioned to the user through a request. Now, suppose request approval is in progress. In the meantime, the priorities of these two policies are swapped, which means that the higher priority policy becomes the lower one and the other becomes the higher priority policy.While the request is in progress, if policies are re-evaluated for the user, a second request is created to provision the same resource but through the current higher priority policy. This issue is not currently handled by the policy engine. To avoid this issue, you must ensure that all pending requests for a specific resource are either approved or rejected before modifying the properties of the access policy that provision the resource, especially through a request.

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:

- Adding template-level approval: You can add an additional level of approval apart from request-level and operation-level while creating the template.

- Adding restrictions: This includes:

- Adding entity restrictions: You can specify restrictions of the entity types that can be selected through the request templates. For example, a template for Provisioning Resource request type might specify a number of valid resources that can be selected by using this template. This limits the use of the template to specific type of entities in case of generic requests. For example, the template defined on provisioning request type may specify that this template can only be used for Active Directory, Exchange, and UNIX resources.

Note:

If no entity type is restricted in the template, then all the available entity types are shown to the requester while creating the request by using this template.

However, the data to be collected during various phases of the request lifecycle is controlled by request datasets. See "Step1: Creating a Request Dataset for the Resources" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about request datasets.

- Restricting data values for an attribute: If you specify a value for attributes, then the default value of the attribute is set, and the attribute is not displayed in the UI. On specifying multiple such values, the values are available to the user as List of Values (LOV), from which the user can select a value.
Attribute restriction can be of the following types:

- Specifying a default value to an attribute in the request template. During the request creation using this template, this attribute is not shown to the requester. This attribute and the corresponding value is set automatically in the request data.

- Restricting an attribute with multiple values in request template. On specifying multiple such values, the values are available to the requester as List of Values (LOV), from which the requester can select a value during the request creation by using this template.

- Restricting an attribute with no value in request template, by selecting the Do not allow users to enter values for this attribute option. This type of restriction is allowed only for the nonmandatory attributes. With this restriction, during the request creation by using this template, this attribute is not shown to the requester. This attribute will not be part of request data.

- Adding additional data collection attributes: These attributes are not associated with any entity. Data collected by using such mechanism cannot be used during request execution. However, it can be used for reporting purpose, validations on the request, and postsubmission data action handlers.
You can define new attributes in a request template that are shown to the requester during request creation in the additional data collection step. These attributes are specific to this template and are not associated with any entity.

- Assigning roles to template to restrict the use by end users: Only the members of the appropriate roles assigned to the template can create a request by using that template.

To summarize, the following are achieved by using the request template:

- The restricted entity types can be specified.

- The restricted attributes that are not required to be collected as a part of the request for the entity can be specified.

- The attribute can be restricted to one value or list of values. If only one value is specified, then the attribute is not shown to the requester while submitting the request. If a list of values is specified, then the requester has to select one value from the list of values.

- Additional data collection attributes can be specified.

- Roles can be assigned to templates to restrict the use by end users.

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:

- Creating Request Templates

- Searching and Modifying Request Templates

- Cloning Templates

- Deleting Templates

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:

- Creating a Request Template Based on the Create User Request Type

- Creating a Request Template Based on the Provisioning Resource Request Type

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.

- Request Template Name: Enter the name of the template that you want to create, for example, Create Contractor.

- Request Type: Select the type of request for which you want to create the request template, for example, Create User.

- Description: Enter a description for the request template that you are creating.

- Template Level Approval Process: Specify the approval workflow name if you want to specify an approval process for the Create User request. This is a template-level approval in addition to the request-level and operation-level approvals. For creating users for contract employees, you can specify that the HR representative, who is responsible for the recruitment of all contract employees, must approve the user creation. For more information about approval-levels, see "Approval Levels" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

See Also:

"Chapter 25: Configuring Workflows" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about default approval processes

Figure 17-1 shows the Set request template details page of the Create Request Template wizard:

Figure 17-1 The Set Request Template Details Page

Description of "Figure 17-1 The Set Request Template Details Page"

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:

Figure 17-2 The Select Attributes to Restrict Page

Description of "Figure 17-2 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:

Figure 17-3 The Set Attribute Restrictions Page

Description of "Figure 17-3 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:

Figure 17-4 The Set Additional Attributes Page

Description of "Figure 17-4 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:

Figure 17-5 The Set Template User Roles Page

Description of "Figure 17-5 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.

Figure 17-6 The Review Request Template Summary Page

Description of "Figure 17-6 The Review Request Template Summary Page"

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.

- Request Template Name: Enter the name of the request template, for example, Provision E-Business Resource.

- Request Type: Select a request type, such as Provision Resource.

Note:

The steps in the Create Request Template wizard are dynamically generated on clicking Next after providing the Request Template Basic Information in the first step of the wizard.

- Description: Enter a description for the request template that you are creating.

- Approval Process: Enter the name of the approval workflow. For information about this field, see step 4 of "Creating a Request Template Based on the Create User Request Type".

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 for 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:

Table 17-1 Default Request Templates

Request Template

Description

Assign Roles

Default template for assigning roles to users

Create User

Default template for creating users

De-Provision Resource

Default template for deprovisioning resources

Delete User

Default template for deleting users

Disable Provisioned Resource

Default template for disabling provisioned resources

Disable User

Default template for disabling users

Enable Provisioned Resource

Default template for enabling disabled resources

Enable User

Default template for enabling users

Modify Provisioned Resource

Default template for modifying provisioned resources

Modify Self Profile

Default template for modifying self profile

Modify User Profile

Default template for modifying user profiles

Provision Resource

Default template for provisioning resources

Remove from Roles

Default template for removing users from roles

Self-Register User

Default template for self registering users

Self-Request Resource

Default template for requesting resources for self

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.

Figure 17-7 Advanced Search Result for Request Templates

Description of "Figure 17-7 Advanced Search Result for Request Templates"

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:

Table 17-2 Fields in the Template Details Section

Field

Description

Request Template Name

The name of the request template, for example, Create User

Request Type

The request type, for example, Create User

Template Level Approval Process

The additional approval process, which is invoked for requests that are created using this request template.

Description

The description for the request template

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:

- Allowed Resources or Allowed Roles

- Attribute Restrictions

- Additional Attributes

- Template User Roles

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.2.1 Allowed Resources or Allowed Roles

The Allowed Resources tab or the Allowed Roles tab is displayed only if the request type is associated with a resource or a role. Figure 17-8 shows the Allowed Resources tab:

Figure 17-8 The Allowed Resources Tab

Description of "Figure 17-8 The Allowed Resources Tab"

The options available in this tab allows you to edit and delete resources or roles. To edit resources or roles:

1. Open/Edit the Request Template that you want to modify in Oracle Identity Manager Advanced Administration.

2. In the Allowed Resources tab of the request template details page, select the resource or role that you want to edit.

3. From the Actions list, select Edit. The Allowed Resources dialog box is displayed.

4. Search for the resource or role that you want to edit.

5. From the Available Resources list, select a resources or multiple resources and click Move or Move All to include the resources in the Selected Resources list.

6. Click Perform. The resource is listed in the Allowed Resources tab.

To delete a resource or role:

1. Select the resource or role that you want to delete.

2. From the Actions list, select Delete. A message box is displayed that confirms the deletion.

3. Click OK.

17.2.2 Attribute Restrictions

This tab contains the attribute restrictions, if any. Figure 17-9 shows the Attribute Restrictions tab:

Figure 17-9 The Attribute Restrictions Tab

Description of "Figure 17-9 The Attribute Restrictions Tab"

Using this tab, you can put additional restrictions on the entity types that you can select if it is associated with a generic request type. To do so:

1. Open/edit the Request Template that you want to modify in Oracle Identity Manager Advanced Administration.

2. In the upper section, select new attributes for restriction, or deselect existing attributes, which are restricted for any of the user or resource entities that have been restricted.

3. In the lower section, modify the values for restricted attributes.

4. Click Next Resource. The attributes for the next resource are displayed. If there are multiple resources restricted, then navigation to attribute restrictions across the resources is possible using the Previous Resource and Next Resource buttons.

Note:

Restrictions for approver-only attribute by using request template is not supported.

17.2.3 Additional Attributes

This tab is always displayed. Figure 17-10 shows the Additional Attributes tab:

Figure 17-10 The Additional Attributes Tab

Description of "Figure 17-10 The Additional Attributes Tab"

Using this tab, you can specify additional attributes for data collection at the template level. These attributes are collected when the user creates a request. This data cannot be used during request execution. You can add new template attributes or delete the existing template attributes.

To specify additional attributes for data collection:

1. Open/Edit the Request Template that you want to modify in Oracle Identity Manager Advanced Administration.

2. In the Attribute Name field of the Additional Attributes tab, enter a name of the attribute.

3. From the Data Type list, select a value from String, Number, Date or Boolean.

4. From the Display Type list, select the type of field, such as text field, date field, and check box, which you want to display for this attribute.

5. Click Add. The attribute is added to the Additional Attributes section.

To delete an additional attribute, select the attribute and select Delete from the Actions list.

17.2.4 Template User Roles

This tab allows you to select the roles that can be assigned to the request template. Only the users with the role are able to create requests by using the template. Figure 17-11 shows the Template User Roles tab:

Figure 17-11 The Template User Roles Tab

Description of "Figure 17-11 The Template User Roles Tab"

To select roles for assigning to the request template:

1. Open/Edit the Request Template that you want to modify in Oracle Identity Manager Advanced Administration.

2. From the Available Roles list of the Template User Roles tab, select the roles that you want to create requests by using this template.

3. Click Move or Move All to include the roles in the Selected Roles list.

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.

18 Managing Approval Policies

Approval policy is a configurable entity of request management that helps associate various request types with approval processes defined in the request service only for request-level and operation-level approvals. It associates approval workflows to be initiated at request or operation levels for a request type. You can use approval policies to associate various request types with various approval processes, which are the SOA-based workflows. Approval policies control which approval process is to be invoked based on the request data evaluation.

You can define multiple approval policies for a request type. Each approval policy is associated with an approval process. When the request is submitted, in the approval initiation phase, all the approval processes associated with the request type are picked up dynamically. Each approval policy has a priority in the backend. Each approval policy decides on what process to invoke based on approval policy priority and approval policy rule.

Approval policy priorities are based on the following:

- For request level, request type + request level

- For operation level, request type + operation level + scope, which is the specific entity associated with the request

When the request engine tries to initiate the approval workflow, it picks up all the available approval policies for that request type in the order of priority. The approval policy with highest priority is taken up and its approval policy rule is evaluated. If the evaluation fails, then the approval policy rule of the approval policy with the next priority is evaluated. If the outcome of the evaluation is true, then the corresponding approval process associated with the approval policy is selected to be the workflow for that request. For information about creating approval policy rules, see "Creating Approval Policies".

Note:

There is only one approval policy rule per approval policy. The rules can be complex, containing multiple conditions and other rules. The rules do not exist as independent entities and cannot be reused in any other approval policy. There is no default rule for an approval policy.

This chapter describes the following topics:

- Approval Selection Methodologies

- Creating Approval Policies

- Searching Approval Policies

- Modifying Approval Policies

- Modifying the Priority of an Approval Policy

- Deleting Approval Policies

Note:

Only the users that are members of the APPROVAL POLICY ADMINISTRATORS role are authorized to create, search, modify, and delete approval policies. See "Approval Policy Management" for more information about authorization for approval policies.

18.1 Approval Selection Methodologies

An approval process selection methodology is an algorithm that selects the approval workflow to be initiated. Based on the request type and the approval level, the request engine decides which methodology to be used and evaluates the approval process accordingly.

If no approvals are defined at the request level, it means that a default approval process is invoked. This default approval process is shipped with Oracle Identity Manager and is assigned to the administrator. If no approvals are defined at the operation level, it means that a default approval process is invoked. If no template-level approvals are defined, then it is assumed that no approvals are required at that level.

The following methodologies are used:

- Request-Level Methodology

- Operation-Level Methodology: Organization-Based Selection

- Operation-Level Methodology: Resource-Based Selection

- Operation-Level Methodology: Role-Based Selection

18.1.1 Request-Level Methodology

This methodology is used for all request types at the request level of approval. The determination algorithm of the request-level selection methodology is as follows:

1. Search for all the approval policies configured for the request level and for the request type with which the request is associated in ascending order of approval policy priority. If the approval policies matching this criteria are found, then:

1. Evaluate the approval policy rules associated with each approval policy to determine the approval workflow. When evaluating the approval policy rules, for the first approval policy rule whose evaluation results in true, the corresponding approval workflow associated with that approval policy is selected. If automatic approval is specified in the approval policy, then request level approval is automatically approved.

2. If none of the approval policy rules are satisfied, then it is considered that no approval workflow is configured at the request level.

2. If no approval workflow is determined, then the default request-level approval is selected.

18.1.2 Operation-Level Methodology: Organization-Based Selection

This methodology is used for all user-related request types, such as Create User, Modify User, Disable User, Enable User, and Delete User, at the operation level of approval. The determination algorithm for the organization-based selection methodology at operation level is as follows:

1. Get the user's organization entity for which request is created.

2. Search for all the approval policies configured for the operation level, for the request type associated with the request, or for all organizations in ascending order of the approval policy priority. If the approval policies matching this criteria is found, then:

1. Evaluate the approval policy rules associated with each approval policy to determine the approval workflow. When evaluating approval policy rules, for the first approval policy rule whose evaluation results in true, the corresponding approval workflow associated with that approval policy is selected. If automatic approval is specified in the approval policy, then the request is automatically approved at the operation level.

2. If none of the approval policy rules are satisfied, then it is considered that no approval workflow is configured at the operation level for this organization.

3. If no approval workflow is configured for that organization entity, then follow the organization hierarchy till either the root node or the domain boundary, which is the root organization in the organization hierarchy. Repeat step 2 for each organization node.

4. If no approval workflow is determined, then the default operation-level approval is selected.

18.1.3 Operation-Level Methodology: Resource-Based Selection

This methodology is used for all resource-related request types at the operation level of approval. The determination algorithm for the resource-based selection methodology at operation level is as follows:

1. Get the resource entity associated with the request.

2. Search for all the approval policies configured for the operation level, for the request type associated with the request, or for all resources associated with the request in ascending order of the approval policy priority. If the approval policies matching this criteria is found, then:

1. Evaluate the approval policy rules associated with each approval policy to determine the approval workflow. When evaluating approval policy rules, for the first approval policy rule whose evaluation results in true, the corresponding approval workflow associated with that approval policy is selected. If automatic approval is specified in the approval policy, then the request is automatically approved at the operation level.

2. If none of the approval policy rules are satisfied, then it is considered that no approval workflow is configured at the operation level for this resource.

3. If no approval workflow is determined, then the default operation-level approval is selected.

18.1.4 Operation-Level Methodology: Role-Based Selection

This methodology is used for all role-related request types at the operation level of approval. The determination algorithm for the role-based selection methodology at operation level is as follows:

1. Get the role entity being assigned to or removed from the user.

2. Search for all the approval policies configured for the operation level, for the request type associated with the request, or for all roles being assigned or removed in ascending order of the approval policy priority. If the approval policies matching this criteria is found, then:

1. Evaluate the approval policy rules associated with each approval policy to determine the approval workflow. When evaluating approval policy rules, for the first approval policy rule whose evaluation results in true, the corresponding approval workflow associated with that approval policy is selected. If automatic approval is specified in the approval policy, then the request is automatically approved at the operation level.

2. If none of the approval policy rules are satisfied, then it is considered that no approval workflow is configured at the operation level for this role.

3. If no approval workflow is determined, then the default operation-level approval is selected.

18.2 Creating Approval Policies

To create an approval policy:

1. In Oracle Identity Manager Advanced Administration, click the Policies tab, and then click Approval Policies. Alternatively, you can click Search Approval Policies under Policies in the Welcome page.

2. From the Actions menu on the left pane, select Create. You can also start the Create Approval Policy wizard by clicking the icon with the plus (+) sign on the toolbar. The Step 1. Set Approval Policy Details page of the Create Approval Policy wizard is displayed.

3. Enter values for the following fields, and then click Next:

- Policy Name: Enter a name for the approval policy. This is a mandatory attribute.

- Description: Enter the details about what this approval policy will do.

- Request Type: Select the request type by selecting from the LOV, for example, Assign Roles. This is a mandatory attribute.

- Level: Select the approval level that you want to implement for this approval policy. This is a mandatory attribute. For more information about approval levels, see "Approval Levels" section in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

- Scope Type: Set automatically based on the request type selection. For example:

- If request type is set to Create User, then Scope Type is automatically set to Organization.

- If request type is set to Provision Resource, then Scope Type is automatically set to Resource.

- If request type is set to Assign Roles, then Scope Type is automatically set to Role.

Note:

The Scope Type, All Scope, and Scope fields are applicable only if the Level field is set to Operation Level. These fields are disabled if the Level field is set to Request Level.

- All Scope: Select this option to specify the approval policy associated with all entities for a particular entity type. For example, for the Create User request type, Scope Type is Organization. If you select All Scope, then this approval policy is applicable to all organizations in Oracle Identity Manager. This is same for Resource and Role scopes.

- Scope: Select this option to specify the approval policy associated with the specific entity for a particular entity type. An approval policy can be associated with a specific Scope based on the Scope Type.
The Scope field is disabled if All Scope field is set. If All Scope field is not set, then this field becomes mandatory and must be set with some value.

- Auto Approval: Select this option to specify automatic approval at the request level or operation level that you select in the Level field.

- Approval Process: Select the workflow that you want to associate with this approval policy. If Auto Approval is selected, then this field is disabled and you cannot set any value. If Auto Approval is not set, then this field becomes mandatory.

4. On the Step 2. Set Approval Rule and Component page, enter the name of the approval policy rule in the Rule Name field, for example, RuleTest1.

5. In the Rule Components section, you can define the parameters of the approval policy rule. To do so, click the icon next to the View list. The Add Simple Rule dialog box is displayed. In this dialog box, you must select values for the following fields, and then click Save.

- Entity: Entity, such as Requester, Beneficiary, or Resource, with which the approval policy rule is associated. This varies based on the selected request type and the approval level.

- Attribute: Attribute of the above selected entity.

- Condition: Condition of the approval policy rule, such as Equals, Not Equals, or Starts With.

- Value: Value of the condition.

Note:

If you use the User Login attribute in a rule expression, the corresponding User Login ID value must be entered in all uppercase letters, otherwise the expression will not evaluate to true.

- Parent Rule Container: The rule container with which this approval policy rule needs to be associated with.

Note:

When writing simple rule expressions, if an entity attribute has an encoded value, then create the expression by using the encoded value, not the lookup-code definition. For example, for the account status attribute, create the expression by using the encoded value 1 or 0, not the decoded value Locked or Unlocked.

6. Rule containers can be used for modeling complex conditions with And and Or combinations. To add a rule container for the approval policy rule, in the Rule Components section, from the Actions menu, select Add Rule Container. The Add Rule Container dialog box is displayed. In this dialog box, enter or select values for the following fields, and then click Add.

- Rule Container Name: The name of the rule container.

- Parent Rule Container: The name of the rule container under which you want to create this rule container. A rule container can hold either another rule container or rule elements with the AND or OR operators in a hierarchical order.

- Operator: The operators are AND and OR.

7. After the approval rule creation is complete, click Next.

8. On the Step 3. Review Approval Policy Summary page, verify the information that you have specified for the approval policy. You can click the Back button to modify any information if you want. Click Finish to create the approval policy.

9. A message is displayed confirming that the approval policy has been created. Click OK.

18.3 Searching Approval Policies

To search for approval policies:

1. In the Oracle Identity Manager Advanced Administration, on the left pane of the Approval Policies tab, in the Search field, enter a search criterion to search for approval policies. You can specify the asterisk (*) wildcard character to specify the search criterion.

Note:

In simple and advanced search for approval policies, searching with translated approval policy names is not supported. Oracle Identity Manager supports only English string search for approval policies. For default approval policies, you can search with English policy names as stored in the database. However, if you create an approval policy by specifying its name in another language, then you can search it by using the same string, and not in any other language.

2. Click the Search icon. A list of approval policies is displayed in a search results table, with the following fields:

- Policy Name: The name of the approval policy.

- Request Type: The name of the request type associated with the approval policy.

- Scope: The associated resource, organization, or role name. The scope is populated only for the approval policies associated with the operation level request.

- Level: The approval level.

- Rule Name: The name of the approval policy rule.

- Approval Process: The approval process associated with the approval policy.

- Priority: Priority of the approval policy.

Figure 18-1 shows the approval policy search results:

Figure 18-1 Approval Policy Search Results

Description of "Figure 18-1 Approval Policy Search Results"

You can also use the Advanced Search option in the Approval Policies tab to search for approval policies based on advanced search criteria. To do so:

1. On the left pane of the Approval Policies tab, click Advanced Search. The Advanced Search: Approval Policies page is displayed.

2. Enter values in the fields to specify a search criteria. You can specify a combination of approval policy name, name of the request type associated with the approval policy, approval level, scope type such as resource, organization, or role, and scope to specify the search criteria.

3. Click Search. The search result displays a list of approval policies with information about priority, policy name, request type, scope, level, rule name, and approval process, as shown in Figure 18-2:

Figure 18-2 Approval Policy Advanced Search

Description of "Figure 18-2 Approval Policy Advanced Search"

18.4 Modifying Approval Policies

To modify approval policies:

1. On the search results table, select a policy.

2. From the Actions menu, select Open. The Approval Policy Details form is displayed.

3. In the Policy Details section, edit the fields to modify the approval policy.

Note:

You cannot modify the approval policy rule name and approval policy priority attribute.

4. In the Approval Rules section, modify approval policy rules, if required. To modify an approval policy rule, you can add a simple rule, add a rule container, modify rule components, or delete a rule component. For detailed information about adding approval policy rules and rule containers, see steps 5 through 7 in "Creating Approval Policies".

5. To modify rule components:

1. Select the approval policy rule.

2. From the Actions menu, select Modify Rule Components. The Modify Rule Components dialog box is displayed.

3. Edit the values in the fields provided, and click Apply.

6. To delete rule components:

1. Select the approval policy rule that you want to delete.

2. From the Actions menu, select Delete Rule Components. A message box is displayed asking for confirmation.

3. Click Yes to confirm the deletion.

7. Click Save to save the changes in the approval policy.

18.5 Modifying the Priority of an Approval Policy

To modify the priority of an approval policy:

1. From the approval policies search result, select a policy whose priority you want to modify.

2. From the Actions menu, select Set Priority. The Modify Approval Policy priority wizard is displayed.

3. In the Set Policy Details page, specify values in the fields as required. For information about the fields in this page, see step 4 in "Creating Approval Policies". Then, click Next.

4. In the Set Policy Priorities page, enter a number to specify the priority of the approval policy. Then, click Next.

5. In the Review and Confirm page, the policy name and the priority that you set are displayed for your review. If you want to change the current priority, then click Back.
Otherwise, click Finish. A message is displayed stating the approval policy priority has been changed successfully.

6. Click OK.

Note:

Oracle Identity Manager does not perform any validation and allows you to set the same priority to multiple approval policies. It is not recommended to set the same priority to multiple approval policies.

18.6 Deleting Approval Policies

To delete an approval policy:

1. From the approval policies search results, select the approval policy that you want to delete.

2. From the Actions menu, select Delete. A message box is displayed asking for confirmation.

3. Click Yes to confirm the deletion.

19 Managing Attestation Processes

This chapter is divided into the following sections:

- About Attestation

- Attestation Process Configuration

- Creating Attestation Processes

- Managing Attestation Processes

- Using the Attestation Dashboard

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:

- Definition of an Attestation Process

- Components of Attestation Tasks

- Attestation Request

- Delegation

- Attestation Lifecycle Process

- Attestation Engine

- Attestation Scheduled Task

- Attestation-Driven Workflow Capability

- Attestation E-Mail

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:

- User Scope or Resource Scope: This defines the algorithm by which the target user entitlements of the attestation process are determined.

- Reviewer Setup: This specifies the reviewer, who attests the entitlements of other users. An attestation process can specify a particular user as the reviewer, or can specify more abstractly how to select the reviewer. For example, the reviewer can be specified as the user's manager, as an administrator of the resource, as an authorizer of access to the resource, or as a member of the role that grants the entitlement.

- Definition of Attestation Schedule: This specifies the schedule for running the attestation process.

- Process Owner: This is a designated group of users that are responsible for monitoring activities related to the process.

- They will be notified of any issues that occur when the process runs.

- They will have permissions to view the process definition, but will not have administrative permissions by default.

- They will be able to execute the process whenever required.

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.1.1 Attestation Process Control

The following sections describe how you can control attestation processes.

19.1.1.1.1 Disabling Processes

An attestation process can be disabled by the system administrator to prevent it from running at its preconfigured schedule. This gives an administrator better control over the environment. A system administrator attestation process can be enabled, but it cannot be enabled if its Next Run Time value is in the past. A user who enables an attestation process must set its next run time in the future.

19.1.1.1.2 Deleting Processes

An attestation process can be deleted. This is called a soft-delete. It does not actually delete the records because the records must be maintained for audit purposes. Instead, the attestation process will be marked as deleted.

A deleted process is not displayed in Oracle Identity Manager Administrative and User Console. Because process names and codes are unique, a name once used is no longer available, and no new attestation process can be created with the same name.

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:

- Reviewer: This specifies the user who performs the attestation.

- Task Source: This specifies whether or not the attestation task is a result of a process or because of delegation by another reviewer. In the case of delegation, the task must track the reviewer who delegated the task, and which task is the source of the entitlements.

- Attestation Data: This is detailed data about user entitlements in the attestation scope. This data is from the process form of the provisioned resource instance.

- Attestation Date: This defines the date on which the attestation task is initiated.

- Attestation Actions: These are the actions that the reviewer can take on the attestation scope. The action is not at the level of attestation task overall, but rather against each entitlement in the attestation scope. The following are attestation actions:

- Certify: The reviewer agrees that the user being reviewed is allowed to have the entitlement in its current form, including any specific data or fine-grained permissions.

- Reject: The reviewer does not think that the user must have this entitlement in the form.

- Decline: The reviewer does not want to accept the responsibility of attesting to the entitlement. This action is usually for cases in which processes have been configured incorrectly, and is useful in the early stages of a rollout.
A reviewer declines a task when the reviewer wants someone else to act upon the task. When a task is declined, it gets assigned to a random user in the System Administrator role.

- Delegate: The reviewer wants to reassign the attestation of this entitlement to another qualified person.

Note:

The attestation tasks are not workflow tasks in Oracle Identity Manager definition. They are not created as part of workflow. Attestation tasks do not support all the task management features that the workflow engine supports such as dynamic assignment, escalation, and proxy management.

19.1.2.1 Attestation Inbox

From the Attestation tab of the TaskList in the Self Service, a reviewer can view the details of each attestation task. Within an attestation task, the reviewer can provide responses or comments for individual entitlements.

19.1.3 Attestation Request

When an attestation process is executed, an attestation request is created and recorded in Oracle Identity Manager database. This request records for audit purposes, when an attestation process is executed. The attestation request record consists of basic identity and audit data and statistical data that is used in reports. The data includes the following items:

- A request ID: Each attestation request has a unique identifier. Each attestation task that Oracle Identity Manager creates as a result of a request, stores as part of its record, the request ID of the associated attestation request.

- Date and time of execution of the process.

- Date and time of completion of the process: The date and time of completion of the process is considered to be the date and time for that request.

- Total number of entitlements identified for attestation.
The number of provisioned resources that matched the selection criteria (of the resource scope of the attestation process) during this particular execution of the attestation process.

- Number of entitlements certified.

- Number of entitlements rejected.

- Number of entitlements declined.

19.1.4 Delegation

The reviewer who is assigned to an attestation task may not be able to attest to all the entitlements in the task. There may be multiple reasons for this. For example:

- There may be too many entitlements covering too many users in the attestation task

- The reviewer is not sure about the reasons for which the entitlements were provisioned

In these cases, the reviewer may want to involve other people in the review. A reviewer can delegate attestation of certain entitlements in the task.

To delegate attestation, the reviewer selects a set of entitlements in the task and delegates them to another user. This creates a new attestation task that is assigned to the selected reviewer.

The new task contains only those entitlements that the original reviewer selected. The original reviewer is no longer responsible for providing an attestation response for those entitlements. The new attestation task assigned to the delegate would track who performed the delegation, which task it was created from, and some other information, for example, the request ID. The new attestation task is treated in the same manner as any other attestation task. It can even be delegated. Figure 19-1 shows delegate attestation page.

Figure 19-1 Delegate Attestation

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.

Figure 19-2 Creating an Attestation Task: Workflow

Description of "Figure 19-2 Creating an Attestation Task: Workflow"

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.2 Stage 2: Acting on an Attestation Task

When an attestation task is assigned to a reviewer, the reviewer receives an e-mail, and the task is displayed in the reviewer's attestation inbox. The reviewer views task details in this inbox.

From the task details page, the reviewer provides a response and, if required, a comment for each entitlement. This marks the attestation entitlement detail in the task as Response Provided.

If the reviewer's response includes delegating the attestation activity for a specific entitlement, then the reviewer must provide a delegated user. Optionally, the reviewer can provide comments explaining why the reviewer is delegating the attestation activity to that user.

After the reviewer provides responses to all entitlements, the reviewer can commit their action for the attestation task by submitting all responses.

Figure 19-3 Flow of Events When Reviewer Responds to Entitlement

Description of "Figure 19-3 Flow of Events When Reviewer Responds to Entitlement"

At this point, the next stage of the Attestation Business Process begins.

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.

Figure 19-4 Flow of Events After Attestation Task Response Is Submitted

Description of "Figure 19-4 Flow of Events After 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.

Figure 19-5 Follow-Up Action Sub-Flow

Description of "Figure 19-5 Follow-Up Action Sub-Flow"

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

19.1.6 Attestation Engine

The attestation engine implements the attestation lifecycle. It is a service in Oracle Identity Manager architecture that exposes APIs to receive instructions to initiate a particular attestation process. The API is called from the attestation scheduled task as well as from the Run Now button on the Attestation Process Detail page to support on-demand execution. It supports both drivers for initiation of attestation processes.

The attestation engine uses the JMS messaging service to perform offline, queued processing. This ensures better performance.

Note:

Attestation depends on the entry in the user profile audit data. If the audit entry is not generated for a user who is part of the attestation process, then the reviewer would not be able to see the user and process form information in attestation. To avoid such situations, ensure that the Issue Audit Messages Task scheduled task is run before performing the attestation run.

19.1.7 Attestation Scheduled Task

This new system scheduled task is responsible for examining the attestation processes defined in Oracle Identity Manager, and creating the necessary attestation tasks in the system.

Features of this scheduled task are:

- By default, this scheduled task is set to run every night. You can change the schedule according to your requirements.

- This scheduled task examines the attestation process definition table for all active (not system administrator) attestation processes

- If the scheduled task finds that the next scheduled start time of a process is in the past, then the task sends a call to the Attestation Engine to initiate the attestation process.

19.1.8 Attestation-Driven Workflow Capability

You can enhance the provisioning processes predefined in Oracle Identity Manager to listen to triggers coming from attestation activity. In this way, you can define custom workflows as part of the provisioning workflow that would respond to attestation taking place (or not taking place, in case of a refusal), and therefore be initiated when attestation takes place. This serves two purposes:

- The default attestation task in the flow, User Attestation Event Occurred, would provide the audit trail for the attestation history of the specific user entitlement.

- There is one instance of this task for each time that resource instance is attested by the appropriate type of attestation process.

- The response code set on the task indicates what the response provided by the reviewer is.

- The user tagged as the person creating the task indicates who the reviewer is.

- Any comment provided by the user is in the notes field for the task.

- Using response-generated tasks, the default task can start the workflow to respond to a particular attestation response received. Therefore, for a particular resource, you can specify that the Reject response must start the appropriate workflow tasks in the provisioning process for disabling the account, as an example.

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.1 Notify Attestation Reviewer

This template is used to build the e-mail to send to the reviewer when an attestation task is assigned to the reviewer.

19.1.9.1.1 Variables

The following are variables in the Notify Attestation Reviewer template:

Variable

Description

Attestation Definition.Process Name

Name of the attestation process

Attestation Definition.Process Code

Code for the attestation process

Attestation Task.Task Assigned Date

Date the attestation task was assigned

19.1.9.1.2 Subject Line

The following is the Subject line of e-mail messages defined by the Notify Attestation Reviewer template:

A new attestation task for attestation process Attestation Definition.Process Name has been added to your attestation inbox

19.1.9.1.3 Body

The body of the e-mail message contains the following information:

The attestation task details are as follows
Process Name: Attestation Definition.Process Name
Process Code: Attestation Definition.Process Code
Data Type: Access Rights
Assigned Date: Attestation Task.Task Assigned Date

19.1.9.2 Notify Delegated Reviewers

This template is used to build the e-mail to send to a reviewer when an attestation task is delegated to the reviewer.

19.1.9.2.1 Variables

The following are variables in the Notify Delegated Reviewers template:

Variable

Description

Attestation Definition.Process Name

Name of the attestation process

Attestation Definition.Process Code

Code for the attestation process

Attestation Task.Task Assigned Date

Date the attestation task is assigned

Attestation Task.Delegated By First Name

First name of the reviewer who performed the delegation

Attestation Task.Delegated By Last Name

Last name of the reviewer who performed the delegation

Attestation Task.Delegated By User Id

User ID of the reviewer who performed the delegation action

19.1.9.2.2 Subject Line

The following is the Subject line of e-mail messages defined by the Notify Delegated Reviewers template:

Attestation Task.Delegated By User Id has delegated to you an attestation task from attestation process Attestation Definition.Process Name

19.1.9.2.3 Body

The body of the message contains the following information:

The attestation task details are as follows
Process Name: Attestation Definition.Process Name
Process Code: Attestation Definition.Process Code
Data Type: Access Rights
Assigned Date: Attestation Task.Task Assigned Date
Delegated By: Attestation Task.Delegated By First Name Attestation Task.Delegated By Last Name [Attestation Task.Delegated By User Id]

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.3.1 Variables

The following are variables in the Notify Process Owner about Declined Attestation Entitlements template:

Variable

Description

Attestation Request.Request Id

ID of the attestation request

Attestation Definition.Process Name

Name of the attestation process

Attestation Task.Reviewer First Name

First name of the reviewer

Attestation Task.Reviewer Last Name

Last name of the reviewer

Attestation Task.Reviewer User Id

User ID of the reviewer

Attestation Data.Provisioned User First Name

First name of the user being attested

Attestation Data.Provisioned User Last Name

Last name of the user being attested

Attestation Data.Provisioned User Id

User ID of the user being attested

Attestation Data.Resource Name

Name of the resource being attested

Attestation Data.Entitlement Descriptive Data

Descriptive data of the entitlement being attested

19.1.9.3.2 Subject Line

The following is the Subject line of e-mail messages defined by the Notify Process Owner About Declined Attestation Entitlements template:

User access rights in attestation request Attestation Request.Request Id have been declined by Attestation Task.Reviewer User Id

19.1.9.3.3 Body

The following is displayed in the body of the message:

Attestation of the following user access rights were declined by the reviewer.
Reviewer: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id]
Attestation Process: Attestation Definition.Process Name
Attestation Request ID: request Attestation Request.Request Id
Access Rights Data: Attestation Data.Provisioned User First Name Attestation Data.Provisioned User Last Name [Attestation Data.Provisioned User User Id] - Attestation Data.Resource Name - Attestation Data.Entitlement Descriptive Data

19.1.9.3.4 Special Comments

Each entitlement data item will appear on a new line.

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.1.9.4.1 Variables

The following are variables in the Notify Process Owner About Reviewers with No Email Defined template:

Variable

Description

Attestation Request.Request Id

ID of the attestation request

Attestation Definition.Process Name

Name of the attestation process

Attestation Request.Request Creation Date

Date when the attestation request was created

Attestation Task.Reviewer First Name

First name of the reviewer that is invalid

Attestation Task.Reviewer Last Name

Last name of the reviewer that is invalid

Attestation Task.Reviewer User Id

User ID of the reviewer that is invalid

19.1.9.4.2 Subject Line

The following is the Subject line for e-mail defined by the Notify Process Owner About Reviewers with No Email Defined template:

E-mail address is not defined for some of the reviewers in attestation process Attestation Definition.Process Name, request Attestation Request.Request Id

19.1.9.4.3 Body

The following is the body of the message:

The following attestation reviewers do not have e-mail addresses defined. Attestation requests have been generated for these reviewers and can be accessed by logging in to Oracle Identity Manager. However, notification e-mails were not sent.
Attestation process: Attestation Definition.Process Name
Attestation Request ID: request Attestation Request.Request Id
Request date: Attestation Request.Request Creation Date
Reviewers Without Email: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id]

19.1.9.4.4 Special Comments

Each reviewer detail appears on a new line.

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.2.1 Menu Structure

The top-level Attestation menu contains the following links in the Policies section of Oracle Identity Manager Advanced Administration:

- Create Attestation Process

- Manage Attestation Process

These menu items are governed by the same delegated administration permissions that govern all menu items in the Advanced Administration.

These menu items are defined but not assigned to any group in Oracle Identity Manager. They will be assigned to the System Administrators group in Oracle Identity Manager if audit compliance components are installed.

19.2.2 System Control

Attestation has the following dependencies:

- The User Profile Audit feature must be enabled.

- Historical data must be collected at least up to the Process Form level.

If the auditing level is set below the required levels, then clicking menu item links related to attestation generates the Attestation Feature Not Available page, and prevents the user from defining any attestation processes.

Audit levels are controlled by the system property called XL.UserProfileAuditDataCollection and the attestation feature expects this value to be set to at least Resource Form.

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:

Field

Description

Name

A unique name for the attestation process. The name must be unique across system administrator and deleted attestation processes.

Code

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

Description

Detailed 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:

Attribute

Expression

Description

Name

Full text or wildcard

The name of the resource.

Type

Lookup values with the option to select all or a subset

The type of resource.

Resource Audit Objectives

Lookup values with the option to select all or a subset

The 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 Groups

Lookup values with the option to select all or a subset

The user groups that have administrative permissions for a resource.

Authorized User Groups

Lookup values with the option to select all or a subset

The user groups that are authorizers or approvers for the resources.

Resource Status

Full text or wildcard

The 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:

Column

Description

Names

Specifies the name of the process.

Code

Specifies the attestation process code.

Description

Specifies a description for the process.

Status

Indicates whether the attestation process is active or system administrator.

Type

Specifies the type of resource.

User Scope

Specifies the scope of the user who will be a part of the attestation process.

Resource Scope

Specifies the resources that are within the scope of the attestation process.

Reviewer Type

Indicates the type of the reviewer.

Reviewer Name

Indicates the name of the reviewer.

Schedule

Indicates if the process is scheduled to run only once, or on a daily, monthly, or yearly basis.

Last Start

Specifies the last time an attestation process was run.

Next Start

Specifies when the process is scheduled to run next.

Process Owner Group

Indicates 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 Completion

Specifies the last time an instance of this process was completed.

The rest of this section discusses the following topics:

- Editing Attestation Processes

- Disabling Attestation Processes

- Enabling Attestation Processes

- Deleting Attestation Processes

- Running Attestation Processes

- Managing Attestation Process Administrators

- Viewing Attestation Process Execution History

19.4.1 Editing Attestation Processes

To edit an attestation process:

1. On the Attestation Process Detail page, click Edit.

2. On the Edit Attestation Process page, make the required changes to the attestation process, and then click Save.
The fields on the Edit Attestation Process page are the same as those displayed in the "Creating Attestation Processes" section.

19.4.2 Disabling Attestation Processes

To disable an active attestation process:

1. On the Attestation Process Detail page, click Disable.
Note that the Disable button is displayed only when a process is active.

2. On the Disable Attestation Confirmation page, click Confirm Disable.

19.4.3 Enabling Attestation Processes

An attestation process can be enabled only if its next start time is in the future and if the process is disabled.

To enable an attestation process:

1. On the Attestation Process Detail page, click Enable.
Note that the Enable button is displayed only when the process is disabled.

2. On the Enable Attestation Confirmation page, click Confirm Enable.

19.4.4 Deleting Attestation Processes

You can edit, disable, or delete an attestation process only as a process administrator with the required permissions.

To delete an attestation process:

1. On the Attestation Process Detail page, click Delete.

2. On the page, click Confirm Delete.

19.4.5 Running Attestation Processes

This feature enables you to run unscheduled attestation processes. To run an attestation process, click Run Now on the Attestation Process Detail page. This starts the attestation process independent of the attestation schedule.

Only users in the process owner group can start unscheduled attestation processes.

19.4.6 Managing Attestation Process Administrators

The tasks of adding, deleting, and updating administrative groups for attestation processes are similar to the tasks of adding, deleting, and updating administrative groups for users and organizations.

To manage the administrators of an attestation process, select Administrators from the Additional Details list on the Attestation Process Detail page. The Administrative Groups page is displayed. You can use this page to add and remove administrators for an attestation process and update administrator permissions.

The permission model for an attestation process definition is as follows:

- To view the attestation process definition, the user must be either of the following:

- A member of a group that has the appropriate read permissions in the administrators group

- A member of the group that is the process owner

- To edit the attestation process definition, the user must be a member of a group that has the required write permissions in the administrators group.

- To delete the attestation process definition, the user must be a member of a group that has the required delete permissions in the administrators group.

19.4.7 Viewing Attestation Process Execution History

To view the execution history of an attestation process, select Execution History from the Additional Details list on the Attestation Process Detail page. The Attestation Process Execution History page is displayed.

The following are the columns in the Attestation Process Execution History table:

Column

Description

Request ID

ID for the attestation process instance that was run

Reviewer

Name of the reviewer for the attestation process

Initiated On

Date and time when the request was started

Completed On

Date and time when the request was completed

If the request is still pending, then it shows Not Completed.

On the Attestation Process Execution History page, click the request ID link to open the Request Detail page. On this page, you can filter the requests according to the certified, rejected, open, and closed state.

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:

Column

Description

Process Code

The attestation process code.

Process Name

The name of the process. The Attestation Process Detail page is displayed when the link for an attestation process name is clicked.

Last Completion

The 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 Date

The 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 Completion

The date and time when the last instance run was completed. If it has not been completed, then the value is Pending.

Total Records

The total number of entitlements identified for attestation and covered by an attestation task as part of the last process instance.

Certified

The number of entitlements certified in the last attestation process instance.

Rejected

The number of entitlements rejected in the last attestation process instance.

Open

All 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:

Column

Description

User

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

Resource

Resource 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 Data

Description of the provisioned resource instance.

Comments

Comment or status of the request. The value can be one of the following:

- Certify

- Reject

- Open

- Closed

Attestation Result

Last response that was provided for the attestation.

Reviewer

User 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 Path

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

Comments

Reviewer 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:

Column

Description

Reviewer

The 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 Result

Action supplied by the reviewer. Except for the first record, the value is always Delegated.

Attestation Date

The date and time of the attestation response of the reviewer.

Comments

Reviewer comments. Long comments are truncated, and tooltips are used to show the full text of the comments.

19.5.2 E-Mail Notification

As part of the attestation process, the attestation engine sends e-mail to concerned parties at various stages. You can configure e-mail content by using e-mail templates of the General type in Oracle Identity Manager Email Definition store.

In the templates, the form user is defined as XELSYSADM. You can change it to a different user. You must ensure that the e-mail address is defined for the user selected to use these templates. Otherwise, the system may not be able to send out notifications.

The following e-mail notification templates are available:

- Notify Attestation Reviewer: Used for sending e-mail when an attestation task is assigned to a reviewer.

- Notify Delegated Reviewers: Used for sending e-mail to reviewers when an attestation task is delegated to them.

- Notify Declined Attestation Entitlements: Used for sending e-mail to users in the Process Owner group if a reviewer declines any entitlements.

- Attestation Reviewers With No E-Mail Defined: Used for sending e-mail to users in the Process Owner group if an e-mail address is not defined for any of the reviewers.

19.5.3 Attestation Grace Period Checker Scheduled Task

A system scheduled task called Attestation Grace Period Checker is used to examine the attestation processes defined in Oracle Identity Manager and to create the required attestation tasks.

The features of the Attestation Grace Period Checker scheduled task are:

- The scheduled task is set to run every 30 minutes by default. You can change this according to your requirement.

- The scheduled task examines all active attestation processes.

Part V

Reporting

This part describes Oracle Identity Manager delegated administration functionalities by using the reporting features in the following chapter:

- Chapter 20, "Using Reporting Features"

20 Using Reporting Features

This chapter includes the following sections:

- Reporting Features

- Starting Oracle Identity Manager Reports

- Running Oracle Identity Manager Reports

- Supported Output Formats

- Reports for Oracle Identity Manager

- Exception Reports

- Creating Reports Using Third-Party Software

- Required Scheduled Tasks for BI Publisher Reports

Note:

- Oracle Identity Manager Reports enables you to use Oracle BI Publisher as the reporting solution for Oracle Identity Management products.

- Oracle Identity Manager Reports are 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 provides a restricted-use license for Oracle BI Publisher and easy-to-use reporting packages for multiple Oracle Identity Management products.

- For large-scale deployments, especially those taking advantage of the extensive auditing capabilities of Oracle Identity Manager, it is highly recommended that you deploy a dedicated enterprise-class reporting solution. A solution based on tools such as Oracle Business Intelligence Enterprise Edition can provide the flexibility, automation, and performance required for a large-scale organizations.

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:

- Access Policy Reports

- Attestation, Request, and Approval Reports

- Role and Organization Reports

- Password Reports

- Resource and Entitlement Reports

- User Reports

20.5.1 Access Policy Reports

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

- Access Policy Details

- Access Policy List by Role

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 Parameter

Description

Access Policy Name

Name of the Access Policy

Fields

The following table lists the fields of the report:

Report Field

Description

Description

Description of the policy

Approval Required

Approval required for the policy

Creation Date

Date when the policy is created

Retrofit Access Policy

Retrofit of the access policy

Created By

Name of the person who created the policy

Priority

Priority of the policy

Columns

The following table lists the columns of the report:

Report Column

Description

Resource Name

Name 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 Parameter

Description

Role Name

Name of the role

Fields

The following table lists the fields of the report:

Report Field

Description

Description

Description of the policy

Approval Required

Approval required for the policy

Creation Date

Date when the policy is created

Retrofit Access Policy

Retrofit of the access policy

Created By

Name of the person who created the policy

Priority

Priority of the policy

Columns

The following table lists the columns of the report:

Report Column

Description

Role Name

Name 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:

- Approval Activity

- Attestation Process List

- Attestation Request Details

- Attestation Requests by Process

- Attestation Requests by Reviewer

- Request Details

- Request Summary

- Task Assignment History

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 Parameter

Description

Approver's First Name

First name of the approver

Approver's Last Name

Last name of the approver

Approver's User ID

User ID of the approver

Organization

Name of the organization

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

Approver's First Name

First name of the approver

Approver's Last Name

Last name of the approver

Approver's User ID

User ID of the approver

Organization

Organization of the approver

Approval Accepted

Count of the accepted approval

Approval Rejected

Count of the rejected approval

Approvals Pending

Count of the pending approval

Approval Requests Total

Total 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 Parameter

Description

Attestation Process Name

Name of the attestation process

Attestation Process Owner

Owner of the attestation process

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

Attestation Process Name

Name of the attestation process

Owner User ID

ID of the owner of attestation process

Date of Current Request

Data on which the request was made

Date of Last Completion

Data on which the request was completed

Certified

Attestation process certified

Rejected

Attestation process rejected

Declined

Attestation process declined

Delegated

Attestation process delegated

Total

Sum 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 Parameter

Description

Attestation Process Name

Name of the attestation process

Attestation Request ID

ID of the attestation process

Request Initiation Date Range From

Start date of the attestation request

Request Initiation Date Range To

End date of the attestation request

Fields

The following table lists the fields of the report:

Report Field

Description

Attestation Process Name

Name of the attestation process

Attestation Request ID

ID of the attestation request

Request Initiation Date

Date on which the request is initiated

Completion

Date on which the request is completed

Certified

Attestation process certified

Rejected

Attestation process rejected

Delegated

Attestation process delegated

No Action

Number of attestation processes on which no action is taken

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user who initiated the attestation request

Last Name

Last name of the user who initiated the attestation request

User ID

ID of the user who initiated the attestation request

Resource

Name of the resource

Descriptive Data

Date on which the request is completed

Reviewer's First Name

First name of the reviewer

Reviewer's Last Name

Last name of the reviewer

Reviewer's User ID

ID of the reviewer

Action

Action 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 Parameter

Description

Attestation Process Name

Name of the attestation process

Attestation Process Owner

Owner of the attestation process

Fields

The following table lists the fields of the report:

Report Field

Description

Attestation Owner

Name of the attestation process owner

Total Number of Requests

Total number of requests

Last Completion Date

Date by which attestation should be completed

Current Request Initiation Date

Date on which attestation is initiated

Columns

The following table lists the columns of the report:

Report Column

Description

Request ID

ID of the attestation request

Initiation Date

Date on which attestation is initiated

Completion Date

Date by which attestation should be completed

Certified

Attestation process certified

Rejected

Attestation process rejected

Declined

Attestation process declined

Delegated

Attestation process delegated

Total Attested

Sum 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 Parameter

Description

Reviewer First Name

First name of the reviewer

Reviewer Last Name

Last name of the reviewer

Reviewer User ID

User ID of the reviewer

Fields

The following table lists the fields of the report:

Report Field

Description

Reviewer 's First Name

First name of the reviewer

Reviewer 's Last Name

Last name of the reviewer

Reviewer 's User ID

User ID of the reviewer

Total Number of Requests

Count of requests to review

Columns

The following table lists the columns of the report:

Report Column

Description

Request ID

ID of the attestation request

Process Name

Name of the process

Initiation Date

Date on which attestation is initiated

Completion Date

Date by which attestation should be completed

Certified

Attestation process certified

Rejected

Attestation process rejected

Declined

Attestation process declined

Delegated

Attestation process delegated

Total Attested

Count 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 Parameter

Description

Requestor User First Name

First name of the requestor

Requestor User Last Name

Last name of the requestor

Request User ID

ID of the requestor

Request ID

Request ID

Request Parent ID

Parent ID of the request

Request Status

Status of the request

Request Type

Type of the request

Request Date From

Start date of the request

Request Date To

End date of the request

Beneficiary User First Name

First name of the beneficiary

Beneficiary User Last Name

Last name of the beneficiary

Beneficiary User ID

ID of the beneficiary

Fields

The following table lists the fields of the report:

Report Field

Description

Request ID

Request ID

Request Type

Type of the request

Requester User ID

ID of the requester

Request Date

Date on which request is initiated

Approver User ID

ID of the approver

Current Status

Status of the request

Parent Request ID

ID of the parent Requester

Columns

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

Report Column

Description

First Name

First name of the beneficiary

Last Name

Last name of the beneficiary

User ID

ID of the beneficiary

User Type

Type of user

User Status

Status of the beneficiary

Organization

Organization of the beneficiary

Request Value

Request value of the resource

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

Report Column

Description

Request Name

Name of the request

Request Value

Value 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 Parameter

Description

Request Type

Type of request

Request Date From

Start date of the request

Request Date To

End date of the request

Organization

Details of the organization

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

Request ID

Request ID

Parent Request ID

ID of the parent Requester

Request Type

Type of request

Request Status

Status of request

Requestor User ID

ID of the requestor

Beneficiary User ID

ID of the beneficiary

Request Details

Details of the request

Approver User ID

ID of the approver

Request Date

Date 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

User ID

ID of the beneficiary

Assignee First Name

First name of the assignee

Assignee Last Name

Last name of the assignee

Assignee User ID

ID of the assignee

Assignee Role Name

Role name of the assignee

Assignee User Name

User name of the assignee

Employee Type

Type 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:

- Role Membership History

- Role Membership Profile

- Role Membership

- Organization Details

- User Membership History

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 Parameter

Description

Role Name

Name of the role

Role Category

Category of the role

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Employee Status

Status of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Membership Status

Status of membership: Revoked, Active

Effective From

Role membership effective from date

Effective To

Role membership effective to date

Fields

The following table lists the fields of the report:

Report Field

Description

Created By

Name of the person who created the role

Creation Date

Date on which the role was created

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Employee Type

Type of employee

Employee Status

Status of the employee

Membership Status

Membership date of the user

Effective From

Membership start date of the user

Effective To

Membership end date of the user

Manager's First Name

First name of the manager

Manager's Last Name

Last name of the manager

Manager's User ID

ID 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 Parameter

Description

Organization

Organization of the user

Fields

The following table lists the fields of the report:

Report Field

Description

Membership in Number of Roles

Number of members in number of roles

Number of Users

Number of users in the role

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Employee Type

Type 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 Parameter

Description

Role Name

Name of the role

Role Category

Category of the role

Organization

Name of the organization

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Employee Status

Status of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Fields

The following table lists the fields of the report:

Report Field

Description

Created By

Name of the person who created the user

Creation Date

Date on which the user is created

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of user

Employee Status

Status of the user

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Member Since

Joining date of the user

Manager's First Name

First name of the manager

Manager's Last Name

Last name of the manager

Manager's User ID

ID 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 Parameter

Description

Organization Name

Name of the organization

Fields

The following table lists the fields of the report:

Report Field

Description

Parent Organization Name

Name of the parent organization

Columns

The following table lists the columns of the report:

Report Column

Description

Role

Name of Administrator User roles

First Name

First name of the user in the organization

Last Name

Last name of the user in the organization

User ID

ID of the user

User Status

Status of the user

User Type

Type of user

Start Date

Joining date of the user

End Date

Leaving 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 Parameter

Description

Last Name

First name of the user

First Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Status

Status of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

User First Name

First name of the user

User Last Name

Last name of the user

Organization

Organization of the user

Employee Status

Status of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Columns

The following table lists the columns of the report:

Report Column

Description

User Role

Name of the user role

Membership Status

Status of membership

Effective From

Date 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:

- Password Expiration Summary

- Password Reset Summary

- Resource Password Expiration

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 Parameter

Description

Last Name

Last name of the user

First Name

First name of the user

User ID

ID of the user

Organization

Organization of the user

Expiration Date Range From

Start date of the expiration date

Expiration Date Range To

End date of the expiration date

Fields

N/A

Columns

The following table lists the columns of the report:

Report Field

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Employee Type

Type of the employee: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Employee Status

Status of the employee: Active, Disabled, Deleted, Disabled Until Start Date

Organization

Organization of the user

Password Expiration Date

Date 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 Parameter

Description

Aggregation Frequency

The frequency of the report generated

Date Range From

Start date of the report generated

Date Range To

End date of the report generated

Organization

Name of the organization

Fields

The following table lists the fields of the report:

Report Field

Description

Aggregation Frequency

The frequency of the report generated

Columns

The following table lists the columns of the report:

Report Column

Description

Time Period

Date and time of reset attempts performed

Reset Attempts

Number of reset attempts

Failed Reset Attempts

Number of failed reset attempts

Locked Users due to Failed Reset Attempts

Number of users locked due to a failed reset attempt

Resets by non-beneficiary

Number 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

User Status

Status of the user

Password Expiration Date From

The password expiry starting date

Password Expiration Date To

The password expiry ending date

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Field

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

User Status

Status of the user: Active, Disabled, Deleted, Disabled Until Start Date

User Type

Type of the user: Full-Time, Part-Time, Temp, Intern, Consultant, Contractor

Password Expiration Date

Date 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:

- Account Activity In Resource

- Delegated Admins and Permissions by Resource

- Delegated Admins by Resource

- Entitlement Access List

- Entitlement Access List History

- Financially Significant Resource Details

- Fine Grained Entitlement Exceptions By Resource

- Offline Resource Provisioning Messages

- Orphaned Account Summary

- Resource Access List History

- Resource Access List

- Resource Account Summary

- Resource Activity Summary

- Rogue Accounts By Resource

- User Resource Access History

- User Resource Access

- User Resource Entitlement

- User Resource Entitlement History

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 Parameter

Description

Resource Name

Name of the resource

Date Range From

Date from which reports are displayed

Date Range To

Date to which reports are displayed

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Name

Name of the resource

Activity Type

The 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 Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

User Status

Status of the user: Active, Disabled, Deleted, Disabled Until Start Date

Organization

Organization of the user

Manager's User ID

ID of the manager

Timestamp

Date 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 Parameter

Description

Resource Name

Name of the resource

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

Administrator Role Name

Name of the Administrator role

Administrator Role Information

Information about the Administrator role

Read Access

Indicates whether the resource has read access

Write Access

Indicates whether the resource has write access

Delete Access

Indicates whether the resource has delete access

Authorizer Role

Authorizer role name

Name Priority

Priority of the resource

Created By

Name of the person who created the resource

Creation Date

Resource 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 Parameter

Description

Resource Name

Name of the resource

Resource Type

Type of resource

Resource Audit Objective

Objective to carry out the audit for the resource

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Target

Indicates whether the resource is a target for organization or user

Write Access

Indicates whether the resource has write access

Delete Access

Indicates whether the resource has delete access

Creation By

Resource creation source

Creation Date

Date on which resource is created

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

User Status

Status of the user

Member Since

Joining date of the user

Manager's First Name

First name of the manager

Manager's Last Name

Last name of the manager

Manager's User ID

ID 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 Parameter

Description

Entitlement Code

Code of the entitlement

Resource Name

Name of the resource

Organization

Organization of the user

Role Name

Name of the role

User Status

Status of the user: Active, Disabled, Deleted, Disabled Until Start Date

User Type

Type of user

Provisioning Date From

Date from which the resource is provisioned to the user

Provisioning Date To

Date to which the resource is provisioned to the user

Fields

The following table lists the fields of the report:

Report Field

Description

Entitlement Code

Code of the entitlement

Entitlement Name

Name of the entitlement

Entitlement status

Status of the entitlement.

Resource Name

Name of the resource

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

User Id

ID of the user

First Name

First name of the user

Last Name

Last name of the user

User Status

User Status

User Type

Type of the user

Organization

Organization of the user

Valid To Date

Entitlement valid from date

Valid From Date

Entitlement 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 Parameter

Description

Entitlement Code

Code of the entitlement

Resource Name

Name of the resource

Organization

Organization of the user

Role Name

Name of the role

User Status

Status of the user: Active, Disabled, Deleted, Disabled Until Start Date

User Type

Type of user

Effective From Date

Entitlement effective from date

Effective To Date

Entitlement effective to date

Fields

The following table lists the fields of the report:

Report Field

Description

Entitlement Code

Code of the entitlement

Entitlement Name

Name of the entitlement

Resource Name

Name of the resource

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

User Id

ID of the user

First Name

First name of the user

Last Name

Last name of the user

User Status

Status of the user

User Type

Type of user

Effective From

Entitlement effective from date

Effective To

Entitlement 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 Parameter

Description

Resource Name

Name of the resource

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

User Roles

Lists 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Employee Type

Type of the employee such as fulltime, part time

Organization Name

Name of the organization

Role Name

Name of the role

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Name

Name of the resource

User ID

ID of the user

Columns

The following table lists the columns of the report:

Report Column

Description

Form Name

Name of the form

Form Type

Type 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 Parameter

Description

User's First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Resource Name

Name of the resource

Action

Action taken by the resource

Date Range From

Start date

Date Range To

End date

Fields

The following table lists the fields of the report:

Report Field

Description

User's First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Resource Name

Name of the resource

Resource Description

Description of the resource

Action

Action taken by the resource

Request Key

Key of the request

Create Date

Provisioning creation date

Columns

The following table lists the columns of the report:

Report Column

Description

Reason

Reason of the offline resource provisioning

Exception

Exception 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 Parameter

Description

Resource Name

Name of the resource

Reconciliation Date Range From

Start date of reconciliation

Reconciliation Date Range To

End date of reconciliation

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

Resource

Name of the resource

Account Information

Information of the orphaned account

Reconciliation Date

Date 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

User Status

Status of the user

User Type

Type of the user

Snapshot Date From

Effective start date of resource access to the user

Snapshot Date To

Effective end date of resource access to the user

Changes Date From

Resource changed from date to user

Changes Date To

Resource changed to date to user

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Resource Descriptive data

Description of the resource

User Status

Status of the user

Resource Status

Status of the resource

Effective From

Effective start date

Effective To

Effective 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

User Status

Status of the user

User Type

Type of the user

Provisioning Date From

Resource provision start date

Provisioning Date To

Resource provision end date

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

User Type

Type of the user

User Status

Status of the user

Organization

Organization of the user

Provisioning Date

Date 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 Parameter

Description

Resource Name

Name of the resource

Resource Type

Type of resource

Account Status

Status of the account

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Total Number of Users

Total number of users associated with the account

Columns

The following table lists the columns of the report:

Report Column

Description

Account Status

Status of the account

Number of Users

Number 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 Parameter

Description

Resource Name

Name of the resource

Date Range From

Start date

Date Range To

End date

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

Accounts Provisioned

Number of accounts provisioned

Accounts De-Provisioned

Number of accounts de-provisioned

Approval Requests

Number of approval requests

Approval Accepted

Number of approved requests

Approval Rejected

Number 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 Parameter

Description

Resource Name

Name of the resource

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization Name

Organization of the user

User Status

Status of the user

User Type

Type of the user

Fields

The following table lists the fields of the report:

Report Field

Description

Resource Type

Type of resource

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

User Status

Status of the user

User Type

Type of the user

Exception Type

Type of exception

Exception Approved in Attestation

Indicates whether the exception is approved or not

Reviewer First Name

First name of the reviewer

Reviewer Last Name

Last name of the reviewer

Reviewer User ID

User 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Status

Status of the user

Employee Type

Type of employee

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

User First Name

First name of the user

User Last Name

Last name of the user

Manager User ID

ID of the reporting Manager

Manager First Name

First name of the reporting Manager

Manager Last Name

Last name of the reporting Manager

Organization

Organization of the user

Employee Status

Status of employee

Employee Type

Type of employee

Identity Creation Date

User creation date

Columns

The following table lists the columns of the report:

Report Column

Description

Resource Name

Name of the resource

Resource Descriptive Data

Description of the resource

Provisioned Date

Date on which the resource is provisioned

Provisioned By

Name of the person who provisioned the resource

Effective From

Effective start date of resource access to the user

Effective To

Effective 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Status

Status of employee

Employee Type

Type of employee

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

User First Name

First name of the user

User Last Name

Last name of the user

Manager User ID

ID of the reporting Manager

Manager First Name

First name of the reporting Manager

Manager Last Name

Last name of the reporting Manager

Organization

Organization of the user

Employee Status

Status of employee

Employee Type

Type of employee

Identity Creation Date

User creation date

Columns

The following table lists the columns of the report:

Report Column

Description

Resource Name

Name of the resource

Resource Descriptive Data

Description of the resource

Resource Status

Status of the resource

Provisioned Date

Date 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 Parameter

Description

User ID

ID of the user

First Name

First name of the user

Last Name

Last name of the user

Email

Email of the user

Resource Name

Name of the resource

Organization

Organization of the user

Role Name

Name of the role

User Status

Status of the user

User Type

Type of the user

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

First Name

First name of the user

Middle Name

Middle name of the user

Last Name

Last name of the user

Email

Email of the user

Organization

Organization of the user

User Status

Status of the user

User Type

Type of the user

Manager First Name

First name of the manager

Manager Last Name

Last name of the manager

Start Date

Entitlement of resource start date

End Date

Entitlement of resource end date

Columns

The following table lists the columns of the report:

Report Column

Description

Entitlement Code

Code of the entitlement

Entitlement Name

Name of the entitlement

Entitlement Status

Status of the entitlement

Resource

Type of the resource

Provisioning Start

Date from which the resource is provisioned to the user

Valid From Date

Entitlement 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 Parameter

Description

User ID

ID of the user

First Name

First name of the user

Last Name

Last name of the user

Email

Email of the user

Resource Name

Name of the resource

Organization

Organization of the user

Role Name

Name of the role

User Status

Status of the user

User Type

Type of the user

Effective From Date

Resource entitlement effective start date

Effective To Date

Resource entitlement effective end date

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

First Name

First name of the user

Last Name

Last name of the user

User Status

Status of the user

User Type

Type of the user

Organization

Organization of the user

Email

Email of the user

Start Date

Start date of resource entitlement

End Date

End date of resource entitlement

Identity Creation Date

Date of identity creation

Manager First Name

First name of the manager

Manager Last Name

Last name of the manager

Columns

The following table lists the columns of the report:

Report Column

Description

Entitlement Code

Code of the entitlement

Entitlement Name

Name of the entitlement

Resource

Type of the resource

Effective From Date

Resource entitlement effective start date

Effective To Date

Resource entitlement effective end date

20.5.6 User Reports

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

- User Profile History

- User Summary

- Users Deleted

- Users Disabled

- Users Unlocked

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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Role Name

Role of the user

Manager User ID

ID of the Manager to whom the user reports

Employee Status

Status of the user

Employee Type

Type of employee

Changes Date Range From

Effective start date of the changes

Changes Date Range To

Effective end date of the changes

Snapshot Date Range From

Effective start date of resource access to the user

Snapshot Date Range To

Effective end date of resource access to the user

Fields

The following table lists the fields of the report:

Report Field

Description

User ID

ID of the user

User First Name

First name of the user

User Last Name

Last name of the user

Manager User ID

ID of the reporting Manager

Manager First Name

First name of the reporting Manager

Manager Last Name

Last name of the reporting Manager

Organization

Organization of the user

Employee Status

Status of employee

Employee Type

Type of employee

Identity Creation Date

User creation date

Columns

The following table lists the columns of the report:

Report Column

Description

Profile Parameter

Name of user profile

Value

Value of user profile

Date Effective From

Effective from date

Time Effective From

Effective 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Employee Status

Status of the user

Employee Type

Type of employee

Creation Date From

Start date of user summary

Creation Date To

End date of user summary

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Status

Status of the user

Employee Type

Type of employee

Manager ID

ID of the Manager to whom the user reports

Source

User creation source

Creation Date

Date 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Type

Type of employee

Deletion Date From

Start date of summary of deleted users

Deletion Date To

End date of summary of deleted users

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Type

Type of employee

Manager ID

ID of the Manager to whom the user reports

Source

User creation source

Deletion Date

Date 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Type

Type of employee

Disabled Date From

Start date of user disabled

Disabled Date To

End date of user disabled

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Status

Current status of the employee

Employee Type

Type of employee

Manager ID

ID of the Manager to whom the user reports

Source

User creation source

Disabled Date

Date 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 Parameter

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Type

Type of employee

Unlocked Date From

Start date of user unlocked

Unlocked Date To

End date of user unlocked

Fields

N/A

Columns

The following table lists the columns of the report:

Report Column

Description

First Name

First name of the user

Last Name

Last name of the user

User ID

ID of the user

Organization

Organization of the user

Employee Status

Status of the user

Employee Type

Type of employee

Manager ID

ID of the Manager to whom the user reports

Source

User creation source

Unlocked Date

Date 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:

- Rogue Accounts By Resource
This report returns a list of all the rogue accounts existing in a resource. The following exceptions are reported:

- An account that exists in the target system, but is not provisioned to the corresponding user in Oracle Identity Manager

- An account that exists in the target system, but has been deprovisioned for the corresponding user in Oracle Identity Manager

- Orphaned Account Summary Report: An account that exists in the target system, but the corresponding user to whom the account is provisioned has been deleted in Oracle Identity Manager. For the given input resource, it lists the rogue accounts that exist in the target system, but the corresponding users to whom the accounts are provisioned has never existed in Oracle Identity Manager.

- Fine Grained Entitlement Exceptions By Resource
This report returns a list of all the accounts in a resource for which the process form data being reconciled is different from the expected values. It means that this report returns any account existing in the target system that is also provisioned to the corresponding user in Oracle Identity Manager, but for which the process data does not match.

Note:

- After completion of initial target reconciliation, all account-related activities performed directly on a target resource are tracked as exception activity. Account-related activities include account creation, account modification, and entitlement assignment/revocation. The exception reports should be used only if the organization policies enforce that all account-related activities in target resources would always be initiated in Oracle Identity Manager. In addition, remember that exception detection and recording are an extension of account data reconciliation and, therefore, may result in a drop in performance during reconciliation.

- All the exception reports depend on reconciliation data. Therefore, these reports will not display any data if the corresponding reconciliation events are archived.

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:

Table 20-1 Scheduled Tasks for BI Publisher Reports

Report Name

Scheduled Task Name

Description

Fine Grained Entitlement Exceptions By Resource

RefreshMaterializedView

To refresh the Materialized View used in this report with the latest data

User Profile History

IssueAuditTask

To populate the audit tables with the latest data

User Unlocked

IssueAuditTask

To populate the audit tables with the latest data

User Membership History

IssueAuditTask

To populate the audit tables with the latest data

Role Membership History

IssueAuditTask

To populate the audit tables with the latest data

Resource Access List History

IssueAuditTask

To populate the audit tables with the latest data

User Resource Access History

IssueAuditTask

To populate the audit tables with the latest data

Resource Activity Summary

IssueAuditTask

To populate the audit tables with the latest data

Password Reset Summary

IssueAuditTask

To populate the audit tables with the latest data

Entitlement Reports

Entitlement List

To populate the Entitlement List table with the marked entitlements

Entitlement Assignment

To populate the Entitlement Assignment tables with the assigned entitlements

Entitlement Updates

To populate the latest data into the Entitlement Assignment tables, if any entitlement has assigned to any user periodically or later

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

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

Copyright © 1991, 2013, Oracle and/or its affiliates. All rights reserved.