Applied Oracle Security: Developing Secure Database and Middleware
Chapter 9: Oracle Identity Manager
In this section, learn how to use the Oracle Identity Manager (OIM) integration platform, including the OIM connectors such as prebuilt connectors and generic technology connectors. Also, find out about the two types of system integrations supported by OIM, provisioning and reconciliation integrations.
Table of contents:
to use Oracle Identity Manager for user provisioning
Understanding the Oracle user provisioning process
Using Oracle Identity Manager (OIM) connectors and integration
The Oracle Identity Manager (OIM) deployment model
User Provisioning Integrations
One of the key strengths of OIM is the flexibility of its integration platform. However, highly flexible frameworks can often become complex and less usable. As a result, since version 9.1, OIM offers several interaction patterns that allow a user to choose the level of flexibility and sophistication of developing integrations with external systems. I have found that this approach is driven more or less by the 80/20 rule: approximately 80 percent of the use cases are satisfied by 20 percent of the integration types. Those 20 percent integration types are simplified into standard connectors and templates.
Every choice of integration between OIM and an external target systems falls into one of the following categories:
- Prebuilt connectors A specific connector implementation for a specific system or
application (such as Active Directory, PeopleSoft, SAP, DB2, Oracle Database, and so on).
- Generic Technology Connector A connector for commonly-used formats and industry standards (such as flat files, Web Services, and Service Provisioning Markup Language).
OIM provides a connector pack that bundles prebuilt and packaged connectors to most thirdparty systems of all types, including databases, enterprise resource planning (ERP) applications, operating systems, Lightweight Directory Access Protocol (LDAP) servers, and so on. Setting up these connectors in OIM is a fairly straightforward process:
1. Copy the connector files to the OIM server.
2. Import the connector’s (XML-based) descriptor file into the OIM repository through the Deployment Manager section in the OIM web console.
3. Define the IT resources associated to this connector, Through this connector install process, OIM automatically creates the foundational elements of the new resource by creating the necessary resource, IT resource(s), and IT resource type objects associated to the connector. At this point, the environment is ready for basic requestdriven provisioning. (See “Discretionary Account Provisioning.”)
Generic Technology Connector
One of the first additions Oracle made to the OIM product after its acquisition was the development of the Generic Technology Connector (GTC). Oracle realized that OIM had great capabilities for supporting high-end system integration challenges such as connecting to ERP systems and LDAP servers using prebuilt connectors or developing custom connectors on top of the OIM development framework. However, there was no easy way to perform quick and simple integrations from OIM to smaller scale and perhaps more departmental applications that were built using simpler database technologies such as Application Express or Microsoft Access. As enterprises are looking to automate provisioning to all types of applications (enterprise and departmental), Oracle needed a solution that targeted those applications and systems with a simpler approach to provisioning. This was the genesis of the GTC, introduced in OIM 9.1.
The GTC supports simple integrations to custom-built applications or other systems that rely on simpler data exchange formats such as comma-separated fields. It also supports many industry-standard protocols such as Service Provisioning Markup Language (SPML). The GTC is another example of a packaged integration used for a common set of applications that can read and exchange information in a standard format. While the GTC does not necessarily solve complex integration scenarios, it does provide a quick integration to medium- to low-complexity applications. Figure 9-10 illustrates the provisioning lifecycle of a GTC-based integration.
FIGURE 9-10 The GTC lifecyle
A GTC-based integration provides a set of packaged functionalities, known as “providers,” to perform the different types of actions needed to execute an end-to-end user provisioning process. The process runs starting from identity data reconciliation from a source system to provisioning to a target application.
The GTC is a useful choice whenever you’re dealing with applications that can support simpler or standard data exchange formats, such as comma-separated files or the SPML format. The typical cost to set up and maintain a GTC-based integration is much lower than that of other types of OIM integrations. Unlike the prebuilt connectors, the GTC code is shipped with the OIM server so there is no need to install additional software.
Two types of system integrations are supported by OIM: provisioning and reconciliation. Provisioning automates account creation from the OIM server to an application or resource using the data from the OIM repository. Reconciliation automates the creation of an OIM identity record based on an external source of identities (that is, a source of truth). Most often, OIM reconciles from an external human resources application as an authoritative source of employee data and then provisions to business productivity applications, such as email, intranet portals, and other ERP systems.
Reconciliation is often driven by business events such as new hires, new customers, organizational changes, employee transfers, and so on. Since these business events are initiated in an ERP system, most often the Human Resources (HR) system, it makes sense to configure OIM to setup reconciliation with those systems so it can listen for relevant identity events. OIM uses two reconciliation styles: trusted source reconciliation and target resource reconciliation.
Trusted Source Reconciliation
Trusted source reconciliation (TSR) is used for reconciling information from external authoritative sources (such as HR systems, CRM, and so on) that usually result in creating, modifying, or removing users in the OIM local repository. If the appropriate user groups and access policies are configured, the external reconciliation events can trigger provisioning processes that create or change account data in applications and resources where users are provisioned. For instance, a new employee record entered into the HR application could trigger a record creation in OIM (via reconciliation), which then can subsequently trigger provisioning events (via access policies) to create an e-mail account in the MS Exchange e-mail server.
TSR has two implementation forms:
- Attribute based Each trusted source is responsible for reconciling one or more
attributes of the user. For instance, the HR system can be the authoritative source that owns the
first and last name attributes, whereas the enterprise LDAP server can be the authoritative source
for the e-mail address attribute.
- User-type based Each trusted source is responsible for reconciling a particular user type in OIM. For instance, the HR system can be the trusted source for employees, whereas the CRM system can be the trusted source for customer user types.
Target Resource Reconciliation
Target resource reconciliation (TRR) is used mainly for reconciling changes to already provisioned users. For instance, if someone changes the phone number of a user in Active Directory without going through the OIM management console, OIM can be configured to reconcile those changes using TRR.
TRR is a very powerful feature in OIM since it can not only choose simple attribute changes from external sources, but it can also be used to identify rogue accounts in external systems quickly. If someone tries to create a privileged account in an external resource (such as Active Directory), TRR can detect that potentially harmful account and take any step that you configure. For example, TRR can configure a policy of automatically disabling rogue accounts until an administrator explicitly re-authorizes the access.
TRR is also useful for reconciling list-of-value fields from target systems (such as LDAP groups, roles, and so on) into OIM so that you can map access policies to actual target system roles and groups.
One of the main drivers of enterprise identity management is the notion of knowing and auditing who has access to what resources. In addition to standard access reporting requirements, compliance mandates often require periodic attestation of users’ access to critical applications. Manual attestation of access is an expensive and risky process to enforce, so enterprises are looking to products like OIM to help provide attestation.
Attestation requires that a defined approval workflow periodically re-authorizes access to sensitive information (typically financial data) that falls within a particular compliance mandate such as the Sarbanes-Oxley Act (SOX). The person with the authority to re-authorize, also known as the reviewer, can have a number of relationships with the user(s) being attested. The reviewer can range from user’s direct supervisor, to an application administrator, to the chief operating officer (COO) of the organization. Basically, the reviewer must have the authority and knowledge to answer the question “who should access what resource.” This authority can also be delegated to a different reviewer if the first reviewer is unable to answer that question.
OIM provides a fairly simple way of managing attestation by embedding it into the provisioning process framework. In other words, you can wrap any resource with the need for attestation.
Following are the typical steps you need to take to set up an attestation policy that can govern by user type (such as organizations, roles, and so on) and by the resources that require this form of periodic re-authorization:
1. Go the attestation policy manager. In the OIM administrative console, navigate to the Attestation section.
2. Create a new attestation process. Typically it makes good sense to create attestation processes by resource and/or organization.
3. Specify the scope of users for attestation. This lets you partition how you attest different types of users. For instance, the accounting department attestation process could be approved by the user’s supervisor, whereas the sales department attestation could be attested by the sales region’s vice president.
4. Specify the scope of applications/resources for attestation. This lets you partition your attestation process by different resources. It often makes sense to use the Resource Audit Objective (which is an attribute associated with a resource) to define your attestation process since different audit objectives require different types of attestations.
5. Specify additional attestation process details. Define additional details such as frequency of the attestations, the process owner, and the grace period for completing the process. Keep in mind that a significant delegation of attestations can occur in large organizations, so the grace period should factor that in.
Figure 9-11 shows how a completed attestation process could look.
FIGURE 9-11 Managing an attestation policy in OIM
In addition to attestation, another common requirement is to provide compliance and security officers a single consolidated view of who has access to what resources and applications in the enterprise. In other words, officers are looking for a reporting solution around users and their access.
One of the benefits of using a centralized hub-and-spoke architecture (see Chapter 8 for details about this type of architecture) as implemented by a product like OIM is the ability to centralize the identity data into a single repository, which allows you to run reports on top of that data. Access reporting is a key feature of OIM, especially when you need to report on applications that fall under the compliance requirements of SOX and other legislative mandates. Since every new user and modification to existing users is processed through OIM, you can use OIM’s reporting infrastructure as a fairly reliable source for asking the question “who has access to what” and, occasionally, “who had access to what.”
Through the web administrative console, OIM offers two types of reporting functionality: operational and historical. Operational reporting gives the user a snapshot of the current users’ access. Historical reporting provides an additional time dimension so that you can view a snapshot in history. A good example that may be driven by SOX requirements is the need to see who had access to the financials application during a certain time period (such as during a corporate quiet period of June 1–30 in 2008). Both types of reports are critical both for compliance and for assuring auditors that the information was under authorized access at all times.
To run either operational or historical reports, navigate to the Reporting section of the OIM administrative UI and click the appropriate report and query with the desired parameters. Figure 9-12 shows a sample report on access to the Financial Accounting application in my environment.
Notice that in Figure 9-12, you can modify parameters to customize your report. You can also export to text-based formats that can be imported into tools such as MS Excel, allowing you to share these reports via e-mail to other parties, such as corporate auditors.
FIGURE 9-12 Access reporting shows who has access to what and who had access to what.
Download the chapter " Oracle Identity Manager " in PDF form.
This was first published in April 2010