OIM 11g R2 Delegated Administration Model – Sample implementation (Part II)

Introduction

This article is the continuation of Part I which describes the architecture of a Solution that addresses the requirements of a Sample Use case described later.

In Part I, some key concepts were discussed. Below is a list of topics introduced in Part I of this post:

·         Scoped Administrative Roles

·         Access Policies

·         Disconnected Application Instance

·         Entitlements

This list is intended to serve as a reminder to the audience of the concepts comprising the foundation of the proposed solution.

This post will focus on the following use case:

A Real-Estate Company needs to implement a Provisioning solution to control access to the company's applications. Users log in to an application and are granted access to the application’s features based on group memberships in LDAP groups.

The company has hundreds of LDAP groups controlling what users can do within applications; individual assignment of those entitlements would be highly impractical.

In addition, the company is about to complete three acquisitions and needs to be able to quickly incorporate the new assets to the provisioning framework and start controlling access grants for the new employees coming over from the acquisitions. This is very complex to achieve since the acquired companies have their own directories which will not go away overnight.

Part III will provide the step by step instructions on how to address the requirements.

Main Article

Part I introduced the concept of a Resource Centric Delegated Administration Model, where the visibility of users and resources was controlled by role membership in Scoped Administrative Roles (SARs). Users can only belong to a single Organization, but Administrators can still manage users that do not belong to their Organization.

Resources, on the other hand, can be published to multiple Organizations and users having the proper scoped privileges can manage the resources published to one or more Organizations without having to be part of the Organizations to which the Resources are published.

Use Case

The use case presented in the introduction of this post has the following requirements:

Requirements

The requirements are divided in three areas:

·         Resource Visibility

·         User Visibility

·         Access Management

Resource Visibility

Resources are visible to users based on the following criteria:

·         User performs in a certain role in the Company

·         Resource belongs to a functional category

·         User has an affiliation to a functional category

User Visibility

Users are placed in one Organization and they are managed by Administrators based on the following rules:

·         There is an End-User Administrator for each Organization

·         There are Administrators at the regional level

·         There are several Organizations within a Region

Access Management

Application Access Privileges can be requested by users in any organization. The Entitlements associated to application access are visible to users based on the following criteria:

·         User belongs to specific Application Roles

·         User is an Administrator of an Application Module to which an Entitlement is linked

Organizational Structure

The Real-Estate Company has the following Organization Structure for Users.

Regions and Departments

The company has three regions:

·         West Coast

·         Mid West

·         East Coast

Each region has a standard set of departments, plus some region-specific ones. The standard departments are:

·         HR

·         Realtors

·         Accounting

·         Marketing

·         Sales

West Coast specific departments are:

·         Legal

·         IT

East Coast specific departments are:

·         Procurement

·         Finance

·         CEO Office

Applications

The Company has the following applications available to all employees:

·         Employee Portal

·         Benefits Management System

Applications accessible to Realtors are:

·         Listing Portal

·         Contracts

The Finance department owns the following applications:

·         Loan Processing Application

·         Appraisal Management

Entitlements

The entitlements specified for each Application have a one-to-one mapping with LDAP groups. The following Entitlements are defined for each Application:

Employee Portal

·         News Viewer

·         Content Viewer

·         Application User

·         News Admin

·         Content Admin

·         Application Admin

Benefits Management System

·         Member Profile Viewer

·         Member Profile Manager

·         News Letter Viewer

·         News Letter Publisher

Listing Portal

·         Property Listing Owner

·         Property Listing Viewer

·         Property Listing Admin

Contracts

·         Contract Owner

·         Contract Viewer

·         Contract Admin

Loan Processing Application

·         Loan Officer

·         Loan Assistant Officer

·         Loan Validator

·         Loan Underwriter

Appraisal Management

·         Executing Officer

·         Reviewing Officer

·         Approving Officer

·         Administrative Officer

 

Summary

Based on the Application’s availability to each type of employee in the company, the SAR memberships enabling the proper visibility constraints will be setup. Part III of this article will describe the configuration required in OIM to implement the process to assign employees to their corresponding SARs.

In Part III, the design of the solution will reuse the infrastructure described in Part I for the automation of SAR assignments.