13 Managing the Access Request Catalog

This chapter provides an introduction to the Access Request Catalog and describes the key features, benefits and use cases of the Access Request Catalog. It contains the following sections:

The Access Request Catalog provides a simple, intuitive, web-based user interface that allows business users to request access to roles, application instance, and additional access (also known as entitlements) within applications.

The Access Request Catalog allows a business to categorize and publish roles, application instance, and entitlements to the Catalog and provide additional business context using extensible metadata. Users use familiar request access for themselves using an intuitive "Catalog search" and "Shopping Cart" user experience.

13.1 Access Request Catalog

This section provides an introduction to the Access Request Catalog. It contains the following sections:

13.1.1 Access Request Challenges

Enterprises have tried to simplify and streamline the process of managing the identity lifecycle and access privileges of end users as part of improving operational efficiency and reducing IT costs. To meet these goals, businesses have tried to implement various solutions to allow end users to manage their own identity and access. However, they have faced several challenges in doing so:

  • End-users had to be trained to understand IT concepts and terminology and use IT processes to request access.

  • The training cycle had to be repeated as new employees joined, lowering productivity, and increasing IT costs.

  • End-users had to get IT assistance when their requests were not fulfilled in a timely manner and did not have visibility into the status of their request.

  • Typically, additional access within an application had to be granted by IT or by Application administrators.

  • This limited business users' view of available access and limited their productivity, while forcing them to rely on IT.

The Access Request Catalog addresses these challenges by providing an easy to use web interface where users can search and browse various types of access and select the ones they need to perform their job duties. It provides the following benefits:

  • The end user does not need to know technical jargon or follow IT processes to request access. The Catalog uses well-known and familiar search and shopping cart patterns to guide the user through the access request process.

  • The end-user does not need to know specific application instance, role or entitlement names. The Catalog provides an extensible metadata model and provides tagging capabilities. This allow business users to specify alternate terms to be used to search for the specific access. End users can search the Catalog using combinations of keywords and wildcards to search for the access they need.

13.1.2 Concepts

The following discussion introduces key access request catalog concepts

  • Catalog

    Catalog (aka Request Catalog) offers a consistent and intuitive request experience for customers to request Roles, Entitlements and Application Instances following the commonly used Shopping Cart paradigm. The catalog is a structured commodity with its own set of metadata.

  • Catalog Item

    A Catalog Item is an item (Roles, Entitlements or Application Instances) that can be requested by a user, either for themselves or on behalf of other users.

  • Category

    A Catalog Item Category is a way to organize the request catalog. Each catalog item is associated with one and only one category. A catalog item navigation category is an attribute of the catalog item. Catalog System Administrators can edit a Catalog Item and provide a value for the category.

    Note:

    You cannot leave Category field blank for a catalog item. Therefore, you must ensure that a value is present for the category.

  • Application Instance

    An Application Instance represents an account on particular target. When users request an application instance, they are requesting an account in a particular target. Application Instances can be connected, if fulfillment is automated via a Connector, or disconnected, if fulfillment is manual. Application Instances can have entitlements associated with them.

  • Enterprise Roles

    Enterprise Roles are defined by customers. Enterprise Roles have policies associated with them. Users can request enterprise roles via the Catalog. When a role is granted, application instances or entitlements are provisioned to the user.

  • Entitlement

    Entitlements are privileges in an application that govern what a user of the application can do.

  • Catalog User-defined field

    Catalog User-defined fields are additional attributes that are added by customers to the Catalog entity

  • Catalog Item Metadata

    Catalog Item Metadata refers to the values for the Catalog Item attributes. Metadata can be managed on a per-item basis by the Catalog System Administrator or can be populated in bulk.

  • Tags

    Tags are search keywords. When users search the Access Request Catalog, the search is performed against the tags. Tags are of three types

    • Auto-generated: The Catalog synchronization process auto-tags the Catalog Item using the Item Type, Item Name and Item Display Name

    • User-defined: User-defined Tags are additional keywords entered by the Catalog System Administrator

  • Catalog System Administrator

    The Catalog System Administrator is a global security role. The Catalog can be managed by members of this role only.

  • Shopping Cart

    The Shopping Cart refers to the collection of Catalog Items that are being requested. A user can have only one cart active at any given time and the cart can contain roles, application instances, entitlements, or any combination of the three.

  • Catalog synchronization

    Catalog synchronization refers to the process of loading roles, application instances, and entitlements into the Catalog.

13.1.3 Catalog Use cases

Use cases in this section explain how the access request catalog make it easy for end users to request roles, application instance, and entitlements required to perform their duties.

Requesting access

Mary, a Manager in MyCorp, would like to request access to MyCorp Trading application for herself and her directs. To do this, she searches the Catalog using the keyword trading. The catalog returns all items that match Mary's keywords and that she is allowed to request. Mary filters the search results by selecting Application from the list of categories. The Catalog returns a reduced set of search results. Mary adds the MyCorp Trading application to the cart and checks out. She adds herself and her directs to the request and submits the request.

Description of req_acc_1.gif follows
Description of the illustration ''req_acc_1.gif''

Administering the Catalog

Jim, a Catalog System Administrator, would like to onboard new application instance and their entitlements, add additional attributes and improve the searchability of the catalog items. He runs the Catalog Synchronization Job scheduled job to harvest the new application instance and their entitlements. Next, he extends the Catalog metadata by adding additional attributes and identifies certain attributes as searchable. Next, he loads the catalog with metadata and tags for the new attributes. For certain Catalog items, he searches the Catalog and edits the Catalog item in place.

Note:

The Catalog System Administrator must have the System Configuration Administrator admin role for running the Catalog Synchronization Job.
Description of req_acc_2.gif follows
Description of the illustration ''req_acc_2.gif''

These use cases are typical examples of using the Access Request Catalog to make applications and entitlements in the applications and roles visible in the Catalog and allowing users to request access to them via simple web-based interface.

13.2 About the Access Request Catalog

This section covers the features and benefits of the Access Request Catalog and its architecture. It contains the following topics

13.2.1 Features and Benefits

The Access Request Catalog is a searchable, categorized collection of entities that are requestable in Oracle Identity Manager. Any authenticated user can access the Catalog and search the Catalog using one or more keywords and search operators, add one or more Catalog items into a shopping cart and submit a request for themselves and others.

Key features of the access request catalog include:

  • Extensible Catalog schema that allows administrators to add additional attributes

    and specify how the attribute is rendered using a simple browser-based UI

  • Automated harvesting of roles, applications, and entitlements

  • Automated loading of Catalog metadata using a CSV file

  • Powerful search using keywords with support for complex search operators

  • Flexible categorization model that allows the Catalog to be organized based on customer choice

  • Catalog search results secured based on viewer privileges of the requester

  • Catalog item data available via a web service for use in workflows

13.2.2 Architecture

Figure 13-1 shows the components of the Access Request Catalog and its relationship with other components of Oracle Identity Manager.

Figure 13-1 High-Level Catalog Architecture

Description of Figure 13-1 follows
Description of ''Figure 13-1 High-Level Catalog Architecture''

The Access Request Catalog consists of the following components:

  1. Catalog Tables

  2. Catalog Loaders

  3. Catalog Metadata

  4. Catalog User Interface in the Identity Self Service Console

13.3 Configuring the Access Request Catalog

This section describes the following configurations for the access catalog:

13.3.1 Adding More Attributes to the Default Search Form

Additional attributes can be added to the catalog search form. The attributes marked as searchable are displayed automatically as text fields in the default search form. These attributes must be added to the cart details form via customization. For information about defining a custom attribute, see "Configuring Custom Attributes".

13.3.2 Configuring Application Selection Limit in Entitlement Search

You can configure the number of applications that can be selected in the default search form during entitlement search. This limit is configurable by using the Catalog Advanced Search Maximum Applications system property. For information about this system property, see "System Properties in Oracle Identity Manager".

13.3.3 Configuring Catalog to Use a Custom Search Form

For advanced customizations to the catalog search, the default catalog search form can be replaced with a custom-built search form. The catalog search form can be configured by using the Catalog Advanced Search Taskflow system property. For information about developing a custom taskflow for catalog search, see "Customizing the Catalog Search Form" in Developing and Customizing Applications for Oracle Identity Manager.

13.4 Administering the Access Request Catalog

This section describes the basic administration of the Access Request Catalog. It consists of the following topics

13.4.1 Pre-requisites

The Access Request Catalog is used by end-users to request access to roles and entitlements to help them perform their duties. As a result, it is very important that the Catalog be current, have a rich metadata and be organized so that users can find the right access. To ensure this, you need to have a plan to manage the Access Request Catalog. The ensuring sections give the steps that you should follow to administer the Catalog. Before implementing those steps, there are certain pre-requisites. These include

13.4.1.1 Setting up the Catalog System Administrator

The Catalog System Administrator is an admin role, similar to the System Administrator and System Configurator role. In Oracle Identity Manager 11g Release 2 (11.1.2.3.0), a member of this role (and those of the System Administrators role) can perform the following actions:

  • Load the Catalog

  • Manage Catalog Items

  • Manage Request Profiles

This role is a global role and not scoped by organization.

To grant the Catalog System Administrator:

  1. Log in to Oracle Identity Self Service.

  2. Click the Manage tab, and click Organizations.

  3. Search and open the Top organization.

  4. Click the Admin Roles tab.

  5. Select the Catalog System Administrator admin role and click Assign in the toolbar.

  6. Search and select the users that you want to assign, and click Add Selected.

  7. Click Add to add the users.

The new members of the Catalog System Administrator role can login to the Self Service Console and start managing the Catalog.

13.4.1.2 Defining the Catalog Metadata

A rich catalog metadata is important to for the following reasons:

  • End-users are only interested in getting access to what they need to perform their job duties. When they search and browse the Catalog, the information presented to them must relate to the business. If the Catalog is sparse (minimal attributes), users will not know which access to pick. If the Catalog is rich but technical, users will get confused and will choose not to use the Catalog.

  • Requesters and Approvers need as much contextual information as possible to help them submit a request or approver one. When approvers review a request, the Catalog item detail helps them understand what is being requested, why and the impact of approving the request.

  • Approval workflows use routing rules to correctly determine approvers. These rules need access to additional context about the requested item to do approver resolution. If the Catalog information is sparse, the routing rules will not have enough data available to determine the correct approvers.

To meet these challenges, the Catalog must contain additional metadata that can help place the access, that is the Catalog item, in the correct business context.

To add one or more attributes to the Catalog:

  1. Log in to the Oracle Identity System Administration Console.

  2. Create and activate a sandbox. See "Managing Sandboxes" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.

  3. Under System Entities, click Catalog.

  4. Click Custom New Attribute to add an attribute.

  5. Select from one of the pre-defined attribute types and click OK.

  6. Provide the necessary information and click Save and Close.

    Note:

    If new custom attribute (UDF) is made Searachable, it is recommended to create a normal index on the database column of the custom attribute for optimal search performance.You can find the database columns of custom attributes in CATALOG table of Oracle Identity Manager schema.

  7. Add additional attributes as required.

    You have completed the first step in extending the Catalog.

  8. If you do not want to modify the Catalog search results or Catalog Item details UI, then you can have your changes reviewed and after approval of the changes, export and publish the sandbox. It is recommended that you export the sandbox to store all the changes made in your sandbox.

    If you want to modify the Catalog search results and Catalog Item details UI, then proceed further.

  9. Logout and login to the Identity Console as a member of the System Administrator role.

  10. Create a new sandbox and activate it.

  11. Add the attribute to the catalog details page by referring to Section 7.5, "Adding a Custom Attribute".

  12. Export and publish the sandbox.

13.4.2 Common Tasks

This section describes the common tasks to be performed by the Catalog System Administrator. It consists of the following tasks:

13.4.2.1 Onboard Applications and Roles

The Access Request Catalog must be populated with enterprise roles, application instances and entitlements so that users can search and request for access. You must develop a process by which enterprise roles, application instances and entitlements can be on-boarded to the Catalog with minimal administrator intervention. This section covers the various steps involved in on-boarding roles, application instances and entitlements into the Catalog.

13.4.2.1.1 Prepare an Onboarding checklist

Use the following oboarding checklist items to develop a high-level process for onboarding roles, application instances and entitlements into the Access Request Catalog. Later, you can follow individual checklists for roles, application instances, and entitlements.

  • Identify Catalog System Administrators

  • Identify and extended Catalog attributes

  • Customize Catalog search results UI

  • Customize Catalog Item Details UI

  • Identify navigational categories

  • Identify Owners, Certifiers, Approvers for roles and applications

  • Identify sources of truth for Catalog Item metadata/glossary

  • Develop procedures to generate and load Catalog item metadata/glossary

  • Develop glossary of tags and a process to maintain tags

13.4.2.1.2 Onboarding Roles

There are no onboarding steps for enterprise roles. Roles, belonging to a role category other than Oracle Identity Manager Roles are published directly to the Catalog when they are created.

When user edits the role and changes its category from Oracle Identity Manager Role to any other category, then the Catalog Synchronization Job scheduled job must be run to have the role searchable in the catalog.

13.4.2.1.3 Onboarding Application Instances

Application Instances require additional configuration before they can be requested by end users. Use the following checklist items to make sure that you have performed the configuration required to onboard application instances:

  • Ensure that the Connector is installed (for new targets)

  • If you are upgrading Oracle Identity Manager from Release 9.1.x or 11g Release 1 to 11g Release 2 (11.1.2.3.0), see "Upgrading Oracle Identity Manager 11g Release 1 (11.1.1.x.x) Environments" of the Oracle Fusion Middleware Upgrade and Migration Guide for Oracle Identity and Access Management for information about mandatory post-upgrade steps

  • Verify that the process forms have an IT resource field

  • Verify that you have defined the form field properties correctly

  • Verify that you have created the application instances with suitable display names and descriptions

  • Verify that you have created the forms required for account requests

  • Verify that you have published the application instances to the relevant organizations

  • For disconnected applications, verify that you have created the application instances. See "Managing Disconnected Resources" for detailed description of the steps

After verifying the steps in the check list, follow the instructions below to onboard application instances.

See Also:

Section 10.2, "Managing Application Instances" for more information on managing Application Instances

Steps to onboard Application Instances

  1. Login to the Identity System Administration as a member of the System Administrator role.

  2. In the left pane, under System Configuration, click Scheduler.

  3. Search for the Catalog Synchronization Job scheduled job.

  4. Check the Process Application Instances parameter.

  5. Set the parameter Mode to Incremental.

13.4.2.1.4 Onboarding Entitlements

Use the following checklist items to make sure that you have performed the configuration required to onboard entitlements.

Note:

Job entitlement list loader should be executed before executing the Catalog Synchronization Job scheduled job.

  • Ensure that the Connector is installed (for new targets)

  • If you are upgrading Oracle Identity Manager from Release 9.1.x or 11g Release 1 to 11g Release 2 (11.1.2.3.0), see "Upgrading Oracle Identity Manager 11g Release 1 (11.1.1.x.x) Environments" of the Oracle Fusion Middleware Upgrade and Migration Guide for Oracle Identity and Access Management for information about mandatory post-upgrade steps

  • Verify that the process forms have an IT resource field

  • Verify that you have defined the form field properties correctly

  • Verify that you have correctly associated the parent and child forms

  • Verify that you have run the common lookup reconciliation job for ICF-based targets

  • Verify that you have run the connector-specific lookup reconciliation jobs for non-ICF connectors

  • Verify that you have created application instances correctly, corresponding to the resource object and IT resource instance specified in the Lookup Reconciliation job

  • Verify that you have published entitlements to relevant organizations

  • Verify that you have run the entitlement list loader job, so that data can be populated in ent_list table

After verifying the steps in the check list, follow the instructions below to onboard entitlements

Steps to onboard Entitlements

  1. Login to Identity System Administration as a member of the System Administrator role.

  2. In the left pane, under System Configuration, click Scheduler.

  3. Search for the Catalog Synchronization Job scheduled job.

  4. Check the Process Entitlements parameter.

  5. Set the parameter Mode to Incremental.

    Note:

    • If its a first time harvesting, then you should set the parameter to Full.

    • If the parameter mode is Incremental, then only those entities are picked by scheduled task for processing, whose create date is greater than update date for creation, and update date is greater than update date value.

13.4.2.2 Bootstrapping the Catalog

Bootstrapping refers to the process of populating the Catalog for the first time. After Bootstrapping large number of any entity, you can gather statistics on base tables. This section refers to bootstrapping the Catalog after you have installed Oracle Identity Manager 11g Release 2 (11.1.2.3.0). If you are upgrading from Oracle Identity Manager 9.1.x or 11g Release 1, then see Chapter, "Upgrading Oracle Identity Manager 11g Release (11.1.1.5.0) Environments" of the Oracle Fusion Middleware Upgrade and Migration Guide for Oracle Identity and Access Management.

Pre-requisites

  • You have extended the Catalog using the Catalog system entities by following the steps given in Section 13.4.1.2, "Defining the Catalog Metadata".

  • You have carried out the necessary UI customization steps required when a user-defined field is added to the Catalog.

13.4.2.2.1 Bootstrapping the Catalog with Roles

There are two ways to bootstrap the Catalog with Roles.

  • Bootstrapping the Catalog with Roles when you are not using Oracle Identity Analytics customer

    In Oracle Identity Manager 11g R2, roles are published immediately to the Catalog when they are created and assigned a role category other than the Oracle Identity Manager Roles category. If you have made changes to the role categories or need to synchronize the enterprise roles with the Catalog, follow the steps given below

    To bootstrap the catalog with roles:

    1. Login to Identity System Administration as a member of the System Administrator role.

    2. In the left pane, under System Configuration, click Scheduler.

    3. Search for the Catalog Synchronization Job scheduled job.

    4. Check the Process Roles parameter.

    5. Set the parameter Mode to Full.

      Note:

      If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.

    6. Click Run Now to run the job immediately or provide a date and time to run the job later.

  • Bootstrapping the Catalog with Roles when you are using Oracle Identity Analytics for managing the lifecycle of enterprise roles

13.4.2.2.2 Bootstrapping the Catalog with Application Instances

Bootstrapping the Catalog with Application Instances requires additional steps to be carried out. Use the checklist given in Section 13.4.2.1.3, "Onboarding Application Instances" to ensure that you have completed the pre-requisites.

Once you have completed the pre-requisites, follow the steps given below to onboard application instances:

  1. Login to Identity System Administration as a member of the System Administrator role.

  2. In the left pane, under System Configuration, click Scheduler.

  3. Search for the Catalog Synchronization Job scheduled job.

  4. Check the Process Application Instances parameter.

  5. Set the parameter Mode to Full.

    Note:

    If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.

  6. Click Run Now to run the job immediately or provide a date and time to run the job later.

13.4.2.2.3 Bootstrapping the Catalog with Entitlements

Bootstrapping the Catalog with Entitlements requires additional steps to be carried out. Use the checklist given in Section 13.4.2.1.4, "Onboarding Entitlements" to ensure that you have completed the pre-requisites.

Once you have completed the pre-requisites, follow the steps given below to onboard entitlements.

  1. Login to Identity System Administration as a member of the System Administrator role.

  2. In the left pane, under System Configuration, click Scheduler.

  3. Search for the Catalog Synchronization Job scheduled job.

  4. Check the Process Entitlements parameter.

  5. Set the parameter Mode to Full.

    Note:

    If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.

  6. Click Run Now to run the job immediately or provide a date and time to run the job later.

13.4.2.3 Ongoing Synchronization

To automate the process of onboarding roles, application instances, and entitlements, you can configure the Catalog Synchronization Job scheduled job in the following manner.

  1. Login to Identity System Administration as a member of the System Administrator role.

  2. In the left pane, under System Configuration, click Scheduler.

  3. Search for the Catalog Synchronization Job scheduled job.

  4. Check the Process Roles, Process Application Instances, and Process Entitlements parameters.

  5. Set the parameter Mode to Incremental.

  6. Provide a date and time to run the job later.

  7. Set the Job frequency to run every five minutes.

13.4.2.4 Enriching the Catalog

Enriching the Catalog refers to the process of populating the Access Request Catalog with data so that the information is available for end-users to see. The additional data helps end-users understand the business context associated with the Catalog Item. The additional data is also available as part of the approval workflow, allowing the workflow to make intelligent routing decisions based on the data about the Catalog Item.

There are two ways to enrich the Catalog:

Pre-requisites

13.4.2.4.1 Editing a Catalog Item Online

To edit a Catalog Item online, using the Oracle Identity Manager Self Service Console:

Note:

Name, Display Name, and Description cannot be edited on the catalog screen. These are base level attributes and you cannot edit from Catalog UI.

When editing a Catalog Item, for list of values (LOV) type of fields, it is recommended to select and specify values by picking from the associated lists, instead of typing the values into the fields directly.

  1. Log in to Identity Manager Self Service as a member of the Catalog System Administrator role.

  2. Click Catalog to access the request catalog.

  3. Enter one or more keywords and click Search.

  4. Use the Refine Search to find the Catalog Item(s) to be edited.

  5. Select the Catalog Item to be edited.

  6. In the Detailed Information section, edit the Catalog Item and click Apply. Verify the confirmation message.

13.4.2.4.2 Enriching the Catalog in bulk from external sources

While Catalog System Administrators can make use of the robust Catalog Item editing capabilities in the Oracle Identity Manager Self Service Console, there are scenarios where the data needs to be loaded in bulk from external sources. Examples of bulk updates:

  • MyCorp wants to provide users with asset information from their IT CMDB system or from their Corporate Asset Management system. The information cannot be entered manually since the CMDB or AMS system gets updated on a regular basis. In such a scenario, MyCorp needs a way to update the Catalog in bulk.

  • MyCorp was using a home grown access request application prior to implementing Oracle Identity Manager 11g R2. This application contains the glossary and other relevant information about the roles, application instances and entitlements. As part of migrating to Oracle Identity Manager 11g R2, MyCorp Catalog System Administrators would like to move the Catalog Item information from the legacy system.

13.4.2.4.3 Loading data from an external source

Follow the steps given below to load data from an external source into the Catalog:

  1. Export the data to be loaded into a comma-separated values format file.

  2. Ensure that the first line of the file contains the Catalog attribute names.

  3. Move the file to a file system that is accessible from the server on which is Oracle Identity Manager is deployed.

  4. Login to Identity System Administration as a member of the System Administrator or System Configurator role.

  5. In the left pane, under System Configuration, click Scheduler.

  6. Search for the Catalog Synchronization Job scheduled job.

  7. Provide the full path to the file in the parameter File Path.

  8. Set the value of the parameter Mode to Metadata. Table 13-1 provides sample parameter details.

    Table 13-1 Catalog Metadata Loader Sample

    Parameter Value

    ENTITY_TYPE

    Role

    ENTITY_KEY

    12

    ENTITY_NAME

    test

    IS_REQUESTABLE

    1

    USER_DEFINED_TAGS

    UDTags

    CATEGORY

    mycategory

    AUDIT_OBJECTIVE

    AO111

    APPROVER_USER

    1

    APPROVER_ROLE

    1

    FULFILLMENT_USER

    1

    FULFILLMENT_ROLE

    1

    CERTIFIER_USER

    1

    CERTIFIER_ROLE

    1

    ITEM_RISK

    5

    CERTIFIABLE

    1

    STUDF

    1

  9. Click Run Now to run the job immediately, or select a date and click Apply to run the job later.

13.4.2.5 Managing Catalog Items

This section contains the following topics

13.4.2.5.1 Deleting a Catalog Items of Type Roles

To delete role Catalog Items:

  1. Login to Identity Self Service.

  2. Search for the role to be deleted and delete the role.

  3. The associated Catalog Item are marked as soft-deleted and will not appear in the Catalog.

  4. For deleting large number of roles, use the APIs to delete the role. It is not recommended to use database techniques to delete roles.

13.4.2.5.2 Deleting Catalog Items of Type Application Instances

Application Instances, in almost all use cases, represent a target system (sometimes known as an endpoint) and an account in a target system. When you delete an Application Instance, you are essentially decommissioning the target system from Oracle Identity Manager. Depending upon the scale of your deployment and the number of accounts provisioned to the target system, deleting an Application Instance can have a significant impact to the end users and their access.

To delete application instance Catalog Items:

  1. Login to Oracle Identity System Administration.

  2. Click Application Instances.

  3. Search for application instances.

  4. Select one or more application instances. Delete and confirm.

  5. Click Scheduler.

  6. Search for the Catalog Synchronization Job scheduled job.

  7. Set the Mode to Incremental.

  8. Click Run Now to run the job immediately or set it up to run at a particular time.

See "Deleting Application Instances" for more information about deleting application instances.

13.4.2.5.3 Deleting Catalog Items of type Entitlements

To delete entitlement Catalog Items:

  1. To delete Entitlements, login to Oracle Identity System Administration.

  2. Click Lookups.

  3. In the Code column, enter the name of the Lookup Definition that contains the entitlement. Refer to the Connector documentation to find out the name of the Lookup Definition.

  4. Delete one or more entitlement values.

  5. Click Scheduler.

  6. Search for the Entitlement List Load job.

  7. Click Run now.

  8. Search for the Catalog Synchronization Job scheduled job.

  9. Set the Mode to Incremental.

  10. Click Run Now to run the job immediately or set it up to run at a particular time.

13.4.3 Configuring Catalog Auditing

Catalog auditing maintains a footprint of changes in the access request catalog. By enabling catalog auditing, you can track who changes what and when in the access request catalog through the UI.

Catalog auditing stores the footprints of the following changes in the access request catalog:

  • A change in the value of a catalog UDF.

  • Any value of a catalog item attribute is changed from the catalog UI or any other custom UI.

  • Following is the list of consolidated catalog attributes that are part of auditing during updation of catalog item:

    Category, Audit Objective, Approver User, Approver Role, Fulfillment User, Fulfillment role, Certifier User, Certifier Role, Item Risk, Certifiable

Note:

Auditing takes place only for those entities that can be modified through the Catalog UI. Audit does not happen for entities that are modified in the catalog through synchronization. In addition, auditing is not supported for User Defined Tags.

To configure catalog auditing:

  1. Login to Oracle Identity System Administration.

  2. Under System Configuration, click Configuration Properties.

  3. Search for the Catalog Audit Data Collection system property with keyword XL.CatalogAuditDataCollection. The default value of this property is none, which specifies that catalog auditing is disabled.

  4. Set the value of the XL.CatalogAuditDataCollection system property to catalog. This enables catalog auditing.

  5. Click Save.

After enabling catalog auditing, the changes in the access request catalog are audited. For changes in the access request catalog, such as changing the risk level of a role, the footprints of the changes are stored in the CPA_CATALOG and CPA_CATALOG_FIELDS tables in the database on running the Issue Audit Massages Task scheduled job. For information about this scheduled job, see "Predefined Scheduled Tasks" in the Oracle Fusion Middleware Administering Oracle Identity Manager.

13.4.4 Configuring Hierarchical Attributes of Entitlements

You can enable the display of hierarchical attributes of entitlements to requesters, approvers, and certifiers to view additional details of entitlements (hierarchical attributes) in the catalog detail screen. The additional details of entitlements is called technical glossary. The technical glossary is displayed in a list view with bread crumbs at the top showing the navigational path. For information about viewing the additional details in the catalog detail screen, see "Viewing Hierarchical Attributes of Entitlements" in Performing Self Service Tasks with Oracle Identity Manager.

Note:

The child entitlements are not requestable in the access catalog. The hierarchical entitlements feature is meant for display purpose only.

The additional details or hierarchical attributes is read-only information. This information must be provided in the form of an XML, which is seeded in Oracle Identity Manager. The technical glossary is inserted and replaced in the database. The following is a sample XML code of the hierarchical attributes:

<oim>
      <applicationInstances>
            <applicationInstance>SampleEBS</applicationInstance><!-- Application Name for which entitlements are seeded-->
      </applicationInstances>
      <attributes>
            <attribute name="Responsibility Name"><!-- Label name of the field which is marked Entitlement field in Child form-->
                  <entitlementValues>
                        <entitlementValue><!-- Below is the Hierarchical data XML for Entitlement and Entitlement Display Name is used to denote entitlement -->
<value>Payables Menu</value>
<attributes>
      <attribute name="Menu">
            <entitlementValues>
                  <entitlementValue>
<value>ALR_OAM_NAV_GUI_USER_NAME</value>
<description>Alerts Manager View</description>
<attributes>
      <attribute name="Function Code">
            <entitlementValues>
                  <entitlementValue>
      <value>ALR_OBJ_ACTIVATE_ACCT</value>
      <description>Create, Activate, Deactive User Account</description>
</entitlementValue>
<entitlementValue>
<value>ALR_OBJ_EDIT_FORM</value>
</entitlementValue>
<entitlementValue>
<value>ALR_OBJ_VIEW_PERSON</value>
                  </entitlementValue>
            </entitlementValues>
      </attribute>
</attributes>
                  </entitlementValue>
                  <entitlementValue>
<value>EMPLOYEE_W2_MENU</value>
<description>Alerts Manager View</description>
<attributes>
      <attribute name="Function Code">
            <entitlementValues>
<entitlementValue>
      <value>Employee_OBJ_ACTIVATE_ACCT</value>
      <description>Create, Activate, Deactive User Account</description>
</entitlementValue>
<entitlementValue>
      <value>Employee_OBJ_EDIT_FORM</value>
</entitlementValue>
<entitlementValue>
      <value>Employee_OBJ_VIEW_PERSON</value>
</entitlementValue>
            </entitlementValues>
      </attribute>
                        </attributes>
                  </entitlementValue>
                  <entitlementValue>
<value>VISION_OAM_NAV_GUI</value>
<description>Alerts Manager View</description>
<attributes>
                        </attributes>
                  </entitlementValue>
            </entitlementValues>
      </attribute>
                              </attributes>
                        </entitlementValue>
                  </entitlementValues>
            </attribute>
      </attributes>
 
</oim>

RDBMS features, such as Securefile LOB and Oracle XML DB, are used for storing hierarchical data in Oracle Database. Securefile is a new re-architecture featuring entirely new disk formats, network protocol, space management, redo and undo formats, buffer caching, and intelligent I/O subsystems. It delivers substantially improved performance along with optimized storage for unstructured data, which resides in Oracle Database as compared to LOB's storage structure. Oracle XML DB provides a high-performance, native XML storage and retrieval technology. It absorbs the W3C XML data model into the Oracle Database, provides new standard access methods for navigating and querying XML, and provides the advantages of relational database technology together with the advantages of XML.

To enable the display of additional details of the entitlements in the access request catalog:

  1. Seed the additional hierarchical data in Oracle Identity Manager. To do so, create a XML file per the XSD with all the additional details about the entitlement. The XSD is used to register XML schema in the database.

  2. Place the XML file in a directory in the Oracle Identity Manager server. You must have read and write permissions on the directory.

  3. Specify the details of the technical glossary in the Catalog Synchronization Job scheduled job. To do so:

    1. Login to Oracle Identity System Administration.

    2. Under System Configuration, click Scheduler.

    3. Search and open the Catalog Synchronization Job scheduled job.

    4. In the Parameters section, in the Mode field, enter Technical Glossary.

    5. In the File Path field, enter the directory path of the XML file.

    6. Click Apply.

When you run the Catalog Synchronization Job scheduled job, a new link, which is called technical glossary details, is displayed just before the catalog details link for entitlements. Clicking this links opens the technical glossary additional information in a different tab. The XML file is deleted from the directory after processing and is moved to the archive directory with time stamp appended to its name.

Any failed record is logged in a file, which is placed in the xmlprocessedlogs directory. The log file has the name of the XML file with time stamp appended to it.

13.4.5 Database Best Practices for Access Request Catalog

Access Request Catalog uses "Oracle Text" option in Oracle database for text search capabilities. Oracle Text is a fast and accurate full-text retrieval technology integrated with Oracle Database.

The CATALOG table which contains catalog items is indexed using CONTEXT index type of Oracle Text. Although Oracle Text index operates like a regular database index, the architecture and processing behind Text index highlights the importance of best practices when creating the Text index and also the on-going maintenance.

Following sections are aimed at providing more information in this regard for Oracle Identity Manager administrators and database administrators.

13.4.5.1 One-Time Optimizations for Oracle Text Index

When you install Oracle Identity Manager, the Text index for Access Request Catalog is created with possible optimizations. However, Oracle Text has some more optimizations that are better applied based on the characteristics of the deployment. Following are the optimizations that you should consider applying for improving Access Request Catalog search performance. It is important to note that Access Request Catalog is not usable when applying these and these are recommended to be done during a scheduled maintenance window.

Note:

Catalog Synchronization Job and Access Request Catalog should be down when these one-time optimizations are applied.

Storage of Text Index

Oracle Text index is stored in relational tables (DR$) which are presently resides in the default tablespace of Oracle Identity Manager schema. It is recommended to separate them out to their own tablespace. You can use the following commands to do that. You are recommended to be familiar with these steps and also make changes where needed.

  1. Login to SYS schema and create a new tablespace to hold the text index internal tables. You can use the following sample command for it. Replace DATA_DIR with the directory in which you want to store the data file and adjust the size and other parameters as necessary for your environment.

    CREATE TABLESPACE catalog_text_ind_tables
 DATAFILE 'DATA_DIR/catalog_text_ind_tables_01.dbf' SIZE 2048M REUSE
 EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

  2. Connect to the database using Oracle Identity Manager schema.

  3. Create a storage preference using the commands below. Oracle recommends you to be familiar with BASIC_STORAGE clause of Oracle Text and add more storage clauses if required. You can find more info on BASIC_STORAGE in Oracle Text Reference document.

    Begin
Ctx_Ddl.Create_Preference('cat_storage', 'BASIC_STORAGE');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage','I_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 5M next 5M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'K_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 5M next 5M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'R_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M) lob (data) store as (cache)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'N_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'I_INDEX_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M) compress 2');
End;
/

  4. Apply the new storage preference using the following command. Make sure the Text index status is valid after this step.

    ALTER INDEX CAT_TAGS rebuild parameters ('replace storage cat_storage');

  5. Verify that the above tables are moved to the new tablespace by querying USER_SEGMENTS table.

KEEP Pool Settings for Text Index:

Oracle recommends put all the tables that make up the Text index in database KEEP pool to improve the performance of Access Request Catalog search. You must size the KEEP pool (DB_KEEP_CACHE_SIZE) correctly so that these Text index tables and other Oracle Identity Manager objects are retained in KEEP pool. To do so:

  1. Connect to the database using Oracle Identity Manager schema.

  2. Compute the size of the text index using the following query and use that to set/adjust DB_KEEP_CACHE_SIZE accordingly.

    SELECT ctx_report.index_size('CAT_TAGS') FROM dual;

  3. Run the following commands as Oracle Identity Manager schema user to put the tables in KEEP pool.

    ALTER INDEX DR$CAT_TAGS$X STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$R STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$R STORAGE (buffer_pool keep) MODIFY lob (data) (STORAGE (buffer_pool keep));
ALTER TABLE DR$CAT_TAGS$K STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$I STORAGE (buffer_pool keep);

13.4.5.2 Text Index Optimization

The Text index could become fragmented due to on-going "Catalog Synchronization" Optimizing the text index on regular basis removes the old data and minimizes the fragmentations, which can improve the search performance of Access Request Catalog. To perform this, Oracle Identity Manager has introduced the following Oracle Database scheduler jobs:

  • FAST_OPTIMIZE_CAT_TAGS

  • REBUILD_OPTIMIZE_CAT_TAGS

These jobs reside in Oracle Identity Manager database schema and they are disabled by default. Oracle strongly recommends you to view these jobs, make schedule changes if needed and enable them. When changing the schedule, make sure the new schedule is set on the same line as the default schedule.

FAST_OPTIMIZE_CAT_TAGS meant to be running on frequent basis. By default, it is scheduled to run once a day at 1 AM. REBUILD_OPTIMIZE_CAT_TAGS does a full optimization and rebuilds the Text index. REBUILD_OPTIMIZE_CAT_TAGS is not meant to be running frequent basis. By default, REBUILD_OPTIMIZE_CAT_TAGS is scheduled to run every Sunday at 2 AM. Note that optimization may take a long time if your Text index is big.

Perform the following steps to change the schedule and/or enable these jobs.

  1. Make sure the default schedule (daily 1 AM for FAST and every Sunday 2 AM for REBUILD) is acceptable to your environment. If not, change the schedule. If you are not sure, you can keep the default schedule and change later when needed.

  2. Enable the jobs using the following commands:

    BEGIN
DBMS_SCHEDULER.ENABLE ('FAST_OPTIMIZE_CAT_TAGS');
END;
/
 
BEGIN
DBMS_SCHEDULER.run_job ('REBUILD_OPTIMIZE_CAT_TAGS');
END;
/

    Note:

    The Text index optimization can be done when the server is up and search of Access Request Catalog takes place.

13.5 Managing the Lifecycle of the Catalog

This section describes how to move Catalog customizations from a test environment to a production environment. You can extend the Catalog, customize the Catalog UI, and develop and test the customizations in a test environment, and then eventually roll out the customizations to your production environment.

This section includes the following topics

13.5.1 Overview of Catalog Customization

While the Access Request Catalog provides robust and rich out of the box functionality, there may be scenarios where you need to extend the Catalog and customize it to meet your business needs.

The following scenarios illustrate common scenarios where the Catalog may require customization.

  • MyCorp would like to add additional attributes, such as Cost to Line of Business and License Required, to give the requester an idea about the cost that would be incurred by the Line Of Business, when the requested item was granted. To support this scenario, the Catalog System Administrator extends the Catalog and adds two additional attributes, Cost to Line of Business and License required. Next, the administrator customizes the Catalog search results and Catalog item details page.

    Note:

    In the request catalog, only String type of UDF can be created. If you mark that attribute as searchable attribute, it is of size 256 Char. If it is not a searchable attribute, then it is of size 2000 Char. You cannot mark a non-searchable attributes to searchable.

  • MyCorp would like to show the Risk associated with an entitlement as part of Catalog search results. To support this scenario, the Catalog System Administrator customizes the Catalog search results and adds the item risk as an image widget.

These customizations are implemented by System Integrators or the customer's own IT staff and need to be moved to Test and to Production. Figure 13-2 shows the high-level process of moving customizations from Test to Production for the Catalog.

Figure 13-2 Test to Production Process for Catalog

Description of Figure 13-2 follows
Description of ''Figure 13-2 Test to Production Process for Catalog''

Catalog customizations have three components:

  1. ADF customizations

    ADF customizations include Catalog UI customizations including search results, item details, cart details and Catalog attributes added or modified using the Form Designer. These customizations should be done within a Sandbox session. For more information on Sandboxes, please refer to Section 13.5.2, "Test to Production procedures for Catalog customizations"

  2. Oracle Identity Manager metadata customizations

    When you add new attributes to the Catalog entity or modify an existing attribute and change its properties, additional metadata is generated in Oracle Identity Manager. For example, if a new attribute, Secondary Approver, is added to the Catalog entity using the Catalog system entities, Oracle Identity Manager adds a database column corresponding to the attribute. If the attribute is searchable, Oracle Identity Manager stores additional metadata. These customizations should be moved from Test to Production using the Deployment Manager.

  3. Data Migration

    The Catalog needs to be populated with relevant information, after adding/ modifying attributes in the Catalog to make the Catalog business-friendly and provide enough information so that users can use the Catalog effectively. Once this additional information, also referred to as the Glossary, has been reviewed and approved, it needs to be moved to Production.

13.5.2 Test to Production procedures for Catalog customizations

This section describes the steps to perform for moving the Catalog definition from Test to Production. It consists of the following steps:

Depending upon the type of customization done, you may need either one or both the steps. Use Table 13-2 to make a determination of which steps to carry out.

Table 13-2 Catalog Customization Steps

Customization Sandbox required Deployment Manager required

Adding/ Modifying a seeded Catalog attribute

Yes

Yes

Adding/ Modifying a Catalog UDF

Yes

Yes

Customizing Catalog UI

Yes

No

Populating Catalog

No

No

See Also:

13.5.2.1 Exporting using the Sandbox and Deployment Manager

To Export Using Sandbox

To move the ADF customizations from Test to Production, follow the steps given below:

  1. Login to Oracle Identity System Administration as a member of the System Administrator role.

    Note:

    In scenarios where you need to switch between the Self Service (or Identity) and System Administration consoles and the Oracle Identity Manager 11g R2 deployment is not protected by Single Sign On, you must log out of one console before logging in into another.

  2. Click Sandbox and select the Sandbox to be exported.

  3. Click Export Sandbox. A sandbox can be exported as a file for transporting, sharing, and other usages where packaging it as a file is required.

  4. Specify a file location for the zip file created.

To Export Using Deployment Manager

Note:

Make sure that you do not have any popup blockers enabled in your browser and that you have a supported Java Runtime Environment (JRE) installed in the browser. This is because the Deployment Manager uses a popup window and it requires JRE to be installed in the browser.

To export the Oracle Identity Manager metadata from Test to Production, follow the steps given below:

  1. Login to Oracle Identity System Administration as a member of the System Administrator or System Configurator role.

  2. In the left pane, under System Configuration, click Export.

  3. Select Catalog Metadata as the object to be exported.

  4. Enter * in the search field and click Search.

  5. Follow the steps to generate the Deployment Manager XML.

Note:

Perform the following optional steps as a best practice:

  • Backup/Check-in the sandbox zip file and the Deployment Manager XML as a single file into a source code control system like Subversion, SourceSafe, and so on.

  • Repeat the steps above in the target (Production) environment and backup the Catalog entity and the Catalog UI.

13.5.2.2 Importing Using the Deployment Manager and Sandbox

Importing the customizations should be done in the reverse order. This is required since the ADF customizations expect the Oracle Identity Manager metadata to be present, when the ADF customizations are imported.

To Import Using Deployment Manager

To import the Oracle Identity Manager metadata from Test to Production:

  1. Login to Oracle Identity System Administration as a member of the System Administrator or System Configurator role.

  2. In the left pane, under System Configuration, click Import.

  3. In the File browser popup, select the Deployment Manager XML file to be imported.

  4. Follow the wizard steps to import the XML.

To import using the Sandbox

To move the ADF customizations from Test to Production:

  1. Login to Oracle Identity System Administration as a member of the System Administrator role.

    Note:

    In scenarios where you need to switch between the Self Service (or Identity) and System Administration consoles and the Oracle Identity Manager 11g R2 deployment is not protected by Single Sign on, you must log out of one console before logging in into another.

  2. Click Sandbox and then click Import Sandbox.

  3. In the dialog, select the file to be imported.

  4. In the left pane, under System Configuration, Click Import.

  5. In the Sandbox Manager, select the sandbox and click Publish Sandbox.

  6. Logout and log back in to view and verify the changes.

13.5.3 Limitations of the Test to Production procedures

There are some limitations in the Test to Production process for the Catalog, including the following:

  • All ADF customizations must be done within a single sandbox session. While you can have multiple sandboxes, only one sandbox can be active at a time and as a result, changes in the System Administration Console i.e. Catalog entity extension and those done in the Identity Console, that is, Catalog UI customization, must be done in the same sandbox.

  • Changes done outside a sandbox or done either before creating and activating a sandbox or after, are not visible in the sandbox.

  • Once you publish a sandbox, you cannot export it or revert it. As a result, you must export the sandbox while it is still activated and not published and also ensure that you back your customizations before you import and publish a sandbox.

  • Deployment Manager imports are committed immediately. There is no rollback capability in the Deployment Manager.

13.6 Troubleshooting

This section describes the troubleshooting procedures to be followed while resolving issues with the Access Request Catalog. It contains the following topics

13.6.1 Catalog synchronization issues

Catalog synchronization issues occur when roles, application instances and entitlements are not visible in the Access Request Catalog. Use the flow charts given below to troubleshoot synchronization issues for each of three Catalog item types that can be requested.

Note:

Harvesting job picks up the data for harvesting on the basis of the Update date parameter. If the update is blank, then all the records are fetched for processing.However, if the user has specified some date in the Update date parameter, only that data is processed which is created or updated after the given date.

  • Troubleshooting synchronizing Roles with the Catalog

    The synchronization of Roles with the Catalog is real-time in nature. When a role is created, it is published to the Catalog immediately as long as it does not belong to the Oracle Identity Manager Roles category.

Note:

The Oracle Identity Manager Roles role category is meant for Oracle Identity Manager usage only. Customers should not use this category for their enterprise Roles.

In a new Oracle Identity Manager 11g R2 installation, enterprise roles created by customers are available in the Catalog and the visibility is based on the organization scoping. In an upgraded environment, customers will have to run the Catalog Synchronization job in a bootstrap mode to publish the existing roles to the Catalog. New roles, created after upgrade, is available in the Catalog immediately.

Figure 13-3 shows a diagnostic flowchart that customers can use to troubleshoot scenarios where the roles created in Oracle Identity Manager are not visible in the Catalog.

Figure 13-3 Catalog Synchronization Diagnostic Flowchart

Description of Figure 13-3 follows
Description of ''Figure 13-3 Catalog Synchronization Diagnostic Flowchart''

13.6.2 Catalog security issues

Catalog security is driven by two factors:

  • The security model that uses Organization-based scoping for users, roles, application instances and entitlements. This security model controls what items a requester can see in the Catalog search results and the users who can be added as target users.

  • The security model that is not scoped by organization and is used for global Admin Roles such as Catalog System Administrator.

Typical issues with Catalog security are:

  • Requesters cannot see the Catalog item even though they have entered the correct search keyword.

  • Requesters are not able to add target users to the request

  • Requesters are not able to provide additional information for application instance requests

  • Requesters cannot see Catalog Item details such as Approver User, Approver Role, Fulfillment User, and Fulfillment Role.

  • Catalog System Administrators do not see the Catalog Item in an edit mode and are not able to edit the Catalog Item

  • Catalog System Administrators are not able to create Request Profiles

Figure 13-6 shows a diagnostic flow chart to be followed to troubleshoot issues with Catalog security.

Figure 13-6 Diagnostic Flowchart With Security Issues

Description of Figure 13-6 follows
Description of ''Figure 13-6 Diagnostic Flowchart With Security Issues''

13.6.3 Catalog Search Issues

Figure 13-7 shows a diagnostic flow chart to be followed to troubleshoot issues with Catalog search.

Note:

Search Criteria for Catalog API's findCatalog method supports only AND conjunction operator.

13.6.4 Common Reasons for Request Failure

When the associated operations specified in a request fail to execute, the request cancels any pending operations and moves the request to the Request Failed stage. Clicking the Request Failed hyperlink displays the reason for request failure.

A request can fail for any one of the following reasons:

  • If you are requesting a role, then your request can fail due to an SoD violation.

  • If you are requesting an application instance and that application instance depends on another application instance, then the request moves to 'Request Approved Fulfillment Pending' status because the parent application instance is not provisioned. For example, to successfully provision a user to a Microsoft Exchange account, the user must have a Microsoft Active Directory account in the domain controller that is managing the users of the Exchange server.

In addition to the preceding reasons, failures can occur because of incorrect password, password policy violation, target system being unavailable, and so on.