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

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

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

Other

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.

Modify business attributes of application role
Modify provisioning configuration of application role (When provisioning configuration is updated, then recompute of the role members is needed.)
Modify content of business role
Decommission role
Decommission application
Define approval policy (UI updates)
Define auto-assignment rule for specified role (UI updates)
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.

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.

Bypass role engineering process - this will be in plan when the role engineering process will be implemented.
Bypass access request process - possible already
Recompute the role assignments
Troubleshoot the recompute operation
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.

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.

Review all my request
Review all requests for me
Review all my approvals
View approval history of the request
View actual state of the request
Approve/Reject the request
Approve/Reject multiple requests at once
Automatic approval if requestor is the same as approver
Transfer all approvals to deputy (When I’m on leave, my deputy should obtain all approval cases)
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".

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
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 to what 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

Priority

Use-case name

Note

Reporting technology

P2?

Analyze reports in database

Exporting reports into database.

Scheduled reports

FUTURE

Option to run SQL in reports

Increase performance of reports

Visibility of single objects