2 Product Architecture

The architecture of Oracle Identity Manager provides a number of compelling technical benefits for deploying a provisioning solution as part of identity and access management. Oracle Identity Manager has a flexible architecture that can handle IT and business requirements without requiring changes to existing infrastructure, policies, or procedures.

Oracle Identity Manager architecture is described in the following sections:

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

Oracle Identity Manager is based on the n-tier J2EE application architecture. Oracle Identity Manager architecture contains the following tiers:

Figure 2-1 illustrates Oracle Identity Manager architecture.

Figure 2-1 Oracle Identity Manager Architecture

Description of Figure 2-1 follows
Description of "Figure 2-1 Oracle Identity Manager Architecture"

2.1.1 Presentation Tier

The Presentation tier consists of three clients: Oracle Identity Self Service, Oracle Identity System Administration, and Oracle Identity Manager Design Console.

Oracle Identity Self Service is a Web-based thin client that can be accessed from any Web browser. This Web client provides user self-service and delegated administration features in a single interface that serve most of the users of Oracle Identity Manager.

Oracle Identity System Administration is a Web-based thin client that provides administrative and system management functions.

Oracle Identity Manager Design Console provides system configuration and development capabilities, including form, workflow design, and adapter creation and management. The Design Console is implemented as a Java Swing client that communicates directly with the Business Services layer in the application. You can access Oracle Identity Manager Design Console by using a desktop Java client.

Oracle Identity manager interfaces support a highly sophisticated delegated administration model, guaranteeing that users can only work on those parts of the application configuration for which they are authorized.

In many enterprises, there is a requirement for the provisioning system to support a custom developed client. Some of the requirements that drive this are:

  • Integration of the client into an existing enterprise portal and adherence to enterprise portal standards

  • Creation of custom flows for user interaction

  • Creation of custom pages built around unique requirements from the provisioning system

To support customization, Oracle Identity Manager exposes the bulk of the necessary functionality via its published public APIs. The client environment for Oracle Identity Manager is customizable via Java APIs.

2.1.2 Business Services Tier

The Business Services Tier is implemented as an Enterprise JavaBeans (EJB) application. The core functionality for Oracle Identity Manager platform is implemented in Java using a highly modular, object-oriented methodology. This makes Oracle Identity Manager flexible and extensible. The Business Services Tier for Oracle Identity Manager includes the following services and capabilities:

  • The Core Services that comprise the core of the business features offered by Oracle Identity Manager, such as the User Management Service, the Policy Management Services, and the Provisioning and Reconciliation Services.

  • The API Services that describe the APIs supported by Oracle Identity Manager that allow custom clients to integrate with Oracle Identity Manager. This includes a rich set of APIs that expose the business functionality of Oracle Identity Manager for use by custom clients, in product customization, and in plug-in and adapter development.

  • The Integration Services based on the Adapter Factory and Connector Framework, which dynamically generates integration code based on the metadata definition of the adapters.

  • The Platform Services that are crucial to the business features offered by Oracle Identity Manager, such as the Request Management Service, the Entity Manager Service, and the Scheduler Service.

The Business Services Tier is described in the following sections:

2.1.2.1 The API Services

The API Services describe the APIs supported by Oracle Identity Manager that allow custom clients to integrate with Oracle Identity Manager. This includes a rich set of APIs that expose the business functionality of Oracle Identity Manager for use by custom clients, in product customization, and in plug-in and adapter development.

The API Services consist of:

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

    • Adding, modifying, and deleting identities

    • Adding, modifying, and deleting roles

    • Adding and deleting role memberships

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

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

2.1.2.2 Integration Services

A scalable and flexible integration architecture is critical for the successful deployment of provisioning solutions. Oracle Identity Manager offers an integration architecture for fast and low-cost deployments.

Oracle Identity Manager integration services provide all the components required to support the development, deployment, and maintenance of connectors. The integration services includes:

2.1.2.2.1 Connector Framework

Oracle Identity Manager connectors are packaged solutions that are used to integrate with target applications for the purposes of managing identities in those applications. Examples of such target applications are Microsoft Active Directory or Oracle E-Business Suite. A connector can be predefined by Oracle for particular target systems or can be custom developed.

Because a predefined connector is designed specifically for the target application, it offers the quickest integration method. These connectors support popular business applications such as Oracle eBusiness Suite, PeopleSoft, Siebel, JD Edward and SAP, as well as technology applications such as Active Directory, Java Directory Server, UNIX, databases, and RSA ClearTrust. Predefined connectors offer the quickest integration alternative because they are designed specifically for the target application. They use integration technologies recommended by target and are preconfigured with application specific attributes.

If predefined connectors does not use integration technologies recommended by target, then a custom connector can be developed. The Adapter Factory tool in Oracle Identity Manager Design Console provides a definitional user interface that facilitates such custom development efforts without coding or scripting.

A connector contains:

  • Multiple connector-specific Oracle Identity Manager entities such as resource objects, data forms, provisioning workflows, and adapters

  • Target-specific Java libraries that provide the underlying functions such as connectivity, authentication and user account management

  • Event triggers that wire provisioning operations to both identity profile changes and policy operations

The connector framework combines all of these components together into a functional connector that is run at appropriate times, either manually based on user interaction or based on system triggering. It defines the various operational triggers, policy triggers, and hooks that allow the connector operation to be tailored to specific requirements.

2.1.2.2.2 Identity Connectors

Connectors are deployed with Oracle Identity Manager, which affects the portability of the connectors across various Oracle Identity Manager releases. The Identity Connector Framework (ICF) decouples the connectors from Oracle Identity Manager. As a result, connectors can be used with any product. Identity connectors are designed to separate the implementation of an application from the dependencies of the system that the application is attempting to connect to.

Identity connectors have the following components:

  • The identity connector framework: Provides a container that separates the connector bundle from the application. The framework provides many common features that developers would otherwise need to implement on their own. For example, the framework can provide connection pooling, buffering, timeouts, and filtering. The identity connector framework is separated into two parts:

    • The API: Applications use the API to call connectors

    • The SPI: Developers can create connectors by implementing the SPI

  • Identity connector bundle: The specific implementation for a given resource target

  • The connector server (optional): Allows an application to remotely run one or more connector bundles that are deployed on another system. Connector servers are available in both Java™ and .NET. The .NET connector server is needed only if you are using .NET connector bundles, whereas the Java connector server is available for connector bundles written in Java.

Figure 2-2 shows the ICF architecture:

Figure 2-2 ICF Architecture

Description of Figure 2-2 follows
Description of "Figure 2-2 ICF Architecture"

Connector SPI

Connector SPI interfaces represent operations supported on a connector. A connector developer can choose to implement one or more operation interfaces for framing target system calls. Extension on existing interfaces or creating new interfaces is not supported. The SPI is broken up into required interfaces, feature-based interfaces, and operation interfaces such as create, update, delete, and search.

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

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

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

Connector API

The connector API is responsible for presenting a consistent view of a connector regardless of the operations it has implemented. For the convenience of the SPI developer, there are several common features that are provided by default. For most of these features there is no need for the application developer to handle the APIs, only configure them. Following is a list of API features:

  • Provide connection pooling to those connectors that require it and avoid the need for the API to see it, because not all connectors have connections. In addition, if the connector uses connection pooling, it is not the responsibility of the API developer to handle the connections, nor dispose of them during error conditions.

  • Provide timeouts to all operations. The API consumer should only configure the appropriate timeout if the default is unacceptable. Each SPI developer should not have to implement such a common service and, for this reason, it is implemented in the framework.

  • Provide search filtering by way of a simple interface that accepts a large variety of filters. The connector developer only needs to implement whichever filters the resource natively supports. The rest is handled by the framework.

  • Provide search/sync buffering, allowing queries and updates to be handled in chunks if need be. The application need not worry about this, as it is handled within the framework.

  • Provide scripting via Groovy and Boo .NET for connectors. This allows for great flexibility within a connector, because the framework can run scripts both on the connector and on the target resource (if supported).

  • The SPI developer has the ability to choose different implementations of an operation. For instance there are two types of updates. This is hidden from the API consumer because there is no need for the application developer to call two different operations that essentially do the same thing. Instead the framework will figure out which operation the connector supports and make the appropriate calls.

2.1.2.2.3 Adapter Factory

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

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

An adapter provides the following benefits:

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

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

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

  • It can be generated without manually writing code.

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

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

  • It can be modified and upgraded.

The Adapter Factory provides rapid integration with commercial or custom systems. Users can create or modify integrations by using the graphical user interface of the Adapter Factory, without programming or scripting. When connectors are created, Oracle Identity Manager repository maintains the definitions and creates self-documenting views. You use these views to extend, maintain, and upgrade connectors.

2.1.2.2.4 Generic Technology Connector

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

To integrate Oracle Identity Manager with a target system that has no corresponding predefined connector, you can create a custom connector to link the target system and Oracle Identity Manager. If you do not need the customization features of the Adapter Factory, then you can create the connector by using the Generic Technology Connector (GTC) feature of Oracle Identity Manager.

You can quickly and easily build a basic connector without advanced features and customized behavior by using generic connectivity technologies such as SPML and JDBC. GTC is a wizard that provides an alternative environment for connector development to rapidly create all the necessary functional components that make up a target system connector in Oracle Identity Manager.

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

  • Reconciliation:

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

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

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

  • Provisioning:

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

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

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

Figure 2-3 Functional Architecture of a Generic Technology Connector

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

Generic technology connectors have the following features:

  • Features specific to the reconciliation module are:

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

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

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

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

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

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

  • Other features of generic technology connectors are:

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

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

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

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

2.1.2.2.5 Remote Manager

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

  • Invoking nonremotable APIs through Oracle Identity Manager

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

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

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

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

Figure 2-4 Remote Manager Architecture

Description of Figure 2-4 follows
Description of "Figure 2-4 Remote Manager Architecture"

See Also:

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

2.1.2.3 Platform Services

The Platform Services include:

2.1.2.3.1 Plug-In Framework

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

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

2.1.2.3.2 SoD Engine Framework

An attempt to enforce good compliance practices is through the definition of Segregation of Duties (SoD) policies. SoD is broadly defined as a way of preventing a user from acquiring a conflicting set of entitlements. This conflicting set is also referred to as a toxic combination. An example of a toxic combination is that a person should not have the ability to create and approve the same purchase order. Enterprises often have business application-specific SoD engines that define and enforce SoD policies on the entitlements users have within those business applications. Examples of such SoD engines are OAACG and SAP GRC.

The SoD Engine Framework allows customers to integrate Oracle Identity Manager with their choice of SoD Engine to enable SoD checks at appropriate points in the request and provisioning process. Oracle Identity Manager can send a request for an SoD check to the SoD Engine through the SoD Invocation Library (SIL). SIL provides a common service interface to all supported SoD engines. The common service interface provides an abstraction on the business components within Oracle Identity Manager. As a result, SoD checks do not have to take care of the correct data formats required by the SoD Engine and also the interpretation of the results returned.

SoD checks can be run at various times in the provisioning lifecycle, such as during an access request, during the approval workflow execution, or during the provisioning execution. If a violation is detected, then the request or resource is marked as being in violation, and the approver or administrator is responsible for deciding whether to proceed or not. If violations are detected during request processing, then various approval workflows can be invoked that allow for higher levels of approval.

Figure 2-5 shows the flow of data during the SoD validation process.

Figure 2-5 SoD Validation Process in Oracle Identity Manager

Description of Figure 2-5 follows
Description of "Figure 2-5 SoD Validation Process in Oracle Identity Manager"

See Also:

Chapter 22, "Using Segregation of Duties (SoD)" for detailed information about SoD

2.1.3 Middleware Tier

The Middleware Tier in Oracle Identity Manager architecture consists of the following:

2.1.3.1 Request Service and Approval Workflow

Oracle Identity Manager architecture includes a request service that allows you to configure approval workflows. To deliver this functionality, Oracle Identity Manager uses Oracle Service Oriented Architecture (SOA) Suite.

Oracle SOA Suite enables you to build service-oriented applications and deploy them to your choice of middleware platform. It consists of a number of components, but for the purposes of delivering comprehensive workflow capabilities, Oracle Identity Manager relies on the following components:

  • BPEL Process Manager: Oracle BPEL Process Manager provides a comprehensive solution for creating, deploying, and managing cross-application business processes with both automated and human workflow steps. It also provides audit trails for both completed and running processes, and process history that enables process improvement.

  • Human Request Service: Although the BPEL standard does not cover manual tasks, it supports asynchronous services. Therefore, the Oracle SOA Suite supports the Human Request Service, which is a manual task service, so that manual steps can be included in standard BPEL processes. Oracle Identity Self Service includes a task list that allows users to view and interact with assigned tasks being managed within the Human Request Service.

  • BPEL Designer: The Oracle BPEL Designer is available as a plug-in for JDeveloper and offers a visual design paradigm for creating and deploying BPEL-based processes.

Oracle Identity Manager embeds SOA task list in the UI. This optimizes and simplifies the interaction of users with the SOA suite. The approvers can approve requests originating in Oracle Identity Manager by using the embedded SOA task list.

Embedded SOA task lists in Oracle Identity Manager enable making relevant data about the Oracle Identity Manager entities available to the SOA instance as Oracle Business Rules (OBR) facts on top of the default Web services. Therefore, writing complex JAVA code to resolve approver and approval routing in SOA workflows can be avoided. The following data is available in the SOA composites as OBR facts:

  • User attribute for requestor and beneficiary

  • All metadata associated with the base entity of requested item

  • All metadata associated with the catalog entry of the requested item

Figure 2-6 shows the integration between the request service and SOA.

Figure 2-6 Request Service and SOA Integration

Description of Figure 2-6 follows
Description of "Figure 2-6 Request Service and SOA Integration"

The request service also provides the services used to raise and track requests in Oracle Identity Manager. A request allows a user to ask that an action be taken after obtaining the necessary approvals, and that a tracking record of the entire process and its status be maintained. The request can be for various types of actions that are defined as request types. The request types can be:

  • Creating, modifying, or deleting an entity

  • Enabling or disabling an entity

  • Adding or removing an identity as a member of a role

  • Granting and revoking entitlements

  • Provisioning, deprovisioning, enabling, disabling, and modifying application instances

Note:

Application instance is a new entity introduced in Oracle Identity Manager 11g Release 2 (11.1.2.1.0). For information about application instances, see "Managing Application Instances" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

The request service supports various types of requests and has the ability to accommodate multiple request types. Oracle Identity Manager provides a number of predefined request types that cover the most common use cases.

The request service also provides support for heterogeneous requests that enable requesting for multiple types of entities in the same request. For example, assigning roles, provisioning application instances, and granting entitlements are supported in a single request.

The request service defines the flow models by which data provided in a request flows through the various services in Oracle Identity Manager. This includes invoking approval workflows at the correct time, monitoring the status of the workflows, and running the request if approval is received.

Both transaction data and history data for requests is maintained, which supports audit and compliance requirements.

2.1.3.2 Authorization Service

Oracle Identity Manager requires a strong level of access control over what users can view and change in the application. To meet this requirement, Oracle Identity Manager lets you define authorization policies that determine at run time whether or not a particular action is allowed. This is controlled by the authorization service that uses Oracle Entitlements Server (OES) embedded within Oracle Identity Manager. OES is an authorization product and enables centralized management of entitlements and authorization policies to granularly determine access to both application components and application business objects.

The OES architecture is made up of two major components. The administration application acts as the policy administration point (PAP) and is used to manage policy, configuration, roles, and entitlements. The second major component is the use of one or more Security Modules (SMs) that are stored in the application container. The SMs evaluate fine-grain access control polices at the policy decision point (PDP) and enforce it at the policy enforcement point (PEP).

Figure 2-7 shows the architecture of OES-based authorization service:

Figure 2-7 OES-Based Authorization Service

Description of Figure 2-7 follows
Description of "Figure 2-7 OES-Based Authorization Service"

Each time a privilege check is requested, the following takes place:

  • Oracle Identity Manager connects to the authorization service to prepare access decision for the operations performed on protected entities.

  • The service then finds and evaluates the policy or policies that apply to the resource.

  • All information required to evaluate a policy is collected by the Security Modules at run time.

  • If the policy references subject by role, all roles are evaluated and the access decision is made.

Oracle Identity Manager provides an abstraction service on top of OES that optimizes and simplifies the definition of policies in Oracle Identity Manager. This service includes a policy definition UI that allows the definition of authorization policies that are feature specific and support fine-grained controls for attributes and functions on entities such as users and roles.

2.1.3.3 UI Customization Framework

Oracle Identity Manager leverages Application Development Framework (ADF) to provide simple and business-friendly UI customization without the need to write code. The components used for customization are:

  • Oracle Web Composer: Oracle Identity Manager supports Web browser-based UI customization and not IDE or JDeveloper-based customizations. JDeveloper is used to create pages, page fragments, regions, tabs and other UI artifacts. After these artifacts are deployed in Oracle Identity Manager, additional customizations can be done on this new content by using Oracle Web Composer.

    Note:

    If you want to use JDeveloper, then you can use APIs and build pages from scratch rather than customize predefined pages. There will be no interoperability between IDE and Web browser- based UI customizations.

    Oracle Web Composer enables you perform browser-based run-time customization or personalization of pages, Changing page layouts, adding items to pages, and performing branding. Customizations can be temporarily saved, reviewed, and then finalized as deployment specific, tenant specific, or user specific. This provides durable customizations across patches and upgrade because UI customizations are preserved separately from the code and UI metadata.

  • ADF Business Editor: Using the ADF Business Editor, you can extend or add custom attributes to user, role, organization, catalog, and application instance entities. In addition, you can configure request datasets for users, resource objects, and application instances.

  • Meta Data Store (MDS): Customizations and personalizations are stored in file system or database by using Oracle MDS.

Figure 2-8 illustrates the components of the UI customization framework.

Figure 2-8 UI Customization Framework

Description of Figure 2-8 follows
Description of "Figure 2-8 UI Customization Framework"

2.1.3.4 Scheduler Service

Business systems frequently make use of scheduling systems, which are configured to run other programs at specified times. Scheduling systems run applications that generate reports, reformat data, or perform audits at regular intervals of time. Scheduling systems often run batch jobs or scheduled jobs that perform routine work automatically at a prescribed time.Scheduling systems are an integral part of any enterprise provisioning solution. Provisioning often involves tasks to be performed in a time-based manner. Some examples are:

  • Running a nightly job to reconcile all changes made directly on a managed application

  • Do escalations of assigned tasks that have not been handled within a specified time period

  • Execute requests at a specific time

Oracle Identity Manager platform includes the Scheduler to provide the scheduling capabilities necessary for enterprise provisioning requirements. This Service is managed as part of Oracle Identity Manager platform and not as an independent product. Figure 2-9 provides an overview of Oracle Identity Manager Scheduler architecture.

Figure 2-9 Oracle Identity Manager Scheduler Architecture

Description of Figure 2-9 follows
Description of "Figure 2-9 Oracle Identity Manager Scheduler Architecture"

Key capabilities provided by the Scheduler service are:

  • The ability to create simple or complex schedules for running thousands of jobs

  • The ability to run the scheduling service as a clustered service to provide the necessary high availability capabilities including fail-over and load balancing

  • The ability to persist the job definitions for management and fail-over support

  • The ability to create, modify, enable, disable, and delete jobs and manage individual job runs by using an administrative UI

  • The ability to run a job in an ad-hoc fashion outside of regularly scheduled runs

  • The ability to manage errors and failures

  • The ability to maintain history of job runs, including statistics and results of these runs

  • The ability to manage the Scheduler service itself

2.1.3.5 Reporting

The rich set of data stored in Oracle Identity Manager repository can be viewed through detailed reports that support management and compliance requirements. Oracle Identity Manager provides support for data reporting through the use of Oracle BI Publisher, which is an enterprise reporting solution and provides a single reporting environment to author, manage, and deliver all of your reports and business documents. Utilizing a set of familiar desktop tools, such as Microsoft Word, Microsoft Excel, or Adobe Acrobat, you can create and maintain report layouts based on data from diverse sources, including Oracle Identity Management products.

Oracle Identity Manager provides a set of standard Oracle BI Publisher report templates. However, you can customize each template to change its look and feel. in addition, you can create your own custom reports by leveraging Oracle Identity Manager database schema.

2.1.4 The Data Tier

Oracle Identity Manager is driven by data and metadata, which provides flexibility and adaptability to Oracle Identity Manager functionalities. Oracle Identity Manager data tier consists of Oracle Identity Manager repository or database, which manages and stores Oracle Identity Manager data and metadata in an ANSI SQL 92-compliant relational database, and an optional LDAP Identity Store.

This section describes the data tier in the following topics:

2.1.4.1 Oracle Identity Manager Database

Oracle Identity Manager repository is the authoritative store for the Who Has What, When, How, and Why data that is the core value of the identity administration and provisioning system. The data stored in Oracle Identity Manager database falls into the following broad categories:

  • Entity Data: Users, organizations, roles, role memberships, resources, provisioned resources

  • Transactional Data: Requests, approval and provisioning workflow instances, human tasks

  • Audit Data: Request history, user profile history

High Availability

The database provides a scalable and redundant data layer to avoid downtime and performance issues. Reliability, recoverability, timely error detection, and continuous operations are primary characteristics of a highly available solution.

Oracle Identity Manager architecture relies on the corresponding capabilities provided by the Database Management System that is used with the product. These capabilities must:

  • Encompass redundancy across all components

  • Provide protection and tolerance from computer failures, storage failures, human errors, data corruption, lost writes, system hangs or slowdown, and site disasters

  • Recover from outages as quickly and transparently as possible

  • Provide solutions to eliminate or reduce planned downtime

  • Provide consistent high performance

  • Be easy to deploy, manage, and scale

  • Achieve Service Level Agreements (SLAs) at the lowest possible total cost of ownership

A broad range of high availability and business continuity solutions are available. You can find out more about maximizing database availability by using technologies such as Oracle Real Application Clusters (Oracle RAC) and Oracle Data Guard at the following Web site:

http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

2.1.4.2 The Metadata Store

The logic underlying Oracle Identity Manager is metadata driven. The structural and behavioral aspects are described by using metadata. Oracle Identity Manager architecture relies on Oracle Metadata Services (MDS) to provide a unified store for metadata. This ensures consistent and reliable access to the metadata for Oracle Identity Manager and for the other Fusion Middleware components that it is built on. The same metadata that is used during the design phase of an application is used at application runtime through the metadata services layer. This ensures consistency through the lifecycle of Oracle Identity Manager. MDS also provides common administrative tooling for the metadata that can be used across various types of metadata stored in the common repository.

Key features and architectural principles of the MDS include:

  • Simplified resource management through a single, unified repository for all artifacts used by various Fusion Middleware components

  • Management of the metadata lifecycle for each artifact as it moves through the various stages of development, testing, staging, and production

  • Sharing and reuse of metadata across components

  • Categorization and reuse of artifacts, encouraging reuse, and promoting consistency

  • Versioning capabilities, which form the basis for various features

  • An upgrade-safe and layered customization mechanism through which metadata and application logic can be tailored per usage of the metadata

  • Advanced caching and assembling techniques coupled with configurable tuning options to optimize performance

Metadata accessed and managed via MDS can be in a file-based repository or a database-based repository. In Oracle Identity Manager architecture, the metadata is in Oracle Identity Manager database to take advantage of some of the advanced performance and availability features that this mode provides.

MDS provides features using which you can create applications to meet customization requirements, such as modifying applications to suit the requirements of a specific business group, customizing applications to suit the individual preferences of a user, and creating applications that are customizable at run time. For more information about customizing Oracle Identity Manager by using MDS features, see "Customizing the Interface".

2.1.4.3 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 is pulled into Oracle Identity Manager and made available as a part of the identity context.

2.1.4.4 Integration Between LDAP Identity Store and Oracle Identity Manager

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

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

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

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

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

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

When changes are made in the user and role data, the actual operation is performed with the help of the kernel handlers. These handlers go through an orchestration lifecycle of various stages, such as validation, preprocessing, action, and postprocessing. For more information about the various stages of kernel orchestration, see "Developing Event Handlers".

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

Figure 2-10 Oracle Identity Manager and LDAP

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

2.1.4.4.1 Configuring the Integration with LDAP

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

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

  • LDAP User Create and Update Reconciliation

  • LDAP User Delete Reconciliation

  • LDAP Role Membership Reconciliation

  • LDAP Role Hierarchy Reconciliation

  • LDAP Role Create and Update Reconciliation

  • LDAP Role Delete Reconciliation

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

See Also:

"Managing Scheduled Tasks" for detailed information about scheduled jobs in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
2.1.4.4.2 Provisioning Data From Oracle Identity Manager to LDAP Identity Store

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

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

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

Note:

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

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

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

This section describes the following topics:

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

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

2.1.4.4.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 the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Note:

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

For detailed information about the Bulk Load utility, see "Using the Bulk Load Utility".

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 the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

  2. LDAP Role Create and Update Reconciliation

  3. LDAP Role Hierarchy Reconciliation

  4. LDAP User Create and Update Reconciliation

  5. LDAP Role Membership Reconciliation

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

2.1.4.4.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 the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the LDAP Consolidated Full Reconciliation scheduled job

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

Note:

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

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

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

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

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

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

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

  • Reconciling the user or role account from LDAP to Oracle Identity Manager database:

    This provides the option to perform fine-grained reconciliation of a particular user or role. The value of the Reconciliation Search Base parameter is:

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

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

    The value of Reconciliation Search Base is:

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

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

  • All users under the node is reconciled:

    The value of Reconciliation Search Base is:

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

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

  • All roles or groups under the node is reconciled:

    The value of the Reconciliation Search Base parameter is:

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

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

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

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

Sample values for the Search Base parameter:

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

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

(objectclass=orclAPPIDPerson)
(title=foobar)

Messages Logged For the LDAP Sync Consolidated Full Reconciliation Scheduled Job

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

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

2.2 System Components

Oracle Identity Manager is built on an enterprise-class, modular architecture that is both open and scalable. Each module plays a critical role in the overall functionality of the system. Figure 2-11 illustrates the system components of Oracle Identity Manager.

Figure 2-11 System Components of Oracle Identity Manager

Description of Figure 2-11 follows
Description of "Figure 2-11 System Components of Oracle Identity Manager"

Oracle Identity Manager user interfaces define and administer the provisioning environment. Oracle Identity Manager offers two user interfaces to satisfy both administrator and user requirements:

  • Powerful Java-based Oracle Identity Manager Design Console for developers and system administrators

  • Web-based Administration and Oracle Identity Manager Self Service interfaces for identity administrators and users respectively

This section describes the following Oracle Identity Manager components:

Identity Administration

Identity administration includes creation and management of identities in Oracle Identity Manager. Identities include users, organizations, and roles. Identity administration also enables password management and user Oracle Identity Manager Self Service operations. Identity administration is performed by using Oracle Identity Manager Administration and Oracle Identity Manager Self Service Web clients, and the SPML Web service.

Provisioning

The provisioning transactions are assembled and modified in the provisioning module. This module maintains the "who" and "what" of provisioning. User profiles, access policies, and resources are defined in the provisioning module, as are business process workflows and business rules.

The Provisioning Server is the run-time engine for Oracle Identity Manager. It runs the provisioning process transactions as defined through Oracle Identity Manager Administration and Oracle Identity Manager Design Console and maintained within the provisioning module.

Audit and Reports

The audit and compliance functions include evaluating a person, organization, system, process, project, or product. This occurs by capturing data generated by the suite's workflow, policy, and reconciliation engines. By combining this data with identity data, an enterprise has all the information it requires to address any identity and to access a related audit inquiry. Audits are performed to ascertain the validity and reliability of information, and also provide an assessment of a system's internal control.

Reporting is the process of generating a formal document, which is created as a result of an audit. The report is subsequently provided to a user, such as an individual, a group of persons, a company, a government, or even the general public, as an assurance service so that the user can make decisions, based on the results of the audit. An enterprise can create reports on both the history and the current state of its provisioning environment. Some captured identity data includes user identity profile history, role membership history, user resource access, and fine-grained entitlement history.

Reconciliation and Bulk Load

The reconciliation engine ensures consistency between the provisioning environment of Oracle Identity Manager and Oracle Identity Manager managed resources within the organization. The reconciliation engine discovers illegal accounts created outside Oracle Identity Manager. The reconciliation engine also synchronizes business roles located inside and outside the provisioning system to ensure consistency.

If you want to load a large amount of data from other repositories in your organization into Oracle Identity Manager, then you can use the Bulk Load utility. The Bulk Load utility reduces the downtime in loading the data. In addition, Bulk Load utility import Oracle Identity Manager users, roles, role memberships, and accounts provisioned to users.

Common Services

Various services are grouped together that are shared and used by other Oracle Identity Manager components. These services are:

  • Form Designer: A form that allows you to create process and resource object forms that do not come packaged with Oracle Identity Manager.

  • Scheduler: A service that provides the capability to run specific jobs at specific schedules. This service can be used by users, application developers, connector developer, and administrators to create and configure a Job to be run at specified intervals. In addition, this service provides administrative capabilities to manage the functionality of jobs and their schedules.

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

  • System Properties: A system property is an entity that controls the configuration aspect of an application. In addition, to the default system properties, you can create and manage system properties in Oracle Identity Manager.

  • Deployment Manager: The Deployment Manager is a tool for exporting and importing Oracle Identity Manager configurations. The Deployment Manager enables you to export the objects that make up your Oracle Identity Manager configuration.

Workflow and Request Management

Various operations in Oracle Identity Manager cannot be performed directly. Instead, the operations must be requested. The request management service provides a mechanism to create, approve, and manage requests. A request is an entity created by the users or administrators who want to perform a specific action, which requires a discretionary permission to be obtained from someone or some process before the action can be performed. For example, a user can create a request to gain access to a laptop computer, a manager can approve the request and create an open requisition, and an IT resource administrator can approve the request.

The primary goal of a provisioning solution is to manage requests and provision resources. Request service provides an abstraction layer on the Business Process Execution Language (BPEL) 11g workflow engine. Functional components such as request, provisioning, and certification interacts with the workflow engine for human approvals. Request service caters to the various functional components in Oracle Identity Manager by managing workflow instances and categories, and provides an abstraction layer on BPEL.

Infrastructure and Middleware Integration

The Adapter Factory, Kernel Orchestration mechanism, Context Manager, and Plug-in Framework are designed to eliminate the need for hard-coding integrations with these systems.

Connector Framework

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

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

  • Identity connectors that are designed to separate the implementation of an application from the dependencies of the system that the application is attempting to connect to

  • Connectors based on custom generic technology connector providers

  • Custom connectors using the Adapter Factory