IGA Use Cases: Role Engineering and Governance
| 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