Exercise 50: Governed Identities

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.

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.

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

The role catalog should look roughly like this:

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:

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.

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:

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.

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.

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.

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:

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:

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.