Applied Oracle Security: Developing Secure Database and Middleware
Chapter 9: Oracle Identity Manager
In this section, learn about the different sophistication levels of the user provisioning process. Learn how to know whether you should be using discretionary account provisioning, self-service provisioning, workflow-based provisioning or access policy–driven provisioning
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 Processes
A user provisioning process looks similar to any other business process. It represents a logical flow of events that deal with creating accounts within enterprise resources to make a new user product.
Every provisioning process uses some fundamental building blocks, and the following sections provide different levels of sophistication in user provisioning. Your choice of sophistication level should, obviously, depend on the requirement and sensitivity of the particular resource. The level of complexity of a provisioning process is typically related to the level of risk associated with the resource being provisioned for access. For systems or databases holding critically sensitive data, provisioning should enforce a stronger verification process, such as requiring certain user attributes(such as job code or seniority) and management approvals before the user is granted access to an account in that critical system. Traditionally, these advanced provisioning processes were executed manually, but with OIM’s process integration capabilities many of these provisioning enforcement tasks can be automated. The following sections provide some configuration solutions for the process-related challenges of user provisioning.
Discretionary Account Provisioning
Discretionary account provisioning is a style of provisioning by which an existing OIM administrator or privileged user can provision a user to an application in a discretionary manner.Inherently, a discretionary method is less consistent and leaves it up to the administrator to know what to do, rather than using a codifying a policy in the provisioning process. By default, this style of provisioning is automatically set up when an OIM is set up with an application using a packaged connector. And typically enterprises use this as a baseline to start designing and implementing their automation rules to make the process less discretionary. To provision a resource to a user in this manner, you’d use the Resource Profile For Users section in the OIM administrative console, shown in Figure 9-3, and click the Provision New Resource button to access the Provision New Resource wizard.
Typically, this style of discretionary provisioning is useful for enterprises that are looking to take the first step from manual provisioning processes to a basic level of automation and centralization. Also, if the enterprise lacks formal governance rules and policies around access to systems and information, handling provisioning requests in a request-based manner might be the inevitable first step. However, if OIM has been put in place, you can accelerate your path to better provisioning automation by leveraging a lot of the built-in features of OIM, such as allowing users to make new requests through OIM and performing basic maintenance tasks such as password resets.
FIGURE 9-3 Discretionary provisioning of new resources
The discretionary account provisioning requires an administrator or a privileged user to initiate the provisioning process. In other words, users will still need to make a phone call or send an email to the administrator to request a new account in an application. However, OIM can be easily configured so that users can communicate entirely through the OIM framework when requesting access to new resources. To enable this, you need to set the Self-Service Allowed flag in the resource object for which you want to allow this. Figure 9-4 shows the option in the configuration screen.
Once this configuration has been set for a resource, that resource appears in the list of choices in the Request New Resource section in the OIM administrative console, as shown in Figure 9-5.
FIGURE 9-4 Configuring self-service requests on resource objects
FIGURE 9-5 Making requests for new self-service–enabled resources
Over the past few years, self-service user provisioning has been a popular solution especially when delivering simple capabilities such as resetting passwords and requesting accounts in new systems and applications. It can greatly reduce the burden on administrators for performing highly repetitive tasks of manually inputting data from paper forms submitted by an end user. However, enabling the self-service capabilities on resources usually leads to some manual oversight, typically enforced through approval workflows that allow administrators to verify and sign-off on requests from end users. Without such approvals, the resource might as well be a fully public resource.
A workflow-based provisioning process gathers the required approvals from the designated approvers before granting a user access to an application or another resource. For example, the Finance application might require that every new account request be approved by the CFO to maintain tight control of who gets to see sensitive financial information.
To set up approval workflows, you can use the graphical workflow designer in the OIM administrator console, which you can navigate to from the following tabs: Resource Management | Manage | Resource Name | Resource Workflows | Create New Workflow
To continue the example from Figure 9-5, we’ll create an approval workflow on the “Financial Accounting” resource object that requires two approvals: one from the user’s manager and one from the application administrator. The following steps create the workflow:
1. Create a new approval workflow with a descriptive name.
2. Right-click the Workflow Designer and create a new task.
FIGURE 9-6 Configuring an OIM workflow assignment rule
3. Double-click the newly created task and go to the Assignment tabs.
4. Edit the Default rule and select the Assignment Type, as shown in Figure 9-6.
5. Select the Request Target User’s Manager type, which is configured to route approvalthrough the requesting end user’s manager.
6. Once both the tasks are set up and configured appropriately, build the process sequence by right-clicking the Start icon and selecting Add Non-Conditional Task. Then drag the arrow to your first task (Manager Approval).
7. Right-click the Approve box of your first task, select Add Response Generated Task, and drag the arrow to the second task (App Admin Approval) to finish out the workflow. Figure 9-7 (on the next page) illustrates the completed view of this.
Access Policy–driven Provisioning
Recall the two keys questions that drive user provisioning efforts:
Who has access to what resources?
Who should have access to what resources?
FIGURE 9-7 OIM Workflow Designer
Request-driven provisioning certainly helps us answer the first question, since all user provisioning occurs through a centralized process and is therefore tracking who is being provisioned where.However, for the second question, the request-driven style is not taking responsibility for ensuring if a user should access a certain resource, since the provisioning occurs in a discretionary manner.
To address this issue, corporate security has to lend a hand by providing us a set of access policies that define rules regarding “who should access what.” Once those policies are defined, you can implement them very easily in OIM through the web administrative console’s Access Policies section.
The following high-level steps are required to set up an access policy:
1. Go to the Create Access Policy section in the OIM administrative console.
2. Select the resource(s) to be provisioned under the chosen access policy, as shown in Figure 9-8.
3. Set the date this for which access needs to be issued.
4. Select the resource(s) that should be denied to the user through this access policy.
5. Select the user groups that apply to this access policy, as shown in Figure 9-9.
FIGURE 9-8 Resource selection during access policy configuration
Once you have defined these four facets of the access policy (what is provisioned, when it is issued, what not to be provisioned, and who this is for), you are ready to automate the majority of your enterprise user provisioning through a collection of these access policies. If you have defined the approval workflows, the access policies will automatically trigger those flows to be routed through the appropriate authorities.
FIGURE 9-9 User group selection during access policy configuration
Download the chapter "Oracle Identity Manager " in PDF form.
This was first published in April 2010