IGA Use Cases

Last modified 08 Sep 2022 11:24 +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

P1

Create application

…​ and define all roles for the new application.

P1

Create application resource

P1

Create application role

P1

Create business role

Other

P1

Connect application to provisioning via manual resource

P1

Simulate relation in associations

Missing feature

P2

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

P2

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

P3

Request new access for myself / for somebody else

Request role or request service + define relation

P3

Request access to application resource

Request direct access of application resource

P3

Modify parameters of the access

Validity period, or relation to resource

P3

Remove access for myself / for somebody else

Data visibility

P2

What is my access ?

P2

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

Identify assignment that is providing me access to the application.

P3

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

P4

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

P2?

Analyze reports in database

Exporting reports into database.

P1

Scheduled reports

FUTURE

Option to run SQL in reports

Increase performance of reports

Visibility of single objects

P1

Role content - in business readable form

P1

User’s history - in business readable form

P1

What is the access of the user ?

P2

Who has access to the application and why ?

P1

What is assigned by this role ?

P2

Where is this role included ?

Big picture over assignments

P1

Who has access where and why ?

Main IGA report / assignments report.
Example here.

FUTURE

Who are the high risk / privileged users ?

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

P3

Compare roles / orgs

Big picture over roles

P1

Role identification in each line of the report

P1

Hierarchy of roles - the role model

Hierarchy based on inducements.
Example here.

P2

Roles in organization units

Role assignments rules

P2

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

P1

Identification of loops in role structure

Report

Other big picture views and reports

P2

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

P2

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