IGA Design Concepts

Last modified 08 Mar 2022 10:05 +01:00
WORK IN PROGRESS

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

Applications

Applications are basic building blocks for defining access. These objects contain business information. Application is an administrative object describing application as a business target that the access definition (the role) relates to. The lifecycle of applications should be interconnected with application inventory.

Application roles

Application roles are basic roles. They are related to applications. The application roles are integrating technical components for creation of user access with business description of the access. Business users are working with business description from the application roles, IDM system and IDM administrators are working with technical definitions.

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.

Business roles

Business roles are collections of application and other business roles . Business roles should be fully readable by business people.

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

One request is processing assignment/removal/modification of one role

This will decrease complexity of the role request approval, management and troubleshooting. On contrary, it will (significantly) increase number of individual notification and approval steps. As a countermeasure, UI must provide means for easy/fast review of multiple requests on one page and multiple request approval.

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.