IGA Use Cases: Role Engineering and Governance
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.
| For the time being, the operations over the roles are not approved or otherwise processed. The operations should be performed by IGA engineer, IGA operator or Role manager. |
1. Role creation
1.1. Create Application
- Scenario
-
Application engineer wants to start managing access to an application via IGA. He wants to create new application in IGA, define all roles for the application - to have them prepared for assignments to users.
The operation is performed by IGA administrator.
- Actors
-
Typically this operation should be performed by IGA administrator upon request of Application engineer (i.e. engineer or owner of the application that is being integrated with IGA solution), 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 may be created automatically and their attributes may be automatically updated. But, also here - the roles are to be created manually.
This use-case assumes situation, when the applications are created manually.
- User Story
-
-
IGA administrator creates the application in UI - new service object with specific archetype.
-
He fills in required attributes (name, owner, link to object in inventory) and configures inducements if the application should be assigned directly.
-
-
IGA administrator creates definitions for each application role for the application. See create application role use-case.
-
If the application was used before and some entitlements are already assigned, then IGA administrator assigns the application role to the particular users. It can be performed manually using GUI, using bulk operation or some reconciliation with the resource.
-
1.2. Create Application Resource
- Scenario
-
Application engineer wants to start managing access to an application resource via IGA. Application resource is not created automatically, but must be created manually via UI.
- Actors
-
Actors are the same as with application. This operation should be performed by IGA administrator upon request of Application engineer (i.e. engineer or owner of the application that is being integrated with IGA solution), Security officer or Role manager.
- Motivation
-
Shares on file-servers or spaces in Confluence may be managed as application resources. The application resources represent the parametric access. To avoid role explosion, the resources should be normally assigned directly with relation distinguishing level of access.
If roles are needed for better modelling of user access, then these roles are the same as application roles - they relate to the application resource instead of application. Just, the creation of application roles will not avoid role explosion.
- User story
-
Prerequisity: Application is already created.
-
IGA administrator created new application resource of specific archetype (for the application resource).
-
It would be good if IGA administrator can create application resource as a copy of existing application resource and just modify its configuration.
-
-
He fills in required attributes (name, owner) and links it to the application.
-
If needed, for inducements, he identifies the resources and defines the set of relations that will be used for the roles from the list of relations defined in MP. The relations are represented for end-users as access levels.
-
In case, when the access to application resource should be defined using roles, then the engineer creates the required application roles and links them to the application resource.
-
1.3. 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 operation is performed by IGA administrator.
The application (or application resource), that the role should be related to, is already prepared in the midPoint.
- Actors
-
Typically this operation should be performed by IGA administrator upon request of Application engineer (i.e. engineer or owner of the application that is being integrated with IGA solution), 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. For IT staff it defines all technical components required to build the access when the role is assigned.
End-users interact mostly with application roles and business roles to manage and review their access.
- User Story
-
-
IGA administrator creates in UI the application role, defines its business attributes and technical elements (e.g. inducements and construction of objects on resources). He connects the role to the application or application resource.
-
The archetype of application and application resource roles may be different.
-
It would be good if IGA administrator can create the role as a copy of existing role and just modify its configuration.
-
When defining inducements to the application, the IGA administrator should be able to define relation for the inducement.
The relation should be visible in the inducements panel. (this is missing: MID-8034)
-
-
When the role is created, the role owner is notified. He can review the role content in UI in the form understandable to him.
-
1.4. Create Business Role
- Scenario
-
Business manager or Role manager wants to organize access to multiple applications to one business role. E.g. to better represent some business position.
- Actors
-
Typically this procedure is initiated by business manager or Role manager. This operation is typically performed by IGA administrator.
- 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.
- User Story
-
-
IGA administrator creates in UI the role, defines its business attributes and selects the content (the application roles, or application resources directly.)
-
IGA administrator can start building the role as a copy of another business role and modifying the content.
-
When the role is created, the role owner is notified. He can review the role content in UI in the form understandable to him.
-
2. Other
2.1. Connect Application to Provisioning via Manual Resource
- Scenario
-
Application engineer wants to start managing access to an application via IGA. The application is managed manually via tickets in organization ITSM system. There is already manual resource in midpoint created, and it is connected to ITSM system.
This process may be used also for specific application roles, that are managed manually in the application that is otherwise managed using automatic resource. E.g. manual administrator accounts locally written in the application.
- Actors
-
As with new application - the operation is typically performed by IGA administrator.
- Motivation
-
Actually midPoint requires creation of new resource for each realisation team that will obtain tickets for manual provisioning. The creation and configuration of new resource requires engineering work of IGA engineer instead of just IGA administrator.
According to IT management processes, modification of roles and services can be included in configuration management processes. But modification of resources is definitely change management and requires more complex and therefore slower processes (e.g. formal tests and deployments). It would be good to keep adding just new application with manual tickets on configuration management level.
- User Story
-
-
IGA administrator creates new application or application role.
-
In definition of provisioning he defines realisation team and some additional information that relates to the application or application role.
-
Application (or application role) is created and can be used.
-
2.2. Simulate relation in associations
Midpoint has missing feature. Access to application (or application resource) may be modeled by assigning service representing the application directly. Relation of this assignment can describe access level (e.g. reader/editor/administrator).
The situation is described in example 2 in access modeling - Buster Blake being Editor of Space:Project X.
When such assignment of service object with relation is created, shadow of the user and its association is created. But such association does not have any representation of relation. If the user access level changes from Editor to e.g. Reader, it can’t be represented easily.
2.3. Create/modify archetype via UI
Archetypes of roles and services are crucial for good visibility and modeling of the access in organization. These archetypes are defined mostly by solution engineer, as the detail definition is not always easy and may have consequences.
IGA administrator/engineer should be able to create and modify archetypes for roles and application or application resources via UI. He should be able easily define icon, description, specify set of relations that will be used for assignment objects of such archetype.
IGA administrator should be able to assign easily archetype to new set of objects via UI (e.g. using already prepared task).
This use-case is partially possible - archetypes may be created and modified. Just modification of archetype requires more midpoint knowledge and UI should be easier to use.