Approvals - Design Notes
- 1. Approval concepts
- 2. Examples of approval workflows
- 3. Additional configurations
- 3.1. Approval policy - notify instead of approve
- 3.2. Approval policy - additional approval by requestee
- 3.3. Approval policy - approval by application owner
- 3.4. Approval policy - skip manager’s approval step for top management
- 3.5. Approval policy - skip manager approval for CEO
- 3.6. Approval policy - replace role owner approval if missing
- 3.7. Approval policy
- 3.8. Approval step can be sent to multiple users at once
- 3.9. Approval policy - additional approval for externist (different approval workflow for different users)
This document contains design notes for upgrade of design of approvals. It is prepared for development of version 4.9.
This version is planned to be tuned during summer 2023.
Concepts and user stories used in these documents are describing just "roles" for clarity and easier reading. The same or similar rules may be applied also for assignment of ORGs or services.
1. Approval concepts
-
Only direct assignment of role to user is being approved. Indirect assignments are not approved.
2. Examples of approval workflows
We should support following types of approval workflows.
2.1. Basic approval - with organizational structure
-
Role assignment is approved by requestee manager and owner of the role.
2.2. Basic approval - without organizational structure
-
Role assignment is approved by owner of the role
2.3. Enhanced approval - by archetype
-
Application roles - 2 approvers - user’s manager and helpdesk (e.g. for verification of licenses).
-
Business roles - 2 approvers - user’s manager and owner of the role.
This model may be enhanced by specific approval policy for specific archetypes / object types.
2.4. Risk based approach for approval.
Roles have 4 levels of risk:
| Risk level | Approvers count | Details |
|---|---|---|
0 |
no approval necessary |
user can request the role, the role is assigned and no approval is necessary |
1 |
1 approver |
the role assignment is approver by user’s manager |
2 |
2 approvers |
1st approver is user’s manager, 2nd approver is role owner (or application owner) |
3 |
3 approvers |
1st approver is user’s manager, 2nd approver is role owner (or application owner), 3rd approver is security officer |
Approval workflow will be selected by value of role risk level in the moment of the request. Level 2 is the default if the role does not have risk level defined
2.5. (Almost) No Approvals
-
All (almost all) claimable accesses are assigned upon request without any approval. Assignment of specific roles has to be approved by manager.
This design is efficient for smaller companies with higher level of trust. The preventive control is replaced by detective control (certifications and access review). This approach is more efficient but can increase risk of unauthorized users accessing sensitive data. For managing risk, specific roles with higher risk level may be approved by manager.
This concept requires additional features to be provided by midPoint:
-
midPoint provides view for manager to see who from his team requested what during specific period of time (e.g. a month)
-
both requests for assignment and unassignment
-
3. Additional configurations
3.1. Approval policy - notify instead of approve
To increase performance in organizations, some approvals may be replaced by notifications only.
See Notification instead of approval user story.
3.2. Approval policy - additional approval by requestee
When requestor is not the same as requestee, the requestee may approve that he wants to obtain the role. This should be first step of approvals
3.3. Approval policy - approval by application owner
Engineer should be able to configure approval step in a way, that it will be approved by owner of the application that is induced to the role. This relates to application roles.
3.4. Approval policy - skip manager’s approval step for top management
To unload approval request of CEO, system should configure that manager’s approval is not necessary for 1st level of managers. If they request assignment, they won’t
3.5. Approval policy - skip manager approval for CEO
If there is manager’s approval and user does not have manager (e.g. CEO), then the manager approval step should be skipped
3.6. Approval policy - replace role owner approval if missing
If role does not have owner defined, specific user (e.g. Security officer) may be selected automatically
3.7. Approval policy
If role is parametric, then put to the first/last/n-th step approval by specific person (e.g. app admin), who defines parametric value of the request. He/she can also reject the request.
3.8. Approval step can be sent to multiple users at once
Claimable or not claimable. All must approve, 1 must approve.
TODO: Add link to performance issue with claiming of requests.
3.9. Approval policy - additional approval for externist (different approval workflow for different users)
If the user is externist, add additional approval step by manager of the externists