IGA Use Cases: Role Engineering and Governance

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

Following use-cases are defined in the area of role engineering and governance.

The main goal of the role engineering use-cases is interconnection of technological and business layer of access management - by developing of role objects and interconnecting them to hierarchical structure. This will build the business model for management of access in the organization.

These use-cases require approval process independent of access request process.

Following actors are active in the use-cases:

  • Author - the person, who created the request for the role.

    • Application engineer is typically author of application roles.

    • Business user is typically author of business roles.

  • Role Owner - performs decisions of role modifications and assignments. It is often the application engineer for application roles and business manager for business roles.

  • IGA administrator - reviews the roles and applications definitions and verify them from the viewpoint of technical accuracy and processing details.

  • Role manager - governs the roles structure. Reviews the roles from the view of their position in the whole model and business functionality.

1. Role creation

1.1. Create application role

Scenario

Application engineer wants to start managing access to the particular role/privilege in the application via IGA solution. He wants to create new role.

The application, that the role should be related to, is already prepared in the midPoint.

Actors

Typically this operation should be performed by Application engineer (i.e. engineer or owner of the application that is being integrated with IGA solution) in cooperation with IGA administrator.

The operation may be initiated upon request of Security officer or Role manager.

Motivation

The application role is key component interconnecting business and IT world of access management. It is providing standard business description of the access to end-users. Fot IT it defines all technical components required to build the access when the role is assigned.

End-users interact with application roles and business roles to manage and review their access.

User Story
  • Requestor (typically application engineer) creates a request for a new application role. He fills in the business details and technical configuration of the role. Details here. When the role is defined according his knowledge, he passes the request to next step - for admin review.

  • IGA administrator reviews role definition in this stage. He verifies that the role is consistent with the Role model document, all components are well-defined and all related technical components are created. If specific IDM components - like new resources are being prepared, the IDM administrator acts together with IDM engineer to prepare IDM environment. If any modification is needed he modifies the role together with the requestor.
    When the role is technically verified (and configured if needed), he passes the role for approval.

  • Role manager approves the role. Role starts to be active and may be assigned.

The use-case shall work according the role engineering and maintenance lifecycle process.

1.2. Create business role

Scenario

Business manager or Role manager wants to organize access to multiple applications to one business role - to better represent some business position.

Actors

Typically this procedure is initiated by business manager or Role manager. It may be performed by business users with higher privileges - Power user, Role manager or IGA administrator.

The author of the role is typically the business user.

Motivation

Structuring of application roles to business roles enables mapping user access to organization needs and increases readability of the user access. Creation of business roles for specific projects or business tasks helps end-users find relevant roles during self-service.

Instead of creation of application role, this operation should work on business level with no or minimal technical knowledge on the side of requestor.

User Story
  • Requestor (typically business manager) creates a request for a new business role. He fills in the role attributes and selects the roles to be included in the new role. Details are described here. When the role is defined according his knowledge, he passes the request to next step - for admin review.

  • IGA administrator reviews role definition in this stage. He verifies that the role is consistent with the Role model document and all components are well-defined. If any modification is needed he modifies the role together with the requestor.
    When the role is technically verified (and configured if needed), he passes the role for approval.

  • Role manager approves the role. Role starts to be active and may be assigned.

The use-case shall work according the role engineering and maintenance lifecycle process.

1.3. Create New Application

Scenario

Application engineer wants to start managing access to an application via IGA. He needs to create new application in IGA, define all roles for the application and start using them in role definition and access request.

If the application was used previously, then the newly created application roles should be assigned to the existing users.

Actors

Typically this operation should be performed by Application engineer (i.e. engineer or owner of the application that is being integrated with IGA solution) in cooperation with IGA administrator.

The operation may be initiated upon request of Security officer or Role manager.

Motivation

When new application is deployed, or the existing application needs to be integrated with IGA solution, then the application must be created in IDM.

The application definition (as service object) and its whole lifecycle should be integrated with an organization application inventory, if such inventory exists. Then the applications should be created automatically and their attributes may automatically updated.

This use-case assumes situation, when the applications are created manually.

User Story
  • If the application object is not created in midPoint, requestor (typically Application engineer) creates it via GUI (new service).

  • Requestor creates definitions for each application role for the application. See create application role.

  • When all roles are created and approved by Role manager, the application is integrated with IGA solution.

  • If the application was used before and some objects are already assigned, then TODO

1.4. Manage new application with manual provisioning

Scenario
Actors
Motivation

When a manual provisioning resource is configured, it should be easy to define just approval workflow and not need to configure additional resource - this requires engineering work.

User story

TODO

2. Role modification

2.1. Modify business attributes of application role

Scenario
Actors
Motivation
User Story

TODO

2.2. Modify provisioning configuration of application role

Scenario
Actors
Motivation
User Story

TODO

2.3. Modify content of business role

Scenario
Actors
Motivation

Update of business role is probably the most common operation in the process.

Most often it is the addition or removal of an application role from the business role. Specific workflow may be defined for this operation. Because 2 roles are affected - the business role being modified and also the application role that will be included into the business role. Owners of both roles should approve this operation.

User Story

TODO

3. Role decommissioning

3.1. Remove role

Scenario

There may be different situations why the role needs to be deleted. E.g.:

  • Role owner of application role wants to remove the role, because the application access model is changed and the role is

  • Role owner of business role wants to remove the role, because the business function is being decommissioned.

  • Role manager performs role cleanup / organization structure is changing and the role becomes obsolete.

Actors

The operation may be performed by business people as well as aby administrators. This operation should g through normal approval process

Open question: Should we allow the operation to be performed by business people (business manager deleting business role) ?

Open question: When Role manager performs cleanup ? Should he still go through approval process ?

Motivation

Performing cleanup of the roles is necessary. When IGA solution allows easy role removal, then more clean environment is being kept.

Open question: Normally, business teams will not request for this - well, maybe we don’t need to implement role removal as a process.

User Story

TODO

3.2. Decommission application

Scenario
Actors
Motivation
User Story

TODO

4. Other

4.1. Define approval policy

Scenario
Actors
Motivation
User Story

TODO

4.2. Define auto-assignment rule for specified role

Scenario
Actors
Motivation
User Story

TODO

4.3. Update/remove role auto-assignment

Scenario
Actors
Motivation
User Story

TODO