Applied Oracle Security: Developing Secure Database and Middleware
Chapter 9: Oracle Identity Manager
User provisioning has become a critical problem for most enterprises dealing with how to give users access to resources. Oracle Identity Manager (OIM) is Oracle’s identity management solution platform that assists with access management, role management, directory services, entitlement management and more. In this section, learn more about how to use OIM and understand its policy framework, which includes the user, user group and organization.
Table of contents:
How 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
This chapter covers Oracle Identity Manager (OIM), which is central to Oracle’s identity management strategy. OIM provides a platform for designing provisioning processes for user and access information to solve the challenge of getting the right accounts and privileges automatically set up for users across all applications they need to access. Configuration of such provisioning automation can be done in many ways; we’ll show you some examples and best practice implementations of user provisioning. This chapter does not intend to cover the full set of OIM features and functionalities, and instead it highlights those that are used most frequently in solving provisioning problems.
The User Provisioning Challenge
When a new employee joins a company, she needs an office, a computer, office supplies, an email address, access to business applications, and so forth. This process goes by many names -- such as on-boarding or hire-to-retire. User provisioning is a subprocess initiated by the onboarding or hire-to-retire process that deals specifically with giving users access to resources.
More on Oracle database security
Read about encrypting data on Oracle SecureFiles
Learn to configure Oracle fine-grained access control for network services
Find out why privileged user management is a must for DBAs
User provisioning has become a critical problem for most enterprises looking to lower their administrative burdens of account management while also trying to reduce risk by centralizing the control for granting access to important applications. Instead, with a user provisioning solution, new account creation tasks can execute in a consistent manner, whereby certain approvals and verifications are mandated before access is provided to new users.
The other critical user provisioning challenge is a technical one—system integration. A typical enterprise has a wide-ranging set of applications built on different technologies, standards, and semantics and therefore centralizing the account creation process is often an integration nightmare
With these three drivers in mind -- simpler administration, reduced risk, and easier integration -- OIM was added into the Oracle Identity Management product suite with the acquisition of Thor Technologies, a smaller and best-of-breed user provisioning product. Since the acquisition, major development and improvements have been made on the product, but the basic framework and approach of user provisioning is still meant to be one that aligns with the three drivers.
Oracle Identity Manager Overview
OIM is a fundamental building block for an overall identity management solution. Access management, role management, directory services, and entitlement management all depend on having a working user provisioning solution that ensures the right identity data exists in the right location for other solutions to use. And with so many different types of policies, processes, and integrations involved in a typical provisioning problem, the provisioning technology needs to support a high level of flexibility and customization. However, with added flexibility comes complexity, so OIM tries to achieve a balance between supporting customization of provisioning without making the implementation process too difficult.
The OIM product framework is architected in a way that allows the developer to choose the level of complexity to work with. Usually, a higher need for customization introduces higher levels of sophistication in configuration. For example, OIM provides many out-of-the-box standard integration solutions to connect into (in the form of packaged connectors and adapters) that provide basic solutions for OIM to provision into a particular system (such as Active Directory). However, additional requirements, such as approval workflows or custom attributes around provisioning, require that the developer customize the baseline connector to support those requirements. You will learn how to implement many of these requirements using OIM in this chapter.
Overall, OIM remains a sophisticated piece of technology that needs to be well understood before implementation. A good place to start learning about OIM is with some key concepts inside the OIM policy framework for managing user provisioning.
As described throughout this book, security entails understanding who gets access to what in any context. In OIM, a user represents that "who" in context of enterprise user provisioning. An OIM user is application-agnostic and, as such, can be provisioned to accommodate different applications using application-centric representations and data models. An OIM user defines a specific default data model with certain standard identity attributes, such as First Name, Last Name, Employee Type, Title, Organization, and so on, that can be extended as needed. The data model defines the fundamental enterprise-level identity data that drives the user’s accounts and privileges in each resource.
In many applications, users are grouped together based on common functions, organization, job level, and so forth. OIM provides the user group object as a mechanism to support organizing users into simple compartments according to certain rules and policies.
A user can be associated to a group in two ways: via direct membership assignments or ruledriven
memberships. Direct assignments are the intuitive mechanism with which most people are familiar.
Membership is simple, straightforward, intuitive, and easy to understand and validate.
Direct assignments are performed in a discretionary manner by another privileged user (such as administrators, managers, and so on), and the memberships are maintained in a static way (memberships are also revoked in a discretionary way). Direct assignment is therefore not a popular approach for certain applications and groupings.
Instead of static group memberships, you can use the notion of membership rules to manage group memberships in a more automated manner. Membership rules are simple conditional statements that are evaluated against each user to determine whether or not the user belongs to a group. Figure 9-1 shows a membership rule, "location == San Francisco." This is an example of automating group memberships based a "location" attribute value.
This rule defines its members as users who have a job title of DBA and who work in the San Francisco area. User groups using membership rules are more dynamic in nature and provide significant flexibility for managing who belongs to which groups and therefore should be granted what resources. This mapping is performed inside an access policy (discussed a bit later).
FIGURE 9-1 Configuring membership rules for user groups
OIM also offers the organization object to also group users. However, the two objects are meant to organize users with different purposes that are complementary. Typically, user groups partition users based on user attributes that are cross-functional and could exist across the enterprise in any organization or department.
An OIM organization is meant to represent a business function or regional department, such as Sales, Product Development, North America Business Unit, and so on. OIM organization objects can be nested and therefore represent real-world organizational hierarchies.
There are three types of OIM organizations: company, department, and branch. Here is how each type maps common real-world organizational models:
- Company objects represent autonomous business units that own multiple business functions typical in any firm (such as Sales, Marketing, Finance, IT, and so on).
- Departments exist underneath company objects to represent business functions (such as Sales, Finance, and so on).
- Branches exist underneath departments to provide additional groupings of users, typically by geography.
It is not always necessary to divide and model your organizations exactly the way your firm or enterprise is organized, since you may not always need that level of detail. Also, keep in mind that a real-world organizational model can change frequently, so you may not always want to align fully to those models if your provisioning and access policies do not depend on the user’s organizational associations.
An access policy is a way in OIM to map who should have access to what resource. The overall mapping from the user to the resource can be made up of mappings from the user to user groups and from user groups to resources. Figure 9-2 shows an instance of an access policy that can be automated to provision end users to the appropriate resources based on the rules and mappings that are represented by the arrows from each object.
In addition to controlling the resource, you can also control each user’s privileges within each resource by associating application-level privileges to user groups in the access policy. For example, suppose two user groups, "Data Analyst" and "Data Administrator," should both be provisioned to access the same database application but with different database roles (such as analyst and DBA).
You can set that mapping of user group to database roles inside an access policy.
FIGURE 9-2 Access policies define the mappings for users to groups and groups to resources. Resource Object
A resource object is an OIM object representing a logical resource for which users need to have
accounts created. For instance, you can have OIM resource objects called "E-mail Server" and
"Customer Database." A resource object can represent almost anything, from applications, databases,
and operating systems, to physical assets and any other entity relevant to provisioning.
A resource object is used to track which users are provisioned to what logical assets. It can report on the current list of users who are provisioned to the E-mail Server resource in our example. Resource objects are also used to design approval workflows and policies around those workflows that are application-centric. So, for example, if a specific person is assigned to approve all new accounts to the e-mail Server system, you can use the resource object to set that condition in your workflow rule.
OIM resource objects do not represent the physical resources themselves and therefore do not contain physical details (such as IP addresses, server hostnames, and so on). For physical server representations and details, OIM provides the concept called IT resources.
An IT resource is a physical representation of a logical resource object. It holds all the physical details of the resource for which a new user is provisioned. If, for example, you have a resource object called Customer Database, you need to also define one or more corresponding IT resource objects that represent the physical characteristics of the resource (such as server hostnames, IP addresses, physical locations, and so on). This information is used by the OIM integration engine when it needs to communicate with those servers to complete a provisioning-related task.
The specific set of attributes of an IT resource is highly dependent on the type of system on
which the account is being created (relational database IT Resources expect schema names and
passwords; LDAP servers IT Resources expect names places and directory information tree
OIM allows you to define an IT resource type that acts as a template to define a specific data model for certain types of IT resources.
Download the chapter "Oracle Identity Manager " in PDF form.
This was first published in March 2010