Self-Service: Request access rights
Self-Service: Request access rights
Self-Service: Request access rights
This use case is part of access right management (ARM) process and in this article is described detailed use case for how end-users are able to request access rights from Matrix42 Self-Service. This article also contains information how use case is configured and examples how customer is able to expand it.
When the use case is delivered, it contains three (3) possibilities to request access rights,
1. Request access rights to myself (available to all end-users)
2. Request access rights to my subordinate (available to managers)
3. Request access rights to external users (available to managers)
Please notice, that IGA packages (Starter, Growth, Enterprise) has affect to the use case and relating functionalities such as user lifecycle management, toxic combinations, etc.
Use case in nutshell,
1. Manager or user requests access rights from Matrix42 Self-Service
2. Approver(s) approves request(s) in the Matrix42 Self-Service
3. Access right(s) are automatically added to user or manual request is sent for adding the access right(s) manully
4. Manager and user can see their own request history from Matrix42 Self-Service
5. IGA Admin can manage access right information, request catalog and visibility for the access rights which are published into Matrix42 Self-Service from IGA solution.
6. All auditing details are available for reporting (by using ready-made reports and dashboards or IGA admins can easily create own reports)
Use case description
This use case can also related to other processes and use cases, which has been marked
* User lifecycle management
**Governance
***Automation & provisioning
****Expanded access right management
| Description | |
Overview |
This use case describes how user can request additional entitlements or business roles and what are outcomes for that request. User and manager can request additional entitlements or business roles for him/herself (request access rights). Manager can request additional entitlements or business roles for subordinate or for external subordinate (request access rights for my subordinates or request access rights for external users) |
Operators |
IGA solution |
Prerequisites |
Access rights needs to be published to Self-Service. Manager - subordinate relations needs to be existing in IGA solution. |
Result |
The request is appropriately approved and send to provisioning process. All audit details are saved and can be reported. User and manager can follow up request status in Self-Service. |
Operating chain |
|
Self-Service |
Request access rights for myself If user lifecycle management add-on is included, request access right service can also be shown in "onboard internal users" and "onboard external users" bundle orders. |
| Self-Service reporting |
User can see own active access rights Manager can see own and subordinates active access rights User can see own open requests Manager can see own open requests Manager can see request waiting for approval Approver can see request waiting for approval Approver can see own approval history User can see own request history Manager can see own request and approval history |
| IGA admin reporting |
IGA admin can create new reports, views and dashboards or they can review, update and remove ready-made views, reports and dashboards. IGA admin can also decide if only active requests are reported, or is also history data included,
|
| IGA admin actions |
|
Messages |
User can see own open requests and their status, and request history from Matrix42 Self-Service portal, so it is highly recommended that email notifications are added to IGA solution in further development phase and try to guide users to portal at the first phase. Email notifications can be also added by IGA Admin. |
Delete
Expansion possibilities
Expansion possibilities are categorized in three category, but it is always important to validate if requested change has affect to the delivery schedule or work estimations.
| Category | Description |
|
Small (less than hour) |
Small changes does not usually affect to the delivery schedule or work estimations and these changes can be done also by IGA admins,
|
|
Medium (0,5 - 2 work days) |
Medium changes can be for example,
|
|
Large (more than 2 work days) |
Large changes usually takes longer time, since they require more detailed definition-, and testing work. Those can be for example,
|
Relations & configuration instructions
Relations to other use cases,
Manage entitlements - use case for IGA admins to be able to define different settings to single access right group (entitlement), such as approvers, visibility in Self-Service, description etc.
Manage applications - entitlement needs to always be related to application, so its highly recommended to create manually or import customers application list to IGA solution.
Manage request catalog - users to be able request access rights from Self-Service, IGA admin needs to build categories for the request catalog.
Approval - use case for different approval types.
Delegation - use case for delegating approval responsibilities to other users.
Provisioning - is used when group memberships are created.
Manage admin tasks - use case for IGA admins to be able to get notifications in case there is a need for manual actions.
Audits and reports - ready-made reports and dashboards for monitoring access right requests.
Relations to other data cards,
IGA Service Request
IGA Identity Storage*
IGA Work Period*
IGA Entitlement
IGA Business Role
IGA Access Right Record
IGA Account
IGA Toxic Combinations**
Configuration instructions:
- Publish service "Request Access Right for Subordinate" in ESS
- Publish service "Request Access Rights for External Users" in ESS
- Publish service "Request Access Rights for Myself" in ESS
- Configure EPEtask called "[Directory] IGA Service request: Verify, Add, Remove"
- Configure the connection settings and after that Test connection from the EPEtask
- Define user and group filters and settings
- No need to change user identity mappings
- Configure EPEtask called "[Directory] IGA Access Right Record: Remove or Add group"
- Configure the connection settings and after that Test connection from the EPEtask
- Define user and group filters and settings
- No need to change user identity mappings
- Go to IGA Access right record and workflow called "1.0 Access right ending"
- Publish the workflow
- Publish the workflow
- Go to IGA Access right record and workflow called "2.0 Add or remove group membership"
- Publish the worklfow
- Publish the worklfow
- Go to IGA service request and workflow called "2.0 Manager Adds Rights to Others Workflow"
- Publish the workflow
- Publish the workflow
- Go to IGA service request and workflow called "2.3 Users Add Rights for Themselves"
- Publish the workflow
Unit testing instructions:
- Test Request Access right services from ESS
- Create IGA request catalog and entitlements and publish them into Self-Service
- Create test users with work period(s), both manager and user level.
- Create subordinates to the manager and make sure that manager information can be found from work periods.
- Create test request, both manual and automatic type
- Check the IGA Service Request from ESM
- If automatic, check the group memberships from the Directory that new group is added to the user
- If manual, check that IGA Admin Task is created to correct support group
- If you are working with an environment where user can have multiple work periods:
- Request the same entitlement from ESS for two (or more) different work periods that the user has
- Check that an active access right record for each work period is created
System and user approval testing instructions
In this chapter are described preparations tasks and testing instructions for system testing and user approval testing phases.
Preparation tasks for both phases
1. Manage entitlements, manage request catalog, manage IGA users and approval related test cases are successfully tested and preparation tasks are implemented (same test users are used for testing access right requests and approvals).
2. Test users are created and there are existing manager - subordinate relations
Testing instructions,
| Test case | Testing steps | Outcomes |
| Request access rights for yourself (login as user) | ||
| Request manual and automatic provisioning type of entitlements | ||
| Request business roles | ||
| Check that status is updated correctly in the front page after declining or approving the request (notice polling time) | ||
| Check that My requests is showing request history correctly | ||
| Request access rights for your subordinate and approve requests made by your subordinate (login to Self-Service as manager) | ||
Approve requests waiting for approval |
||
Decline some of the requests waiting for approval |
||
Request automatic and manual provisioning type of entitlements |
||
| Request business roles | ||
| Check that status is updated correctly in the front page after declining or approving the request (notice polling time) | ||
| Check that approvals is showing request history correctly | ||
Request access rights for your external subordinates (login to Self-Service as manager) |
||
Request automatic and manual provisioning type of entitlements |
||
Request business roles |
||
Approve access right requests (login to Self-Service as entitlement or business role approver) |
||
Approve requests waiting for approval |
||
Decline requests waiting for approval |
||
Check that request status is updated correctly in the front page after declining or approving the request (notice polling time) |
||
Check that approval history is showing correctly |
||
| Login to IGA solution as IGA admin | ||
| Validate that IGA service request is created correctly | ||
| Validate from the directory that group-membership connection is made correctly | ||
| Validate that reports, dashboards and views are showing auditing details correctly | ||
| Validate that entitlement data card is showing group-membership connection correctly | ||
| Validate that users IGA account data card is showing group-membership connection correctly | ||
| Validate that manual access right requests are created correctly (either IGA admin task generated to the support group or email sent for manual actions) |
Table of Contents