Request / Approval

In most cases, access is granted in one of two ways:

• Birthright rules.
• Requested access.

The first option, birthright rules, involves rules that evaluate criteria such as job title, department, location, or other attributes used in your environment. Based on these attributes, access can be automatically granted. An example of a birthright access could be a rule that creates an AD account for the user, puts them in the right OU, sets the required group memberships, network drives, and creates a mailbox. Birthright rules enable access to be applied in a consistent way and can reduce the amount of time needed for onboarding transfers and terminations. Granting access by a birthright rule is described in detail in this document.

The second way to gain access is by creating a request. Here, either the employee or their manager can create a request for an account or entitlements. If the access requires authorizations, then one or more people may be required to approve the request. Once all the authorizations have been obtained, the system can either automatically provision access, or a notification can be sent to the service to ask to have someone manually provision the access. Even if access is provisioned manually, there are compliance benefits to this process.

This document deals with the second access granting option - defining a request/approval model via service catalog.

A service catalog in the SelfService portal is shopping-cart based. Using the catalog, users can search, find entitlements or objects that they need and then create a request. Upon approval, access will be granted.

To implement a service catalog in OpenIAM, we need to do the following:

• Define a categorization/classification structure within which users will find their applications and entitlements.
• Define the approval flow.

The following video tutorial provides an introduction to workflows:

The sections below will describe how to configure each of these.