IGA Use Cases

Last modified 09 May 2023 16:43 +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. Use-cases in following areas are described:

  • 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.

2.1. Role Engineering And Governance

Priority Use-case name Note

Role creation


Create application

…​ and define all roles for the new application.


Create application resource


Create application role


Create business role



Connect application to provisioning via manual resource


Simulate relation in associations

Missing feature


Create/modify archetype via UI

Better UI

Additional use-cases listed below were considered in this area. They relate to role engineering process or some other events. They will be part of FUTURE works.

  1. Modify business attributes of application role

  2. Modify provisioning configuration of application role (When provisioning configuration is updated, then recompute of the role members is needed.)

  3. Modify content of business role

  4. Decommission role

  5. Decommission application

  6. Define approval policy (UI updates)

  7. Define auto-assignment rule for specified role (UI updates)

  8. Update/remove role auto-assignment (UI updates)

2.2. Operations / data governance

Priority Use-case name Note

Bulk operations


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.

Additional use-cases listed below were considered in this area.They will be part of FUTURE works.

  1. Bypass role engineering process - this will be in plan when the role engineering process will be implemented.

  2. Bypass access request process - possible already

  3. Recompute the role assignments

  4. Troubleshoot the recompute operation

  5. Approve/Reject request on behalf - already implemented in some way

2.3. Self-service

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

Priority Use-case name Note

Access management


Request new access for myself / for somebody else

Request role or request service + define relation


Request access to application resource

Request direct access of application resource


Modify parameters of the access

Validity period, or relation to resource


Remove access for myself / for somebody else

Data visibility


What is my access ?


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

Identify assignment that is providing me access to the application.


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

Role catalog organized by applications.

Additional use-cases listed below were considered in this area. They will be part of FUTURE works.

  1. Review all my request

  2. Review all requests for me

  3. Review all my approvals

  4. View approval history of the request

  5. View actual state of the request

  6. Approve/Reject the request

  7. Approve/Reject multiple requests at once

  8. Automatic approval if requestor is the same as approver

  9. Transfer all approvals to deputy (When I’m on leave, my deputy should obtain all approval cases)

  10. Setting somebody as deputy

2.4. Access Certifications

Priority Use-case name Note


All user assignments should be displayed in certification.

Also in business terminology - "access to application".

2.5. Visibility and reports

The IGA system should provide useful IGA information from the data. In the form that is readable by the users - in the "language" they speak and can easily understand.

We can expect that the users such as helpdesk operators, auditors, security officers, or application engineers that use midPoint roles for managing access to their applications may have knowledge about identity management, provisioning, roles or technology infrastructure, but specific midpoint terminology may confuse them.

Priority Use-case name Note

Reporting technology


Analyze reports in database

Exporting reports into database.


Scheduled reports


Option to run SQL in reports

Increase performance of reports

Visibility of single objects


Role content - in business readable form


User’s history - in business readable form


What is the access of the user ?


Who has access to the application and why ?


What is assigned by this role ?


Where is this role included ?

Big picture over assignments


Who has access to what and why ?

Main IGA report / assignments report.
Example here.


Who are the high risk / privileged users ?

This use-case needs more detail work. Will be developer later.


Compare roles / orgs

Big picture over roles


Role identification in each line of the report


Hierarchy of roles - the role model

Hierarchy based on inducements.
Example here.


Roles in organization units

Role assignments rules


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


Identification of loops in role structure


Other big picture views and reports


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


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

Was this page helpful?
Thanks for your feedback