IGA Use Cases: Operations and Data Governance

Last modified 24 Jun 2022 16:20 +02:00
This page is a work in progress.

Following use-cases are defined in the area of operations and data governance.

Operation teams are managing IGA data of individual users or objects and/or of bulk of objects. Most (if not all) the tasks should be performed using GUI.

1. Single object operations

1.1. Bypass role engineering process (create/modify/delete roles without approval)

Scenario

New role: IGA administrator needs to create large amount of roles and the configuration and ownership is already agreed.

Role modification: IGA administrator needs to update role configuration. It is just some technical update (e.g. typo in description) and full role de

Role removal: Some old not used roles are being removed. IGA administrator is performing cleanup and wants to delete such roles without

Actors

This operation is typically performed by IGA administrators or IGA engineers. It may be upon request of Role manager.

Motivation

Role objects are routinely modified using Role engineering process. Modification of the roles needs to be governed and approved by Role manager function. But this process may be time-consuming and may block administrative operations.

To balance security and operations efficiency, the IGA administrators or IGA operators with sufficient privileges should have an option to bypass the Role engineering process - create/modify/delete roles without approval.

Of course, each such operation must be correctly audited with identification that it bypassed role engineering process.

Such operation is needed e.g. while changing some typos in role description, or performing large reconstructions in structure of roles driven by Role manager.

There is still open question how to define and identify such operation. Whether by specific fields of roles could be allowed, or leave whole role for specific modification and just log it to audit. Identification of this specific operation in audit is needed.

User Story

The operation should be performed only by users with specific authorization.

New role: IGA operator/administrator just creates the role with actual configuration via GUI or using REST (e.g.via Midpoint studio). He somehow identifies that the role engineering process for the role should be bypassed. The new role starts to be active.

Role modification: IGA administrator opens modifies role configuration. He somehow identifies that the role engineering process for the role should be bypassed.

Role removal: IGA administrator deletes the roles.

In each case - the operation is listed in audit log. With identification that this bypassed the role engineering process.

This procedure is actual way of role management. There is no role engineering process defined in midPoint yet.

1.2. Bypass access request process (create/modify/delete assignments without approval)

Scenario
Actors
Motivation
User Story

TODO

1.3. Recompute the role assignments

Scenario
Actors
Motivation
User Story

TODO

1.4. Troubleshoot the recompute operation

Scenario
Actors
Motivation
User Story

TODO

1.5. Approve/Reject request on behalf

Scenario

An manager can’t technically perform approval, but he decided offline. The operation must be performed by IGA team. It should be documented in the approval.

The operation may relate to both approvals in access request process and in the role engineering process.

Actors

The operation should be performed by IGA operator, IGA administrator or Role manager.

Motivation

Some situations require fast approval when the approver is not available. This operation allows to overcome such critical situation.

User story

IGA operator with sufficient privileges opens the defined request and approves/rejects it. The approval process proceed to next step. The operation is identified in the approval history. E.g. as "Approved by <real approver - the IGA operator> on behalf of <original approver>" or some other way readable to end user.

This operation should have individual authorization, as some deployment may not allow this scenario.

Implementation

The use-case is already implemented. The authorization #completeAllWorkItems allows this operation. Documentation is at Workflow security (authorizations) page.

Actual documentation incorrectly states that the function is obsolete and not supported. JIRA-7960 is created for the situation.
The operation is incorrectly described in the Approval history. It is unclear to end user, what has happened. JIRA-7961 is created for the issue.

2. Bulk operations

2.1. Define set of users/objects for bulk operation

Scenario

The IGA operator must perform an operation over list of users (or other objects) he obtained. There is no specific query for defining the users. The list is obtained externally - not from midPoint. E.g. in the form of csv file.

Actors

Typically, this is performed by IGA operator or IGA administrator.

Motivation

When managing bulk of objects, the operators are defining the search filters by query. Sometimes, the query is not good solution, as they need to perform operation on set of objects that does not have anything in common to build a well readable query.

Defining query by naming all users is not practical and not well readable. Importing such list as scope definition for bulk task or bulk action would help the operator to solve the problem easily.

User Story

The IGA operator or administrator upload the list of objects (in csv form to midPoint). Then he prepares the bulk task or bulk operation definition and references the uploaded file as source in the search filter. Then he performs the operation.

The objects in csv should be defined by one of unique attributes - typically name. It may be large (up to number of users in mp).

2.2. Update attributes / assignments for set of users

E.g. Disable/enable set of users

Scenario
Actors
Motivation
User Story

TODO

2.3. Update attributes for set of roles

E.g. change ownership or approver of set of roles when user leaves.

Scenario
Actors
Motivation
User Story

TODO

2.4. Change approver of pending requests

E.g. when person leaves the company and some approvals are left opened.

Scenario
Actors
Motivation
User Story

TODO

2.5. List and compare attributes for set of users

Scenario
Actors
Motivation
User Story

TODO

2.6. List and compare role assignments (access) for set of users

Scenario
Actors
Motivation
User Story

TODO

2.7. List and compare entitlements for set of users

Scenario
Actors
Motivation
User Story

TODO