Exercise 50: Governed Identities

Book referenceUnwritten chapters
Training referenceMID-102, Governance (planned)


Apply complex governance rules on identity population: policies, multi-stage approvals, SoD, ...


  • HR System: Employee data are stored in the HR system. There is an export task that exports the content of an HR system into a CSV file in regular interval. This HR system is smart and it maintains full information about organizational structure.

  • Open source LDAP server (OpenLDAP, 389ds or similar): Company-wide LDAP server that is used as central user directory and authentication server for several applications. Accounts should be provisioned into the LDAP server using the standard inetOrgPerson object class. This LDAP server has flat structure, e.g. all accounts are in ou=People,dc=example,dc=com.

  • Addressbook application is written on top of LDAP directory. The application allows to browse employee LDAP accounts, search for a specific contact and retrieve e-mail addresses and telephone numbers. Addressbook application is using the content of LDAP server both as a data and as account database. Access to addressbook application is controlled by membership in LDAP groups: cn=addressbook,ou=Groups,dc=example,dc=com for ordinary users and cn=addressbook-admin,ou=Groups,dc=example,dc=com for addressbook administrators.

  • CRM: Database-based CRM application. Accounts should be provisioned in the database table. See create-table-crm.sql file. There are some pre-existing accounts, including some rogue accounts.

  • MidPoint: Start the exercise with an empty midPoint server. Alternatively you may start with a configuration from previous exercises.


We have a mid-size company. It is no longer sufficient to manage the identities. We want to apply identity governance principles.

Basic Principles

Archetypes should be applied wherever it makes sense. There should be archetypes for employees, external workers, business role, project, functional organizational units and so on. Archetypes should use proper assignment relation definitions that constraint applicability of archetypes and archetyped object only to cases where it makes sense.

Do not repeat yourself. Keep copy&paste to the very minimum. Try to reuse the code and configuration as much as possible. Use the opportunity to specify policies in archetypes and meta-roles. Use function libraries to avoid code duplication.

Apply least privilege principle. Limit privileges of all users to the necessary minimum. Use fine-grained authorizations and user interface customization mechanisms to their full potential. Apply global policy rules in situations where a policy needs to be consistently applied to the whole system.

Synchronization and Provisioning

We have a simple HR system that exports the data to an CSV file. All the current employees are recorded in the HR system. The HR system also exports organizational structure in CSV files. Each organizational unit has an (immutable) identifier. It also has an identifier of a parent organizational unit.

There is also an LDAP server that works as central directory server. Many applications are configured to authenticate at this server using LDAP protocol. LDAP server has a flat structure, storing all accounts in ou=People,dc=example,dc=com suffix.

Set up a synchronization task to pull the data from HR CSV files automatically. Both organizational structure and employees should be synchronized to midPoint. Employees should be properly assigned to organizational units in midPoint. Users and orgs in midPoint should be fully populated.

Set up automatic provisioning to LDAP server, based on organizational structure and job code roles. This includes LDAP groups for organizational units and job roles. Use an approach similar to the preview exercise of your choice.

All active employees should have access to addressbook application.

Connect the CRM resource to midPoint (e.g. use DatabaseTable connector). CRM is an "outbound" resource. Use the setup similar to Exercise 4.

Former employees has to be kept in midPoint, but they should not be exposed to ordinary users. Design an appropriate way how to deal with identities of former employees, e.g. separate org, activation, lifecycle state, etc. Ordinary (non-administrator) users should not be able to access data about former employees.

All synchronization and provisioning processes should be completely automatic. No administrator intervention should be required.

Role Request and Approval

Organize roles in a role catalog. Role catalog should contain at least two role categories:

  • Application roles that are related to a single application. Such as addressbook administrator or CRM auditor. This part of role catalog should be organized by application. Make sure that appropriate archetype is applied to the application "categories" (see below).

  • Business roles that span several applications. Such as sales agent or customer support leader.

The role catalog should look roughly like this:

  • Application Roles

    • Directory Service (archetype: application)

      • Directory Service Administrator (archetype: application role)

      • Directory Service Backup Operator (archetype: application role)

      • …​

    • Addressbook (archetype: application)

      • Addressbook Administrator (archetype: application role)

      • …​

    • CRM (archetype: application)

      • CRM Administrator (archetype: application role)

      • CRM Auditor (archetype: application role)

      • …​

  • Business Roles

    • Sales agent (archetype: business role)

    • Marketing specialist (archetype: business role)

    • …​

Make sure that appropriate archetypes are used on all levels of the role catalog. Please note, that the roles are sorted by application and not necessarily by resource. For example there is no resource for the addressbook application. But we still want to see that application in our role catalog.

Allow employees to request roles using a self-service capabilities of midPoint user interface. Make sure that employees can log into midPoint and request the roles from the catalog. The interaction should be intuitive and fool proof. E.g. users should not see any role in the catalog that the user cannot request. Mind the least privilege principle. Pay attention to set up the authorization in a robust way. Make sure that roles cannot be requested in any way. Some users may have access to other parts of midPoint user interface such as user details or role details. Make sure that such users cannot abuse this privilege to request a role that is not available in the role catalog, e.g. by using the assignments tab of user details page.

Not all the application roles are requestable. There may be application roles that cannot be requested by users. We still want to place such roles into the role catalog. But we do not want to display those roles to employees when they browse the catalog, looking for a role to request.

Requested roles are not assigned immediately. The request should be driven through a multi-stage approval process. The process has following stages:

Stage Approver Description Escalate to


Manager (functional)

Follow functional organizational structure to find user’s manager. Skip organizational units that do not have a manager. E.g. if user’s organizational unit does not have a manager, manager of a higher organization unit should be used as an approver.

Functional manager of the manager that was the original approver.


Role approver or application owner

If a business role is requested, then approver of business role should approve. If an application role is requested, then owner of the application in which the role belongs should approve.

Manager of IT Department organizational unit.

3 (optional)

Security office

Some sensitive roles should be approved by any member of security office.

Manager of Security Department organizational unit.

Role stages should be executed sequentially (not in parallel). Any decision that denies the request at any stage is understood as a final deny. E.g. if user’s manager denies the request then we do not want to bother role approver or security officer. In case that there are more managers, more approvers/owners or more security officers then any of them can decide independently. E.g. if a role has several approvers, the approver that makes a first decision matters. If any of the approvers approves the request, the request continues with the next stage. If any of the approvers denies the request, the the request is denied.

Applications have owners, but individual application roles do not have explicit owners or approvers. We do not want to store the owner relation for application roles as that can be a maintenance problem. If an application role is requested, the approval policy should dynamically determine the approvers by looking at the application.

Last approval step is applied only to some roles. Some roles are sensitive. We want to get an approval of a security office to these roles. We do not want to hardcode a specific name of a security officer in the policy. We want any member of Information Security Office to be approver of these roles.

But how do we know which roles are sensitive? We want to create a special meta-role that will be used to mark security-sensitive roles. We want to assign this meta-role in a very convenient way in midPoint user interface. We want to apply this policy to a role by clicking on a single checkbox. Therefore this meta-role should be configured as a "user friendly policy" in the user interface.

All approval stages should include an escalation scheme. If the original approver does not make a decision in a specified time limit, then the request is escalated. Escalation scheme is different for each approval stage.

Please note, that not all the roles are placed in role catalog. There are special non-requestable roles such as Superuser. There are roles that are designed for automatic assignment only. There are roles that should be manually assigned by system administrator.

There are also roles that can be assigned in two ways: they may be assigned automatically, and they may be assigned manually by system administrator. Make sure that those two methods will not get mixed. If a role is assigned by administrator then the assignment should stay until administrator unassigns it. The role may be assigned and unassigned automatically in the meantime. But even if there is a reason to unassign the role automatically, it should still remain assigned until administrator unassigns it.

Delegated Administration And Deputies

Set a delegated administration configuration for organizational unit managers. The managers should be able to log in to midPoint user interface and access selected pages of administration part of midPoint user interface:

  • Managers should be able to see Organizational Structure page. They should have read-only access. Managers should see all organizational units in functional organization tree.

  • Managers should be able to read users in organizational units that they are managing. Some properties from user profile should not be accessible to managers. Managers should be able to set some user proprties of the users that belog the their units. E.g. managers should be able to modify the costCenter property.

  • Managers should be able to access All users page (user list). But they should be able to see only the users that belong to their organizational units. In a similar way managers should be able to access Employees and Active employees views. Managers should not be able to get any data about former employees.

Employees tend to take vacation from time to time. There is no universal system of redundancy of responsibilities in the company. Some persons are single points of failure in company processes. We do not want to stop the business when such a person goes to vacation. The decision was to implement a possibility to delegate ad-hoc deputies for such people. However, we do not want to grant this ability to anyone. Therefore, setup a reasonable system of deputies. Design a role that gives ability to grant deputies. Make that role requestable, but mark it as sensitive which enforces approval by security office. Limit the rights that are delegable by using the deputy mechanism.

Governance Policies

We want to make sure that executive roles and controlling roles are segregated. I.e. there must not be a single person that holds both an executive role and an executive role at the same time. Therefore we need a segregation of duties (SoD) policy. Figure a way how to mark roles and organizational units as executive and controlling. You can you any mechanism (meta-roles, orgs, etc.) as long as you stick the do not repeat yourself principle. The classification of roles to executive/controlling must be easy to do. E.g. in case that meta-roles are used they should be set up as "user-friendly policies" that are easy to assign in GUI.

Role request process is an efficient tool to assign the roles. But we need a different method to remove role assignments that are no longer needed. Therefore set up an annual role re-certification campaign. All roles that were assigned by using the role-and-approval process should be subject of the re-certification campaign. The roles that were assigned automatically should not be re-certified. It makes little sense to overload one person with re-certification decisions. Therefore distribute the re-certification work to managers of functional organizational units. Schedule the campain for two weeks and to automatically repeat on annual basis.

Annual re-certification is an efficient tool, but we cannot wait several months with some decisions. For example, if an employee is moved to a new organizational unit, manager of that unit is assuming responsibility for actions of that employee. The employee can have any number of roles assigned by using the role-and-approval process. Therefore the new manager should re-certify role assignments immediatly after change in organizational unit. Set up such ad-hoc re-certification process.

Our company is required by regulations to keep data about former employees for 5 years. Therefore make sure that data about old employees are not deleted immediately when they leave, but that the data remain in midPoint. Also make sure that the data are deleted after 5 years, as after that time we have no legal basis to keep the data. For the purpose of this exercise delete old employees by using a custom scheduled bulk task.

Our company is not all work, there is also some fun. The employees have decided to play darts. There are four darts teams and there is a company-wide competition that is taken very seriously. Set up the four darts teams as orgs in midPoint (apply appropriate archetype). Let employees request membership in a particular team. The request should be approved by current dart team leader. We want people to jump ship and change the team at any time. But we do not want anyone to be a member of more than one team. Therefore make sure that the membership in the old team is automatically cancelled when an employee becomes member of another team.

Role Management Policies

Our company is changing all the time. As the company changes, role structure has to change as well. The company has grown beyond the point that role structure maintenance can be done by a single person. There is a class of employees that are responsible for maintenance of business roles. Set up a new roles that allow employees to create and change business roles. However, we cannot trust these employees completely, that would not be a good security practice. Therefore we want to drive all changes in business roles through an approval process. Security office has to approve all changes in business roles before they are applied.

Make sure that the employees cannot delete business roles, they can only mark them as archived. Set up a custom scheduled task that deletes unused archived roles, but only in case that they are archived for more than 3 years. Make sure that those roles are unused (not assigned to any user and not part of any other role). For the purposes of this exercise create a bulk task that is using Groovy script to process the roles.

We also want to delegate creation of application roles. Create a role that will allow to suggest creation of a new application role. In that case application owner has to approve creation of application role before the request is routed to security office. I.e. we neet a two-stage process for application roles: 1. approval by application owner, 2. approval by security office. Such delegated administrators cannot suggest modification or deletion of application roles. Only application owner can do that.

User Interface Customization

Default midPoint user interface is nice, but we want to use the user interface to its full potential. Therefore customize the user interface to better suit our needs:

  • Make sure there are views for all the meaningful archetypes. We want to see entries such as Employees and Business roles in the menu. We want to be able to click on them to set list of employees, to click on Create button to create an employee and so on. Make sure that archetypes are used in the user interface to their full potential.

  • We want more views still. For example we want to see Active Employees view. We want to see Archived roles view, Disabled users may be useful and so on. Please setup a handful of such useful views. Have a look at the columns in the tables that lists objects. There is certainly a room for improvement. Not all the default columns make sense, therefore remove them. And there may be need for some additional columns. For example, it would be nice to see disable reason and timestamp in the Disable users view.

  • MidPoint user interface automatically does some data validation. But we want more. We want to automatically validate correct format of telephone number and e-mail address. Allow only those telephone number that are in correct international notation (starting with + sign).

  • Configure full text search capability. Our deployment is not huge and we want to have the comfort of full text searches.

  • Set up custom links on user dashboard. For example change List users to List employees and replace List resources to something that is more meaningful for end users.

In addition to that there is one very special requirement. The game of darts is taken very seriously in our company and there is a lot of rivalry. Every few months there is a company-wide championship and the winning team takes possession of Golden Dart Cup. But there is also an individual award. The title of Master of Darts is awarded to the person with highest individual score. The employees insist that this title should be clearly visible in the IDM system. Therefore we have to do several things:

  • Create a custom extension properties for dart championship. Each user should have a property that indicates whether she or he is the Master of Darts. We also want timestamp that tells when the person won the championship for the last time.

  • We need to customize the summary panel in user details page. The panel should clearly state that a particular user is current the champion.

  • We need a custom task that awards the the master title to a particular user. The task should make sure that only one champion. The task should reset the champion flag of the previous champion and update timestamps accordingly. As administrator cannot be bothered to adjust task parameters all the time, we want an ability to execute this task from the context menu of user list. Therefore administrator will go to the user list and execute the task from the menu.

Additional Tasks

We had a security incident! There is a risk that password encryption keys have been compromised. We have to change the key and re-encrypt all passwords with new key.