IGA Use Cases

Last modified 03 Jun 2022 19:25 +02:00
This page is a work in progress.

Business use cases and "user stories" for Identity Governance and Administration. The purpose of this document is to guide design activities by providing a list all the practical use cases for inspiration. We do not claim that our implementation will support all of those use cases.

This list is not complete. It is expected that it will be continually updated.

1. Actors

IGA information is consumed by different actors. Starting with end-users, through technical engineers and finishing by business and security managers.

The IGA information must be available to all of them in the form they need.

Actor Form of information Information Interface

End user

Business level

Typical interaction of end user is self-service - end user needs to request new access, modify his profile and review the access he has assigned already. He needs to see information of individuals - himself or his teammates.

End-user needs the access described in business form.

Self-service GUI

Power user

Business level

This is typically business manager or any person who is responsible for managing access of others. Additionally, to the operation of typical end-user, he needs to approve access requests, manage his teams and their access and create/modify business roles.

Typically, he needs to obtain the information by viewing object details in business form and some specific reports prepared for their teams.

Self-service GUI

Application engineer

Business level + technical level (only in definition of his roles)

Application engineer is end-user in IGA solution with specific privileges. Within role engineering process he creates and manages details of application roles related to his application.

He needs to see these roles, view also technical content of the roles (not XML, just via GUI) and be able to approve requests if he is assigned as an approver of any role.

Administration GUI (only for role engineering)

IGA operator

Business level + technical level

This is typically helpdesk operator or some IT operator. The person should be able to manage user attributes (e.g.credentials), manage access for the (scope of) users and manage the teams. He needs to process operation over bulk of users.

He needs to operate via GUI.

Administrator GUI

IGA administrator /
IGA engineer

Both business and technical level + full access to XML details of the objects.

These users need full access to the system using GUI and other tools. Need to configure IGA system and also data (on request)

Administrator GUI
Other tools

Role manager

Both business and technical level

Needs full access to the GUI, to be able to fully view and possibly manage the role data (structure and assignments).

Administrator GUI

Security officer / Auditor

Both business and technical level

Needs full read access to GUI. Typically, these actors need to see/run reports and user details of specific users.

Administrator GUI

The meaning of the form of information is as follows:

  • Business level - providing information in the form of "user", his "attributes", "application", "role", "access".

  • Technical level - technical information of user’s "accounts", "entitlements" (assigned objects). Configuration of application role (inducements, archetypes, …​) but displayed in GUI and terminology acceptable to IT users not specified in midPoint.

  • XML details - detail deep midPoint configuration. Good midPoint knowledge is needed.

2. Use-Cases

Multiple use-cases may be defined for the Identity governance. For clarity, we have divided them into the following areas:

  • Role engineering and governance - specific use-cases related to management of roles

  • Operations / data governance - management of user assignments

  • Self-service - IGA operations performed by end-users - mostly assignment of an access

  • Access certification - Business review of user access

  • Visibility and reports - providing useful IGA information from data.

The use-cases (or better user stories) are described in the linked pages.

The use-cases preparation is in progress. The preparation status is described in the last column. The state Implemented means that the use-case is already implemented in midPoint.

2.1. Role Engineering And Governance

Priority Use-case name Note Preparation status

Role creation

P1

Create application role

Prepared

P1

Create business role

Prepared

P1

Create new application

Define all roles for the new application and integrate it into IDM.

In progress

P ?

Manage new application with manual provisioning

To prepare

Role modification

P1

Modify business attributes of application role

To prepare

P1

Modify provisioning configuration of application role

When provisioning configuration is updated, then recompute of the role members is needed.

To prepare

P1

Modify content of business role

To prepare

Role decommissioning

P1

Decommission role

In progress

P1

Decommission application

To prepare

Other

Optional

Define approval policy

Good to have this in UI, but we can start without this.

To prepare

Optional

Define auto-assignment rule for specified role

Good to have this in UI, but we can start without this.

To prepare

Optional

Update/remove role auto-assignment

Good to have this in UI, but we can start without this.

To prepare

2.2. Operations / Data Governance

Priority Use-case name Note Preparation status

Single object operations

P ?

Bypass role engineering process

Create / modify / delete roles without approval

Prepared

P ?

Bypass access request process

Create / modify / delete role assignments without approval

To prepare

P ?

Recompute the role assignments

E.g. when some updates in the roles was performed

To prepare

P ?

Troubleshoot the recompute operation

To prepare

P ?

Approve/Reject request on behalf

E.g. IGA operator/Role manager in special situations.
The use-case is already implemented (see details).

Implemented

Bulk operations

P 1

Define set of users/objects for bulk operation

The set of users for bulk operations may be defined by specific query, or just by list of users.

Prepared

P ?

Update attributes / assignments for set of users

E.g. Disable/enable set of users

To prepare

P ?

Update attributes for set of roles

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

To prepare

P ?

Change approver of pending requests

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

To prepare

P ?

List and compare attributes for set of users

To prepare

P ?

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

To prepare

P ?

List and compare entitlements for set of users

To prepare

2.3. Self-service

In this section we described only self-service use cases that relates mostly to access visibility and management.

Priority Use-case name Note Preparation status

Access management

P 1

Request new access for myself / for somebody else

To prepare

P 1

Update parameters of the access

E.g. the validity period

To prepare

P 1

Remove access for myself / for somebody else

To prepare

Data visibility

P ?

What is my access ?

To prepare

P ?

Do I have access to the application "A"? Why?

Identify role that is providing me access to the application.

To prepare

P ?

What role should I request to get access to the application "A"?

To prepare

P ?

Review all my request

To prepare

P ?

Review all requests for me

To prepare

P ?

Review all my approvals

To prepare

P ?

View approval history of the request

How did I get this access ?

To prepare

P ?

View actual state of the request

Why is the request not approved yet ?

To prepare

Approvals

P ?

Approve/Reject the request

To prepare

P ?

Approve/Reject multiple requests at once

To prepare

P ?

Automatic approval if requestor is the same as approver

To prepare

P ?

Transfer all approvals to deputy

When I’m on leave, my deputy should obtain all approval cases

To prepare

End user operations

P ?

Setting somebody as deputy

To prepare

P ?

Which role is providing access to the specified application (direct / indirect) ?

NOTE: this is special case of UC Hierarchy of roles 1 - just for one role.

To prepare

P ?

What access is this role providing ?

NOTE: this is special case of UC Hierarchy of roles 2 - just for one role.

To prepare

P ?

What everything is this role doing ?

To prepare

2.4. Access Certifications

Priority Use-case name Note UCstatus

P ?

TODO

To prepare

2.5. Visibility and reports

The IGA system should provide useful IGA information from the data. Especially for external customers (auditors / security officers / business).

Priority Use-case name Note Preparation status

Reporting technology

P ?

Analyze reports in database

Exporting reports into database.

Prepared

P ?

Scheduled reports

Prepared

P ?

Specify set of objects for reports

Implemented

P ?

Option to run SQL in reports

Increase performance of reports

Prepared

Visibility of single objects

P ?

User’s history - in business readable form.

To prepare

P ?

What is the access of the user ?

To prepare

P ?

Who has access to the application and why ?

To prepare

P ?

Who are members of the role ?

To prepare

P ?

User’s history in business terminology

To prepare

Big picture over assignments

P ?

Who has access where and why ?

Main IGA report / assignments report

To prepare

P ?

Who are the privileged users ?

To prepare

P ?

Who are the highest risk users ?

To prepare

Big picture over roles

P ?

Compare roles and their attributes

Listing of roles and their specified attributes - view and compare

To prepare

P ?

Compare orgs and their attributes

Listing of ORGs and their specified attributes - view and compare

To prepare

P ?

View hierarchy of roles

Hierarchy based on inducements and role archetypes

To prepare

P ?

Role structure analysis 1: What is assigned by the roles

Report of roles and all their descendants.

To prepare

P ?

Role structure analysis 2: Where are the roles included

Report of roles and all their ancestors

To prepare

Optional

What applications can be accessed by the roles ?

To prepare

Optional

What accounts are created by the roles? / What entitlements are managed by roles?

To prepare

Optional

Identification of loops in role structure

Report

To prepare

Other big picture views and reports

P ?

Comparison of role assignments (what should be) and actual representation on managed objects (what is)

Discrepancies - on users level, attribute level - for specified attributes

To prepare

P ?

What resources we are managing ?

To prepare

P ?

What objects we are (not) managing on the particular resource

To prepare

Process monitoring reports

Optional

Monitor the role engineering process

To prepare

Optional

Monitor the access request process

To prepare

Optional

Monitor the access certification process

To prepare