Misc IGA Design Notes
TODO For Discussion
These things need to further discussed:
-
End-to-end request tracking. Track request from the shopping cart (e.g. how the roles were selected), all the way to the finish of the last provisioning operation (e.g. manual operation).
-
Manual provisioning, roles, and work processes. E.g. assigning a group on manual resource. How do we construct application role for such resource?
Concepts For Discussion
The concepts are defined to have rules that will lead us to make the IGA deployment not only manageable by skilled IDM personnel, but - and this is even more important - also readable by business people. The IDM system serves the business, so it must be clearly readable by business people in business terminology.
Midpoint is very flexible. This flexibility enables multiple ways of solving the problems - and generates complexity. The concepts also help to decrease complexity of the solution and increase its readability by business.
Access Design
- Application role definition contains all components needed for access
-
The application role should contain all components needed for the role assignment. If the role contains rules for automatic assignment, even assignment of the role to the users.
- Shallow hierarchy of roles
-
Business roles can contain other business roles, but too deep hierarchy may decrease readability and increase maintenance costs. Avoid using more than 3 levels of roles in hierarchy (application role in business role in business role).
- Role model
-
At least basic business architecture of the roles, role assignments, naming conventions and integration principles should be prepared for each IGA deployment. This architecture is referenced as Role model document or
Role model. - Role assignments
-
Following role assignments may be used:
-
application role → user
-
application role → business role → user
-
application role → business role → organization unit → user
Each type may be used based on business need. The organization using business roles or even business roles assigned to organization units is preferred over direct assignments of application roles to users.
-
- Minimize number of levels for role structure
-
To keep the environment manageable and readable it is important to keep the structure of roles flat. Ideally just 1 level where business roles contain application roles. These business roles are assigned to users directly, via organization units that the users are members.
It is important that the structure of the roles is readable to business people using midpoint - therefore, usage of metaroles that are not visible to users via GUI is not recommended.
- Organization units vs roles
-
Even though OUs and roles are basically the same in MP, it should be strictly separated for business users, to decrease confusion.
On the other hand, roles may be assigned to OU and through it to its members - this concept is quite natural and understandable.
Role Engineering and Maintenance Process
- The process is governed by Role manager
-
The task of the Role manager in this process is the coordination of the application role design. Often it is needed to correct the naming, description of the roles or other business components, to have the new roles in line with the role model. The Role manager, or IGA administrator, who is processing the request, should be able to align the requirements of the application owner or administrator (the requester) with the role model and technical options and find the best application role design for the application.
- Differences in the process between application and business roles
-
The processes of role engineering for application roles, business roles and IT roles, are slightly different. The difference is based on complexity of the roles and involved actors. Application roles are more technical and their definition is much more complex. On contrary, the definition of business role is much easier and may be performed by business users.
- Differences in user interface between application and business roles
-
Business role definition uses different - easier - user interface.
- Avoid time constrains in role definitions
-
To keep environment clear and readable it is good to use time constrains only in assignments. Roles have their lifecycles. The lifecycle stages are managed by IGA personnel and adding time constrains on this level would increase complexity unnecessarily.
Access Request Process
- Requests are created via self-service UI and related REST calls only
-
Admin interface operations should not generate requests. IDM administrators manage multiple users. Their work is to perform large cleanups and modifications. Of course, cases for manual operations will be generated even based on such operations.
- Access request process supports delegated administration
-
Roles can be requested by the user for himself/herself, or for somebody else. Specific privileges will be needed for this. This feature allows management of access for whole team.