1 Introduction

This chapter explains integration concepts for the Oracle Identity Management suite.

The chapter contains these topics:

1.1 Prerequisites to Integration

Before using the procedures in this document to integrate Oracle Identity Management components, you must install and deploy the components. These prerequisites are explained in the following sections:

For details about installing Oracle Identity Management components, see:

  • Installation Guide for Oracle Identity and Access Management

  • Oracle Fusion Middleware Quick Installation Guide for Oracle Identity and Access Management

1.1.1 Understanding the Installation Roadmap

You will take (or may already have taken) one of these paths in your IdM deployment:

  • Installation, followed by component integration, and ending with scale-out (HA)

  • Installation, followed by scale-out, and ending with integration

With scale-out, you may already have performed some of the integration procedures described here; notes in the relevant sections can help you determine whether a procedure is needed.

The Introduction chapter in the Installation Guide for Oracle Identity and Access Management contains background on the IdM deployment procedure and describes the installation roadmap, prerequisites, and the installation and configuration workflow.

Oracle Fusion Middleware High Availability Solutions in the High Availability Guide explains the high availability solutions in Oracle Fusion Middleware, as well as the topologies and architecture of the various HA options.

1.1.2 Understanding Deployment Topologies

You must also understand the identity management topology and the environment in which the components will work together.

To learn more about the topology supported in this document, see Section 1.2.

1.1.3 About LDAP Synchronization in Oracle Identity Manager

Enable LDAP synchronization in Oracle Identity Manager before starting this integration.

If you did not enable LDAP synchronization by using the OIM Configuration Wizard during installation, refer to Appendix E, "Enabling LDAP Synchronization in Oracle Identity Manager" for instructions.

The following topics provide an overview of the integration between LDAP identity store and Oracle Identity Manager:

1.1.3.1 The Identity Store

Oracle Identity Manager provides the ability to integrate an LDAP-based identity store into Oracle Identity Manager architecture. 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 are pulled into Oracle Identity Manager and made available as a part of the identity context.

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

  • Changes made in Oracle Identity Manager: User creation, modification, deletion, changes in enabled/disabled state and locked/unlocked states, and password changes are synchronized to LDAP.

  • 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. However, a change to a user password made in LDAP is not 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.

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) and Identity Virtualization Library (libOVD). 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. libOVD is an LDAP virtualization layer (based on OVD) embedded in Fusion Middleware components, such as Oracle Identity Manager and Access Manager. It is not a standalone LDAP server like OVD.

Figure 1-1 shows the communication between Oracle Identity Manager and LDAP.

Figure 1-1 Oracle Identity Manager and LDAP

Description of Figure 1-1 follows
Description of ''Figure 1-1 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:

1.1.3.2.1 Configuring the Integration with LDAP

Configuring the integration between Oracle Identity Manager and LDAP is performed after installing Oracle Identity Manager. When integrating LDAP with Oracle Identity Manager, you must create a container to store reserved users, create a new user in Oracle Identity Manager to perform Oracle Identity Manager operations, and configure OVD (or libOVD) with a directory server to work with Oracle Identity Manager. These tasks are explained in the subsequent sections.

The post-configuration utility, as described in Section E.2.1, "Running the LDAP Post-Configuration Utility", enables the following scheduled jobs in Oracle Identity Manager. It updates the Last Change Number parameter of each job with the value found in the LDAP 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 Administering Oracle Identity Manager.

See Also:

"Managing Scheduled Tasks" for detailed information about scheduled jobs in Administering Oracle Identity Manager.
1.1.3.2.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 Directory Server 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.

This section describes the following topics:

1.1.3.2.3 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

1.1.3.2.4 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

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

"Managing Scheduled Tasks" for information about scheduler and scheduled tasks in Administering 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 "Using the Bulk Load Utility" in Developing and Customizing Applications 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.

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

1.1.3.2.6 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 Administering 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 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 use cases (sample parameters are shown):

  • 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=sampleuser1,cn=users,cn=subrealm1,dc=us,dc=example,dc=com"

  • All users and roles or groups under the node are reconciled:

    The value of Reconciliation Search Base is:

    "cn=subrealm1,dc=us,dc=example,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 are reconciled:

    The value of Reconciliation Search Base is:

    "cn=users,cn=subrealm1,dc=us,dc=example,dc=com"

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

  • All roles or groups under the node are reconciled:

    The value of the Reconciliation Search Base parameter is:

    "cn=groups,cn=subrealm1,dc=us,dc=example,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 Server' IT resource configuration is used for both provisioning and full reconciliation.Sample values for the Reconciliation Search Base parameter:

"cn=subrealm1,dc=us,dc=example,dc=com"

Sample values for the Search Base parameter:

"dc=us,dc=example,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.

1.1.4 About Using Oracle Virtual Directory with Access Manager

Using Oracle Virtual Directory with Oracle Access Management Access Manager (Access Manager) is optional. However, if you plan to use Oracle Virtual Directory with Access Manager, then you must configure Oracle Virtual Directory for integration with Access Manager before starting the core integration procedures described in this publication.

Refer to Appendix F, "Configuring Oracle Virtual Directory for Integration with Oracle Access Management Access Manager" for instructions.

1.1.5 Common Environment Variables

This document uses shorthand notation to refer to common environment variables. For example, the Oracle Middleware Home directory is often referred to as MW_HOME.

For a list of common environment variables, see "Identifying Installation Directories" in the Installation Guide for Oracle Identity and Access Management.

1.2 Integration Topologies

Oracle Identity Management consists of a number of products, which can be used either individually or collectively. Two basic types of topology are available in Oracle Identity Management:

  • Basic integration topology

    This topology supports integration between suite components, in an environment where each component runs on a separate node.

  • Enterprise integration topology

    This topology supports integration between suite components in an enterprise environment. Each component may run on multiple nodes.

Topology Described in this Document

This book is dedicated to the first type, single-node integration topology. Use the procedures described in this book when deploying Oracle Identity Management in an environment where each component runs on its own node. You can also use the procedures to understand integration tools and techniques, and to understand the effects and benefits of integrating specific identity management components.

1.2.1 Basic Integration Topology

See Also:

Table 1-1 for definitions of acronyms used in this section.

Figure 1-2 shows a basic integration topology where the IdM components Access Manager and Oracle Identity Manager are configured on separate WebLogic domains:

Figure 1-2 Basic Integration Topology with Multiple Administration Servers

Split-Domain IdM Architecture

Note that:

  • All IdM components, including Access Manager server (AMHOST), the Oracle Identity Manager server (OIMHOST), and Oracle Internet Directory (OID) are configured in separate WebLogic domains, and each is administered by its own administration server.

    Besides enhancing management of each component, this topology ensures you have flexibility when applying patches and upgrades. Patches for each component can be applied independently, with no version dependency on other components.

  • For simplicity, some of the OMSS topology is omitted; for example the MSAS server which resides in the DMZ is not shown in the diagram. For complete details of OMSS architecture, see Section 5.2.

  • The BIP server and SOA Suite reside on the OIM domain; they are not shown in the diagram.

  • The figure shows some representative ports only.

About SOA Suite for Oracle Identity Manager

The SOA Suite used by OIM must be installed in the same domain as OIM. However, if you use SOA Suite for other purposes, you should consider setting up a separate install of SOA Suite for running your own services, composites, and other SOA features for that purpose.

About Single Domain Architecture

In the single-domain architecture, Oracle Access Management Access Manager, Oracle Identity Manager, and Mobile Security Access Server are configured on the same WebLogic domain. While possible, such a topology is not practical in the current context for the reasons cited above, and is not recommended for IdM integration.

See Also:

Section 1.3 for an introduction to each IdM component.

1.2.1.1 The Three Tier Architecture

This architecture can be viewed as consisting of three layers or zones:

  • The Web Tier consists of the HTTP server and handles incoming Web traffic.

  • The Application Tier contains identity management applications for managing identities and access, including Oracle Identity Manager and Oracle Access Manager.

  • The Data Tier, here considered to include the directory servers, hosts LDAPs and database.

1.2.1.2 Understanding the Web Tier

The web tier is in the DMZ Public Zone. The HTTP servers are deployed in the web tier.Most Identity Management components can function without the web tier. However, the web tier is required to support enterprise level single sign-on using products such as Access Manager.

The web tier is structured as follows in the single-node topology:

  • WEBHOST has Oracle HTTP Server, WebGate (an Access Manager component), and the mod_wl_ohs plug-in module installed. The mod_wl_ohs plug-in module enables requests to be proxied from Oracle HTTP Server to a WebLogic Server running in the application tier.WebGate, an Access Manager component in Oracle HTTP Server, uses Oracle Access Protocol (OAP) to communicate with Access Manager running on OAMHOST. WebGate and Access Manager are used to perform operations such as user authentication.

1.2.1.3 Understanding the Application Tier

The application tier is the tier where Java EE applications are deployed. Products such as Oracle Identity Manager, Oracle Mobile Security Suite, Oracle Access Management Identity Federation, and Oracle Enterprise Manager Fusion Middleware Control are among key Java EE components deployed in this tier.

The Identity Management applications in the application tier interact with the directory tier as follows:

  • They leverage the directory tier for enterprise identity information.

  • They leverage the directory tier (and sometimes the database in the data tier) for application metadata.

  • Fusion Middleware Control Console provides administrative functions to the components in the application and directory tiers.

  • Oracle WebLogic Server has built-in web server support. If enabled, the HTTP listener exists in the application tier as well.

1.2.1.4 Understanding the Data Tier

The data tier is the deployment layer where all the LDAP services reside. This tier includes products such as Oracle Internet Directory (OIDHOST), Oracle Virtual Directory (OVDHOST), Oracle Unified Directory, and Oracle Database (IDMDBHOST).

The data tier stores two types of information:

  • Identity Information: Information about users and groups resides in the identity store.

  • Oracle Platform Security Services (OPSS): Information about security policies and about configuration resides in the policy store.

Storing Policy Data

Policy information resides in a centralized policy store that is located within a database. You may store identity information in Oracle Internet Directory or in another directory.

Storing Identity Data

If you store the identity details in a directory other than Oracle Internet Directory you can use Oracle Virtual Directory to present all the identity data in a single consolidated view that Oracle Identity Management components can interpret. For details, see Chapter 7.

Note:

Oracle Identity Manager uses Oracle Virtual Directory server or libOVD to access third-party directories.

1.2.2 The Enterprise Integration Topology

Unlike the single-node topologies described in this document, an enterprise integration topology takes into account such features as high availability, failover, and firewalls, and is beyond the scope of this document.

See the Enterprise Deployment Guide for Oracle Identity and Access Management, which explains the concepts of the enterprise integration topology and provides implementation procedures.

1.2.3 Using Multiple Directories for an Identity Store

Although the integration scenarios in this document focus on a simple identity store topology consisting of an Oracle Internet Directory LDAP server, your site may have some user data in a third-party directory, such as Microsoft Active Directory, and other user data in Oracle Internet Directory.

To account for this topology, you can use Oracle Virtual Directory to present all the identity data in a single consolidated view that Oracle Identity Management components can interpret.

For configuration details, see Chapter 7.

1.2.4 Integration Terminology

Table 1-1 shows key terms and acronyms that are used to describe the architecture and topology of an Oracle Fusion Middleware environment:

Table 1-1 Oracle Fusion Middleware Integration Terminology

Term Definition

IdM Configuration Tool

A command-line tool to verify the status of identity management components and to perform certain integration tasks.

Oracle Access Protocol (OAP)

A secure channel for communication between Webgates and Access Manager servers during authorization.

Oracle Fusion Middleware home

A Middleware home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes.

A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS.

Oracle HTTP Server (OHS)

Web server component for Oracle Fusion Middleware that provides a listener for Oracle WebLogic Server.

WebLogic Server home

A WebLogic Server home contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of other Oracle home directories underneath the Middleware home directory.

Oracle home

An Oracle home contains installed files necessary to host a specific product. For example, the Oracle Identity Management Oracle home contains a directory that contains binary and library files for Oracle Identity Management.

An Oracle home resides within the directory structure of the Middleware home. Each Oracle home can be associated with multiple Oracle instances or Oracle WebLogic Server domains.

Oracle instance

An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. The system components in an Oracle instance must reside on the same machine. An Oracle instance directory contains files that can be updated, such as configuration files, log files, and temporary files.

An Oracle instance is a peer of an Oracle WebLogic Server domain. Both contain specific configurations outside of their Oracle homes.

The directory structure of an Oracle instance is separate from the directory structure of the Oracle home. It can reside anywhere; it need not be within the Middleware home directory.

Oracle WebLogic Server domain

A WebLogic Server domain is a logically related group of Java components. A WebLogic Server domain includes a special WebLogic Server instance called the Administration Server, which is the central point from which you configure and manage all resources in the domain. Usually, you configure a domain to include additional WebLogic Server instances called Managed Servers. You deploy Java components, such as Web applications, EJBs, and Web services, and other resources to the Managed Servers and use the Administration Server for configuration and management purposes only.

Managed Servers in a WebLogic Server domain can be grouped together into a cluster.

An Oracle WebLogic Server domain is a peer of an Oracle instance. Both contain specific configurations outside of their Oracle homes.

The directory structure of an WebLogic Server domain is separate from the directory structure of the WebLogic Server home. It can reside anywhere; it need not be within the Middleware home directory.

system component

A system component is a manageable process that is not WebLogic Server. For example: Oracle HTTP Server, WebCache, and Oracle Internet Directory. Includes the JSE component.

Java component

A Java component is a peer of a system component, but is managed by the application server container. Generally refers to a collection of applications and resources, with generally a 1:1 relationship with a domain extension template. For example: SOA and WebCenter Spaces.

Oracle Fusion Middleware farm

Oracle Enterprise Manager Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer an Oracle Fusion Middleware farm.

An Oracle Fusion Middleware farm is a collection of components managed by Fusion Middleware Control. It can contain WebLogic Server domains, one or more Managed Servers and the Oracle Fusion Middleware system components that are installed, configured, and running in the domain.

Oracle Identity Management

The suite of identity and access management components in Oracle Fusion Middleware. See Section 1.3 for details.

WebLogic Administration Server

The Administration Server is the central point from which you configure and manage all resources in the WebLogic domain.

WebLogic Managed Server

The Managed Server is an additional WebLogic Server instance to host business applications, application components, Web services, and their associated resources. Multiple managed servers can operate within the domain. Certain Managed Servers in the domain are created specifically to host Oracle Fusion Middleware components.

1.3 About Oracle Identity Management Components

This section provides a brief overview of IdM components whose integrations are described in this book, and explains the benefits of integration. Topics include:

1.3.1 Oracle Unified Directory

Oracle Unified Directory is a comprehensive next generation directory service. It is designed to address large deployments and to provide high performance in a demanding environment.

The Oracle Unified Directory server is an LDAPv3-compliant directory server written entirely in Java. The directory server provides full LDAPv3 compliance, high performance and space effective data storage, and ease of configuration and administration.

Several procedures in this book feature Oracle Unified Directory as the repository for the identity store. For details, see Section 2.3, "Configuring the Identity Store".

1.3.2 Oracle Internet Directory

Oracle Internet Directory is a general purpose directory service that enables fast retrieval and centralized management of information about dispersed users and network resources. It combines Lightweight Directory Access Protocol (LDAP) Version 3 with the high performance, scalability, robustness, and availability of an Oracle Database.

Oracle Internet Directory can serve as the repository for the identity store, which contains user identities leveraged by identity management components and other applications.

For details about integration with Oracle Internet Directory, see:

1.3.3 Oracle Virtual Directory

Oracle Virtual Directory, an LDAP version 3 enabled service that provides virtualized abstraction of one or more enterprise data sources into a single directory view. Oracle Virtual Directory makes many directories appear to be one local repository, hiding the complexity of data location, format, and protocol from client applications.

For details about integration with Oracle Virtual Directory, see:

1.3.4 Oracle Access Management Access Manager

Oracle Access Management Access Manager provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration; auditing, and more. All existing access technologies in the Oracle Identity Management stack converge in Access Manager.

For details about integration with Access Manager, see:

1.3.4.1 A Note About IDMDomain Agents and Webgates

By default, the IDMDomain Agent is enabled in the Oracle HTTP Server deployment. If you migrate from IDMDomain Agent to WebGate Agent, note the following:

  • The protection policies set up for IDMDomain can be reused for WebGate if your webgate uses the IDMDomain preferredHost.

  • IDMDomain and WebGate can coexist. If the IDMDomain Agent discovers a WebGate Agent in the Oracle HTTP Server deployment, IDMDomain Agent becomes dormant.

See Also:

Configuring Centralized Logout for the IDM Domain Agent in the Administrator's Guide for Oracle Access Management.

1.3.5 Oracle Identity Manager

Oracle Identity Manager is a powerful and flexible enterprise identity management system that automatically manages users' access privileges within enterprise IT resources. Oracle Identity Manager is designed from the ground up to manage user access privileges across all of a firm's resources, throughout the entire identity management lifecycle—from initial creation of access privileges to dynamically adapting to changes in business requirements.

For details about integration with Oracle Identity Manager, see Chapter 3, "Integrating Access Manager, OAAM, and OIM".

1.3.6 Oracle Adaptive Access Manager

Oracle Adaptive Access Manager is Oracle Identity Management's solution for web access real-time fraud detection and multifactor online authentication security for the enterprise. It provides:

  • Real-time and batch risk analytics to combat fraud and misuse across multiple channels of access

  • An extensive set of capabilities including device fingerprinting, real-time behavioral profiling and risk analytics

  • Risk-based authentication methods including knowledge-based authentication (KBA) challenge infrastructure with Answer Logic and OTP Anywhere

See Also:

"Introduction to Oracle Adaptive Access Manager" in Administering Oracle Adaptive Access Manager.

For details about integration with Oracle Adaptive Access Manager, see:

Note:

Oracle Adaptive Access Manager integration with both OAM 10g and Access Manager 11g in coexistence mode and customizations such as single login page mode are beyond the scope of this document. For details, see Developer's Guide for Oracle Adaptive Access Manager.

1.3.7 Oracle Mobile Security Suite

Oracle Mobile Security Suite creates a secure enterprise workspace on mobile devices to isolate and protect corporate applications and data.

Oracle Mobile Security Suite and Access Manager are always installed together and integrated by default. It allows users to access corporate applications protected by Access Manager from the Mobile Workspace application while providing a unified administration console. Integration with Oracle Identity Manager enables you to allow mobile users, whose identities are governed by Oracle Identity Manager, to access corporate application with the single sign-on capabilities of Access Manager.

For details about integration with Oracle Mobile Security Suite, see Chapter 5.

1.3.8 Oracle Access Management Identity Federation

To enhance support for federated authentication in cloud, web services, and B2B transactions, a SAML-based federation service is being introduced in a single access management server in 11g Release 2 (11.1.2). Oracle Access Management Identity Federation is an enterprise-level, carrier-grade service for secure identity information exchange between partners. Identity Federation protects existing IT investments by integrating with a wide variety of data stores, user directories, authentication providers and applications.

In this initial release Identity Federation is limited to Service Provider mode. Identity Provider mode still requires an Oracle Identity Federation 11gR1 installation.

For details about using the Identity Federation service with Access Manager, see Chapter 6, "Integrating with Identity Federation".

1.4 IdM Integration Quick Links

Table 1-2 provides links to the integration procedures described in this document.

Table 1-2 Links to Integration Procedures in This Guide

Components to Integrate Link

Post-install LDAP Synchronization with Oracle Identity Manager

Appendix E

Oracle Virtual Directory and Oracle Identity Manager

Appendix E

Oracle Virtual Directory and Access Manager

Appendix F

Access Manager and Oracle Identity Manager

Chapter 2

Access Manager, Oracle Identity Manager, and Oracle Adaptive Access Manager

Chapter 3

Access Manager and Identity Federation

Chapter 6

Multi-Directory identity store

Chapter 7

Access Manager and Oracle Adaptive Access Manager

Appendix C

End-to-end SSL for IdM Components

Chapter 4

Integration Procedures in Other Documents

Table 1-3 lists key integration procedures that appear in other IdM documents:

Table 1-3 Links to Integration Procedures in Other Guides

Components to Integrate Link

Oracle Privileged Account Manager (OPAM) and Oracle Identity Manager (OIM)

"Integrating with Oracle Identity Manager" in Administering Oracle Privileged Account Manager.

OPAM and OAM

"Integrating with Oracle Access Management Access Manager" in Administering Oracle Privileged Account Manager.

OIM and Oracle Identity Analytics (OIA)

"Integrating with Identity Analytics" in Administering Oracle Identity Manager

1.5 Common Integration Scenarios

This section describes common scenarios to integrate Access Manager, Oracle Adaptive Access Manager, and Oracle Identity Manager and the resource protection and collection and password management benefits.

1.5.1 Resource Protection and Credential Collection Scenarios (OAAM Advanced Integration Using TAP)

This section describes the process flow when a user tries to access a protected resource in an Access Manager and OAAM Advanced integration using Trusted Authentication Protocol (OAAM Advanced using TAP). OAAM Advanced using TAP is the supported OAAM Advanced integration with Access Manager. This integration type provides authentication schemes, virtual authenticators, fraud rules, knowledge-based authentication, challenge processor and shared library frameworks, and additional advanced security access features, such as OTP Anywhere and Step Up Authentication.

Step Up Authentication allows a user who has been authenticated for a resource at a specific authentication level to access resources at a relatively higher authentication level. When the user accesses a resource protected with an authentication level that is greater than the level of his current token, OAAM runs policies to determine how to further authenticate the user so he can gain the required level of authentication needed for access to the protected resource.

Figure 1-3 illustrates the following scenarios for Step Up Authentication:

Figure 1-3 Resource Protection and Credential Collection Flow

OAAM-OAM flows

Initial steps that pertain to all three cases are listed as follows:

  1. A user tries to access a resource protected by Access Manager via TAPscheme configured with Oracle Adaptive Access Manager.

  2. The Oracle Access Management WebGate intercepts the unauthenticated request and forwards the request to the OAAM Server with the encrypted TAP token.

    Access Manager is forwarding the request to OAAM based on the challenge URL defined in the TAPScheme.

  3. The OAAM Server checks for the current authentication status of the user from the TAP token. The TAP token contains the current authentication level. Depending on the value of the current authentication level, Oracle Adaptive Access Manager can determine whether the user is authenticated or not. Accordingly, the user is taken through one of the flows described in this section.

For information on authentication flows, see "Authentication Flow" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

1.5.1.1 Case 1: The User is Authenticated by Access Manager with Oracle Adaptive Access Manager Performing Step Up Authentication

In this scenario, the user is already authenticated when he recently accessed another resource with a lower authentication level. When the user tries to access a resource protected by the TAPscheme, Oracle Adaptive Access Manager does not show the user name and password pages because the user is already authenticated. However, the following flows are executed in Oracle Adaptive Access Manager based on whether the user has registered or not in Oracle Adaptive Access Manager.

User has registered with Oracle Adaptive Access Manager

If the user is registered with Oracle Adaptive Access Manager, the process flow is as follows:

  1. Oracle Adaptive Access Manager fingerprints the PC, notebook, mobile phone, smart phone, or other web-enabled machine used by the user.

  2. Oracle Adaptive Access Manager runs the post-authentication rules, determines the risk score, and executes any actions or alerts that are specified in the policy.

  3. If the risk score is sufficiently high, Oracle Adaptive Access Manager presents the user with a second challenge (KBA or OTP). In the Challenge flow, he is challenged with his registered challenge questions or one-time password.

  4. If the Challenge flow is successful and the user has the appropriate profile registered, Oracle Adaptive Access Manager constructs the TAP token with the user name and sends it back to Access Manager. Access Manager asserts the token sent back. After asserting the token, Access Manager creates its cookie and continues the normal Single-Sign On flow in which it redirects the user to the protected resource.

User has not registered with Oracle Adaptive Access Manager

If the user has not registered with Oracle Adaptive Access Manager, the process flow is as follows:

  1. If the user is not registered, he may be asked to register a virtual device, personal image, phrase, and challenge questions, and one-time password, if OTP has been configured. Registration is required depending on security requirements, which specify whether the registration is mandatory or optional.

  2. Oracle Adaptive Access Manager fingerprints the PC, notebook, mobile phone, smart phone, or other web-enabled machine used by the user.

  3. Oracle Adaptive Access Manager runs the post-authentication rules, determines the risk score, and executes any actions or alerts that are specified in the policy.

  4. If the risk score is sufficiently high, Oracle Adaptive Access Manager blocks the user because it cannot challenge a user who does not have a registered profile (no KBA or OTP).

  5. If there is no risk, the user is taken through profile registration and after that, Oracle Adaptive Access Manager constructs the TAP token with the user name and sends it back to Access Manager. Access Manager asserts the token sent back. After asserting the token, Access Manager creates its cookie and continues the normal Single-Sign On flow in which it redirects the user to the protected resource.

1.5.1.2 Case 2: User is Not Authenticated by Access Manager

If the user is not authenticated, the process flow is as follows.

  1. The OAAM Server presents the user with the OAAM user name page.

  2. The user submits his user name on the OAAM user name page.

  3. Oracle Adaptive Access Manager fingerprints the PC, notebook, mobile phone, smart phone, or other web-enabled machine used by the user.

  4. Oracle Adaptive Access Manager runs pre-authentication rules to determine if the user should be allowed to proceed to the OAAM password page.

  5. If the user is allowed to proceed, the virtual authentication device rules are run to determine which virtual authenticator to display in the OAAM password page.

  6. If the user has registered with Oracle Adaptive Access Manager, the OAAM Server displays the OAAM password page with either the personalized TextPad or KeyPad. If the user has not registered, Oracle Adaptive Access Manager displays the OAAM password page with the Generic TextPad.

  7. The user submits his password on the OAAM password page and the credentials collected are verified against the identity store using the Oracle Access Management OAP API. After validation on the Access Manager side, Oracle Adaptive Access Manager runs the post-authentication rules.

  8. Based on rules/risk score, Oracle Adaptive Access Manager might allow the user to proceed, challenge the user, or block the user.

    • If the user is allowed to proceed, then Oracle Adaptive Access Manager evaluates the Registration checkpoint depending on security requirements. If the user is not registered, he may be asked to register virtual device, personal image, phrase, challenge questions, and OTP, if configured.

    • If the user is to be challenged because the risk was sufficiently high, Oracle Adaptive Access Manager evaluates the Challenge checkpoint to determine whether to block him or present him with another challenge (KBA or OTP). If Challenge Choice has been configured and the user has more than one OTP type registered, the user can choose.

    • If the user is blocked, he cannot continue.

  9. If authentication is successful and the user has the appropriate profile registered, Oracle Adaptive Access Manager constructs the TAP token with the user name and sends it back to Access Manager. Access Manager asserts the token sent back. After asserting the token, Access Manager creates its cookie and continues the normal Single-Sign On flow in which it redirects the user to the protected resource.

1.5.1.3 Case 3: User is Authenticated by Access Manager and Oracle Adaptive Access Manager Does Not Perform Step Up Authentication

If the user is already authenticated at a higher level than the level required to access the resource protected by TAPscheme, then the flow is not interrupted by Oracle Adaptive Access Manager and the user can directly access the protected resource.

1.5.2 Resource Protection and Credential Collection Scenario (OAAM Basic Integration)

This section describes the process flow when a user tries to access a protected resource in an Access Manager and OAAM Basic integration (OAAM Basic). This deployment provides login security and Knowledge Based Authentication (KBA). For details about OAAM Basic, see Section C.3, "OAAM Basic Integration with Access Manager."

The process flow is as follows:

  1. A user tries to access a resource protected by Access Manager.

  2. Oracle Access Management WebGate intercepts the request and forwards the request to the OAAM Server.

  3. Access Manager calls the OAAM APIs to run pre-authentication rules to determine if the user should be allowed to proceed. Based on the rule result such as Allow, Block, or Deny, Access Manager displays the appropriate pages.

  4. If the user is allowed to proceed, Access Manager displays the password page.

  5. The user submits his password and the credentials collected from Access Manager are verified against the identity store.

  6. Access Manager calls the OAAM APIs to run the post-authentication rules.

  7. Based on the results (Register User, Register Question, Challenge, Allow, or Block), Access Manager displays the appropriate set of pages.

    For example, if the result is Register User, as part of the user registration process (for first time login), the user is asked to select and answer three challenge questions.

    For example, if the result is Challenge, Access Manager displays a challenge question page with the security question displayed.

1.5.3 Password Management Scenarios

Common management scenarios supported by these deployment modes include:

1.5.3.1 Access Manager Integrated with Oracle Identity Manager

Figure 1-4 shows how password management is achieved when Access Manager and Oracle Identity Manager are integrated.

Figure 1-4 Integrating Access Manager and Oracle Identity Manager for Password Management

Integration flow OAM-OAAM-OIM

The flow of interactions between the components is as follows:

  1. A user tries to access a resource protected by Access Manager.

  2. The Oracle Access Management WebGate intercepts the (unauthenticated) request.

  3. WebGate redirects the user to the Access Manager login service, which performs validation checks.

  4. If Access Manager finds any password management trigger conditions, such as password expiry, it redirects users to Oracle Identity Manager.

  5. Oracle Identity Manager interacts with the user to establish the user's identity and carry out the appropriate action, such as resetting the password.

  6. Access Manager logs the user in by means of auto-login, and redirects the user to the Access Manager-protected resource which the user was trying to access in Step 1.

1.5.3.2 Self-Registration

In this scenario, the user does not have an account but tries to access an Access Manager-protected resource. An Oracle Access Management 11g WebGate intercepts the request, detects that the user is not authenticated, and redirects the user to the Oracle Access Management Credential Collector (or 10g authenticating WebGate), which shows the Access ManagerLogin page containing a Register New Account link.

On selecting this link, the user is securely redirected to the Oracle Identity Manager Self Registration URL. Oracle Identity Manager interacts with the user to provision his account.

Self-Registration Flow

The Welcome Page is an unprotected page from which the self-registration/account creation can be initiated. This page contains two links, in addition to any introductory text or branding information. The links are:

  • Register New Account - This is an unprotected URL to the corresponding application's registration wizard

  • Login - This is a protected URL which serves as the landing page to which the user is directed after successfully completing the login.

Note:

Any application protected by a single sign-on system with the self-registration requirement is expected to support a self-registration page. The options are:

  • Self-registration using the default self-registration page or a customized version of the page.

    This is the most common option and is covered here.

  • Self-registration using anonymous pages in other applications.

    If the application dictates that the user be automatically logged in at the end of the registration process, it can implement this by using the Oracle Platform Security Services APIs.

See Also:

Oracle Fusion Middleware Security Overview for more information about Oracle Platform Security Services.

The account creation flow is as follows:

  1. The user (using his browser) accesses the application's welcome page, which contains a Register New Account link.

  2. The user clicks the Register New Account link, which takes the user to a self-registration page provided by the application.

  3. The user interacts with the application to self-register.

  4. On completion, the application performs an auto-login for the user.

The protected application is expected to send an SPML request to Oracle Identity Manager to create the user. After this, the application could choose to do one of the following:

  • The application may choose not to auto-login the user. The application redirects the user to the protected landing page URL. Access Manager then shows the login page and takes the user through the login flow.

  • If there is no approval associated with the request, the application can make use of the Oracle Platform Security Services (OPSS) APIs to conduct an auto-login to the specific landing page URL and respond with a redirect request with that URL (along with the SSO cookie). This takes the user directly to the landing page without bringing up the login page.

  • Auto-login cannot be done if approval is needed. The application determines which profile to use at the time of SPML request. The application needs to respond with an appropriate page indicating that the request has been submitted.

1.5.3.3 Password Change

The Change Password flow enables users to change their password.

Password Change Flow with Access Manager and Oracle Identity Manager

In this situation, the user successfully logs into Access Manager but is required to immediately change the password. The user is not authorized to access protected resources until the password is changed and challenges have been set up.

On successful login, Access Manager detects if the triggering condition is in effect and redirects the user to the Oracle Identity Manager Change Password URL. Oracle Identity Manager facilitates the user password change or challenge set-up and resets the triggering condition.

On completion, Oracle Identity Manager redirects the user to the protected resource.

This situation is triggered in the following cases:

  • The Change Password upon Login flag is on. This occurs:

    • when a new user is created

    • when the administrator resets a user's password

  • The password has expired.

This flow describes the situation where a user logs in to an Access Manager-protected application for the first time, and is required to change password before proceeding.

The following describes the Change Password flow:

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager.

  2. Oracle Access Management WebGate (SSO Agent) intercepts the request and redirects the user to the Access Manager Login Page.

  3. The user submits credentials, which are validated by Access Manager.

  4. Access Manager next determines if any of the First Login trigger conditions are valid. If so, Access Manager redirects the user to the Oracle Identity Manager Change Password URL.

  5. Oracle Access Management WebGate (SSO Agent) intercepts the request, determines that Oracle Identity Manager is protected by the Anonymous Authentication Policy, and allows the user request to proceed.

  6. Oracle Identity Manager interacts with the user to enable the user to change his password. On completion, Oracle Identity Manager updates the attributes that triggered the First Login flow. Oracle Identity Manager then performs a user auto-login.

  7. Oracle Identity Manager notifies Access Manager of the successful first login.

  8. Oracle Identity Manager redirects the user to the application URL the user tried to access in step 1.

1.5.3.4 Forgot Password

The Forgot Password flow allows users to reset their password after successfully answering all challenge questions.

Forgot Password Flow for Access Manager/Oracle Identity Manager Integration

In this scenario, the user is at the Access Manager Login page and clicks the Forgot Password link. Access Manager redirects the user to the Oracle Identity Manager Forgot Password URL, and passes the destination URL to which Oracle Identity Manager must redirect upon a successful password change as a query parameter (backURL).

Oracle Identity Manager asks the user the challenge questions. Upon providing the correct responses, the user is allowed to specify a new password.

On completion, Oracle Identity Manager redirects the user to the protected resource.

The Forgot Password flow is as follows:

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager.

  2. The Oracle Access Management WebGate (SSO Agent) intercepts the request and redirects the user to the Access Manager Login Page.

  3. The user clicks on the Forgot Password link on the Access Manager Login page, which sends the user to the Oracle Identity Manager Forgot Password URL.

  4. Oracle Identity Manager interacts with the user to enable the user to reset the password. On completion, Oracle Identity Manager performs a user auto-login.

  5. Oracle Identity Manager redirects the user to the application URL to which access was attempted in step 1.

Forgot Password Flow for Access Manager/Oracle Identity Manager/Oracle Adaptive Access Manager Integration

With Oracle Adaptive Access Manager and Oracle Identity Manager integration, the Forgot Password feature is made available as a link from the OAAM password page. The flow starts when the user is at the OAAM password page and clicks the Forgot your password link.

The process flow is as follows:

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager via an authentication scheme.

  2. The Oracle Access Management WebGate (SSO Agent) intercepts the request and forwards the request to the OAAM Server for login.

  3. OAAM Server presents the user with the OAAM user name page where the user submits his user name.

  4. Oracle Adaptive Access Manager fingerprints the user device (a desktop computer, laptop computer, PDA, cell phone, kiosk, or other web enabled device) and runs the pre-authentication rules to check if the user is a member of a blacklisted country, device, IP, ISP, or users group or if he is using WEBZIP. If he is in a blacklisted group or using WEBZIP, he is blocked and cannot proceed.

  5. If the user is allowed to proceed, virtual authentication device rules are run to determine which virtual authentication device to display on the password page.

  6. OAAM Server displays the OAAM password page with the virtual authentication device.

  7. The user clicks the Forgot your password link on the OAAM password page.

    Note:

    The Forgot your password link is not available to unregistered users logging in for the first time. They will have to reset their password on the first logon.

  8. OAAM Server runs the Forgot Password checkpoint.

  9. Oracle Adaptive Access Manager presents the user with a challenge page.

    • If the user is unregistered, the user is blocked and cannot access the protected resource.

    • If the user is registered, he is challenged by OTP or KBA depending on the deployment. If challenge choice has been configured and the user has more than one OTP challenge type registered, he is given a choice of which OTP challenge type he wants OAAM to challenge him.

  10. If the challenge is successful, Oracle Adaptive Access Manager makes calls to Oracle Identity Manager for the Password Policy text.

  11. The user is redirected to the Password Reset page where the Password Policy text is shown.

  12. The user enters the new password and confirms the new password by entering it again.

  13. Oracle Adaptive Access Manager collects the user name and password and sends OAP API calls to Access Manager.

  14. Access Manager makes LDAP calls to the identity store configured with Access Manager to validate credentials.

  15. Oracle Adaptive Access Manager calls Oracle Identity Manager to update the repository with the new password.

  16. After authentication, Oracle Adaptive Access Manager evaluates Post-Authentication checkpoint policies. Based on the outcome of the policy Oracle Adaptive Access Manager might challenge the user, check the registration of the user, or block the user.

    • If the outcome of Post-Authentication is Allow then Oracle Adaptive Access Manager evaluates the Registration checkpoint to determine which pieces of user information is pending registration. Based on the types of registration it takes the user through the Registration flow.

    • If there is enough risk involved, the outcome of Post-Authentication may be Challenge. Oracle Adaptive Access Manager evaluates the Challenge checkpoint to determine if the user should be blocked or challenged with one of the registered challenge mechanism (KBA or OTP depending on the configuration) by taking the user through the Challenge flow.

    • If the outcome of Post-Authentication is Block then the user would be blocked and he will not be able to access the protected resource.

  17. Oracle Adaptive Access Manager interacts with the user during the required flows and if the user is successful, Access Manager sets the OAM cookie, the user is logged in, and a single sign-on session is created.

1.5.3.5 Account Lock and Unlock

Access Manager keeps track of login attempts and locks the account when the count exceeds the established limit.

When an account is locked, Access Manager displays the Help Desk contact information and Forgot Password link, or similar.

If contacted by the end user, the Help Desk unlocks the account using the Oracle Identity Manager administrative console. Oracle Identity Manager then notifies Access Manager about the changes. If the end user decides to use the Forgot Password link instead of contacting the Help Desk, Oracle Identity Manager interacts with the user. Upon completion, the user is allowed to reset the password.

Account Lock and Unlock Flow

When the number of unsuccessful user login attempts exceeds the value specified in the password policy, the user account is locked. Any login attempt after the user account has been locked displays a page that provides information about the account unlocking process, which will need to be customized to reflect the process (Help Desk information and Forgot Password link, or similar) that is followed by your organization.

The following describes the account locking/unlocking flow:

  1. Using a browser, a user tries to access an application URL that is protected by Access Manager.

  2. Oracle Access Management WebGate (SSO Agent) intercepts the request and redirects the user to the Access Manager login page.

  3. The user submits credentials that fail Access Manager validation. Access Manager renders the login page and asks the user to resubmit his or her credentials.

  4. The user's unsuccessful login attempts exceed the limit specified by the policy. Access Manager locks the user account and redirects the user to the Access Manager Account Lockout URL. The resulting page displays the Help Desk contact information and Forgot Password link.

  5. If the user contacts the Help Desk over the telephone and asks an administrator to unlock the account, then:

    1. Oracle Identity Manager notifies Access Manager of the account unlock event.

    2. The user attempts to access an application URL and this event triggers the normal Oracle Access Management single sign-on flow.

  6. If the user clicks the Forgot Password link, the user is sent to the Oracle Identity Manager Forgot Password URL, then:

    1. Oracle Identity Manager interacts with the user to enable the user to reset the password. On completion, Oracle Identity Manager performs a user auto-login.

    2. Oracle Identity Manager redirects the user to the application URL.

    Note:

    The user would be able to self-unlock the account by going through the Oracle Identity Manager Forgot Password flow, only once the user status is locked in Oracle Identity Manager. The user locked status is synchronized from the LDAP provider to Oracle Identity Manager only when the "LDAP User Create and Update Reconciliation" scheduled job is run.

1.5.3.6 Challenge Setup

The Challenge Setup enables users to register challenge questions and answers.

Challenge Setup Flow for Access Manager-Oracle Identity Manager Integration

Access Manager detects and redirects on password trigger conditions:

  • Password Policy is updated to increase the required number of challenges.

  • Password Policy is updated to require challenges .

When such redirection happens, Oracle Identity Manager checks if the challenge questions are set. If not, it asks the user to set up challenge questions in addition to resetting the password.

The following describes the flow:

Note:

The flow assumes First Login is not required.

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager.

  2. Oracle Access Management WebGate (SSO agent) intercepts the request and redirects the user to the Access Manager Login Page.

  3. The user submits credentials, which are validated by Access Manager. If a password triggering condition is detected, Access Manager redirects the user to the Oracle Identity Manager change password URL.

  4. The Oracle Access Management WebGate (SSO agent) intercepts the request, determines that Oracle Identity Manager is protected by the anonymous authentication policy, and allows the user request to proceed.

  5. Oracle Identity Manager interacts with the user to set up the challenges. On completion, Oracle Identity Manager updates the attributes that triggered the set challenges flow.

  6. Oracle Identity Manager redirects the user to the application URL that the user attempted to access in Step 1.

Challenge Setup Flow for Access Manager-Oracle Identity Manager-Oracle Adaptive Access Manager Integration

In this scenario, the user is successfully authenticated but is required to register challenge questions. The user is not authorized to access protected resources until the challenges questions have been registered.

Note:

When adding Oracle Adaptive Access Manager to existing Oracle Identity Manager deployments, you will need to forego all the existing questions and answers that are registered in Oracle Identity Manager. Instead, users are asked to register the challenge questions again in Oracle Adaptive Access Manager on the next login.

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager.

  2. Oracle Access Management WebGate intercepts the (unauthenticated) request.

  3. Oracle Access Management WebGate redirects the user to the OAAM Server and passes a redirect URL.

  4. Oracle Adaptive Access Manager presents the user with the OAAM user name page.

  5. The user submits his user name on the OAAM user name page.

  6. Oracle Adaptive Access Manager fingerprints the user device (a desktop computer, laptop computer, PDA, cell phone, kiosk, or other web enabled device) and runs pre-authentication rules to determine if the user should be allowed to proceed to the OAAM password page.

  7. If the user is allowed to proceed, the OAAM Server displays the OAAM password page with the strong authenticator specified by the virtual authentication device rules.

  8. The user submits his password on the OAAM password page.

  9. During authentication, Oracle Adaptive Access Manager calls Access Manager to validate the credentials.

  10. After authentication, Oracle Adaptive Access Manager checks if the user has registered challenge questions.

  11. If the user has not registered for challenges, Oracle Adaptive Access Manager interacts with the user to set up the challenges (select challenge questions and register answers and/or set up an OTP profile).

  12. If the registration is successful Oracle Adaptive Access Manager redirects the user to the Access Manager protected resource.

1.5.3.7 Challenge Reset

Challenge Reset enables users to reset their challenge registration.

The flow is as follows:

  1. Using a browser, the user tries to access an application URL that is protected by Access Manager.

  2. Oracle Access Management WebGate intercepts the (unauthenticated) request.

  3. Oracle Access Management WebGate redirects the user to the OAAM Server and passes a redirect URL.

  4. The OAAM Server presents the user with the OAAM user name page.

  5. The user submits his user name on the OAAM user name page.

  6. Oracle Adaptive Access Manager fingerprints the user device (a desktop computer, laptop computer, PDA, cell phone, kiosk, or other web enabled device) and runs pre-authentication rules to determine if the user should be allowed to proceed to the OAAM password page.

  7. If the user is allowed to proceed, the OAAM Server displays the OAAM password page with the strong authenticator specified by the virtual authentication device rules.

  8. The user submits his password on the OAAM password page.

  9. During authentication, Oracle Adaptive Access Manager calls Access Manager to validate the credentials.

  10. If authentication is successful and the user has questions registered, but he wants to reset his challenge questions, the user clicks the Reset Challenge link.

    Note:

    The integrator would need to have added a link to the protected application that would take users to the OAAM User Preference pages (or in some cases, directly to the OAAM Question Reset page). Adding the link allows users to manage their OAAM registration.

  11. The user is redirected to Oracle Adaptive Access Manager User Preferences/Question Registration page where he can reset challenge questions.

1.5.4 Manage Mobile Security Accounts and Applications Using Identity Self-Service

The Manage Mobile Security Account flow enables users to manage their mobile security accounts and applications. The flow between Oracle Mobile Security Suite and Oracle Mobile Security Suite-integrated components is as follows:

  1. The user enrolls his mobile devices in Oracle Mobile Security Suite.

  2. Oracle Mobile Security Suite provisions applications to the users based on his roles.

  3. The user logs in to the Oracle Identity Manager Self Service Console to:

    • view his devices

    • perform operations, such as lock, wipe, or reset passcode for his device or workspace

  4. The Oracle Mobile Security Suite taskflows embedded in the Oracle Identity Manager Console invokes Oracle Mobile Security Suite to obtain information on the devices and perform operations on them.

1.6 System Requirements and Certification

Refer to the system compatibility, requirements and certification documentation for information about hardware and software requirements, platforms, databases, and other information.

The compatibility documentation describes compatibility and interoperability considerations that may arise when you install, patch, or upgrade Oracle Fusion Middleware 11g components. For details, see Interoperability and Compatibility Guide for Oracle Identity and Access Management.

The system requirements document covers information such as hardware and software requirements, minimum disk space and memory requirements, and required system libraries, packages, or patches.

The certification document covers supported installation types, platforms, operating systems, databases, JDKs, directory servers, and third-party products.

For the latest requirements and certification documentation refer to the table "Oracle Fusion Middleware Certification Matrices" in the Interoperability and Compatibility Guide for Oracle Identity and Access Management.

1.7 Using My Oracle Support for Additional Troubleshooting Information

You can use My Oracle Support (formerly MetaLink) to help resolve Oracle Fusion Middleware problems. My Oracle Support contains several useful troubleshooting resources, such as:

  • Knowledge base articles

  • Community forums and discussions

  • Patches and upgrades

  • Certification information

Note:

You can also use My Oracle Support to log a service request.

You can access My Oracle Support at https://support.oracle.com.