IGA Use Cases: Self-service
1. Access management
1.1. Request access for myself / for somebody else
End user needs to obtain access to some application. He can choose role that is giving access for him, or he even can select application (represented by service object) - if the application is requestable.
When the user selects access to application, he must define access level - represented by relation in midPoint.
| User can choose only from relations defined for the specific role/service archetype (via <assignmentRelation>) |
- User story
-
-
User request access. Select whether he want to obtain access for himself/herself or for somebody else.
-
Then selects the application (service), or selects role.
-
When the role is selected, then he selects relation and requests the access.
-
- Status in 4.6
-
This is not implemented in standard "Request access dialog" in 4.6 (build: v4.6devel-1160-g65c050a8d4) because:
-
Services can’t be selected in the dialog.
-
Relation is selected prior service - so limitation of relation based on archetype of selected service can’t be implemented.
Still, there is possibility to select the service, but using administrative UI: User/Assignments/Service/New assignment.
-
1.2. Request access to application resource
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.
Access to application resources requires selection of not only the application resource, but also setting of relation to the app. resource. The list of application resources may be large and end-user may not know he must define relation.
The relation is displayed to user as access level. The list of relations must be specific to particular application resource role archetype.
| User can choose only from relations defined for the specific role/service archetype (via <assignmentRelation>) |
This use-case describes request for direct assignment of application resource. In this request, the user must select requested access level for the application resource. If there are application roles defined for the app. resource, then the access request is standard.
- User story
-
-
While requesting access to application resource, the user selects application resource role (probably from list of application resource roles for specific application he has chosen prior).
-
Then the user select access level (relation) from the list of predefined access levels for the application resource.
-
- Status in 4.6
-
This is not implemented in standard "Request access dialog" in 4.6 (build: v4.6devel-1160-g65c050a8d4) because:
-
Services can’t be selected in the dialog.
-
Relation is selected prior service - so limitation of relation based on archetype of selected service can’t be implemented.
Still, there is possibility to select the service, but using administrative UI: User/Assignments/Service/New assignment.
-
1.3. Modify parameters of the access
End user wants to modify parameters of an assignment. Typically he needs to increase validity period (even when the assignment expired) or modify access level (e.g. when he has READER access level and wants to have EDITOR).
- User story
-
-
User opens his accesses and select particular access (assignment of role or service)
-
User modify parameters of the access and sends the request for approval.
-
Standard approval process is started.
-
- Status in 4.6
-
In self-service UI in 4.6 (build: v4.6devel-1160-g65c050a8d4) is the operation possible via Profile/Assignments page. But only modification of Activation is possible. No option to modify relation.
Relation may be changed by removal of existing assignment and requesting new one with different relation. This is not straightforward as it could be for end user. If possible, this
| Starting of approval process after this modification was not tested - please test. |
2. Data visibility
2.1. What is my access ?
End user wants to know where everywhere he has access. "Where" means applications and application resources.
He should be able to see list of all services (midPoint representation of application and application resources) where he has access.
- User story
-
Two possible options:
-
End user open list of all his assignments (both direct and indirect) and can filter it to applications and application resources, or
-
end user opens panel "application access" with view where all direct and indirect assignments of services (applications and application resources) are listed.
-
End user should see in the view also additional information:
-
the relation represented as access level, and
-
role, via which the service was assigned or information, that the role was assigned directly
There may be hundreds of application assignments. End user should be able to order or search the application list.
- Status in 4.6
-
The use-case is not implemented in default MP configuration, but it may be configured in MP as definition of custom panel for user (not tested yet). (MP build: v4.6devel-1160-g65c050a8d4)
The search is not usable for end-users. In end-user UI should use probably fulltext search, or some modification of basic search where he can just write name of the service (not selecting relations).
2.2. Do I have access to the application "A"? Why?
End user needs to identify role that is providing me access to the application.
To answer "why he has the access", end user should be able to open assignment and see the role (if the assignment is indirect) or request by which he obtained the role.
- User story
-
-
End user can open panel "application resources" (mentioned in previous use-case) and search for the application.
-
He can see information in the view, or additional information in assignment details.
-
- Status in 4.6
-
Same as in previous use-case.
2.3. What role should I request to get access to the application "A"?
End-user needs to obtain access to application "A" to perform his/her work. He/she does not know what roles are defined for the specific application, but he can have a look and decide.
End user must be able to browse through role catalog organized by application. When he chooses application he open all roles related to that application (or application resource) and choose the specific role by information in description or so.
- Use-case
-
-
End-user opens role-catalog, and:
-
switches to the view by application, or
-
filters the view just to roles and application (and application resources) that relates to the specific application
-
-
end-user reviews the roles related to the application and selects one that suits his needs.
-
Note: end-user may request application or application resource directly (if the services are requestable).
-
-
- Status in 4.6
-
The view of role catalog is not visible in end-user UI in independent view but is accessible in access request process. This place for displaying of the role catalog for end-users is good enough.
But, the use-case is not supported in 4.6 (build: v4.6devel-1160-g65c050a8d4), because the role catalog can’t be organized by applications.