MidPoint Authorization Configuration

Each operation is actually authorized twice when it goes through the IDM Model component:

The important aspect to understand authorization is to understand what happens between these two authorizations. The Clockwork and Projector page explains the details. But simply speaking the object values are recomputed, mappings are evaluated and policies applied. Let’s explain that using an example. Let’s assume we have a user which has one LDAP account. User properties givenName and familyName are mapped to LDAP attributes givenName and sn respectively. This mapping is implemented by simple outbound mappings. If the familyName of a user is changed in GUI then this change is also mapped to the LDAP sn attribute and this is changed as well. But how about authorizations? We want to give user the ability to change the family name in the user object. This happens from time to time, e.g. when people get married. But we do not want to give the user direct access to LDAP accounts. We want to keep these accounts strictly controlled using midPoint policies, and we do not want users to mess them up with manual changes. Luckily this is what midPoint authorization model was designed for. We need just few authorizations to implement this. Firstly the request phase authorization needs to allow user to change the familyName of user object. This is simple:

Secondly we need an execution phase authorization to allow this operation to be executed:

And we also need a third authorization. Changing the familyName in user object will trigger the mappings and there will be yet another result: an operation to change LDAP attribute sn. Therefore we also need to allow this operation:

There are several interesting things about this authorization. Firstly this is an execution phase authorization. And there is no such authorization in the request phase. This is exactly what we want. We want to allow execution of account modification if it is a result of policy evaluation (which means outbound mappings in this case). But we do not want to allow users explicitly requesting changes to account attributes. Therefore this authorization only allows operation in the execution phase. Secondly this authorization is using an owner clause to define object. This is necessary because this authorization applies to different object than previous authorizations. Previous authorizations applied to a user as an object. But this authorization applies to a shadow. It is important to realize that change of one object can result in a change of a different object, e.g. as data are mapped between focus and projections. And authorizations needs to be set up accordingly.

Following action URLs are used for object operations:

Up until midPoint 3.9 there was only one read authorization that governed all the read operations. Since midPoint 3.9 there are two related, but distinct operations: get and search.

Get authorization governs operations when a single specific object is retrieved. This is usually the getObject() operation that retrieves objects by their object identifier (OID). This is perhaps the most frequently used operation in midPoint. It is used almost everywhere: when accounts, roles and organizational units of a specific user are retrieved, when midPoint gets information about approvers, owners, resources referenced from tasks and so on. This usually happens when midPoint follows object references (e.g. links).

Search authorization applies to operations that are looking through many objects. Those are search(), searchIterative() and count() operations. In this case we do not have object identifier, we are looking for an object by specifying search criteria (filter/query). Those operations are used mostly by user interface when listing objects such as users, roles and tasks. It is also applied to many operations related to organizational structure management.

In normal case both get and search authorizations are needed and in fact they are often exactly the same. But there are cases when the difference between those operations can be used to gain significant advantage. For example, it is often safe to allow get of basic properties of almost any object in the system. And this is often really needed. We want to allow users to read names of roles and organizational units that are assigned to them. We want to allow them to get information about owners and approvers of the roles that the user has access to. All of that is governed by get authorization. Therefore we often want to enable get for almost any object in the system (provided that only a reasonable set of properties is returned). On the other hand, we usually do not want any user to see all the other users. We want the users to see all the active employees, or all the users in their workgroup. But we do not want them to see all the archived objects. We want users to get all the roles in the system, even the deprecated or archived ones in case that they happen to still have them assigned. But we do not want those roles to appear in the searches. And this is how the difference between get and search operation can be used: give users quite a broad authorization to get objects. But strictly limit their search capability.

The read authorization is still supported for compatibility and convenience reasons. It can be understood as a shortcut for specifying both get and search authorizations.

The object selection criteria can be combined in almost any meaningful way. E.g. the following authorization only applies to user objects that have locality set to Caribbean and are in the Org identified by OID 1f82e908-0072-11e4-9532-001e8c717e5b.

Each authorization specify zone of control over some part of midPoint objects. The zone of control is the set of objects that the authorization allows access to. Zone of control is defined by the object specification of the authorization as described above. This may be a filter, organizational structure reference and so on. If the object is part of the zone of control then the authorization is applied. So far there is nothing special about it. But it becomes really interesting in cases, when user is allowed to modify the properties that are used to set the zone of control. For example let’s have a look at following authorization:

This authorization allows a user to change the value of subtype property. But if the user changes the value to anything else than employee then such user forfeits the ability to modify this object. The object will move outside of user’s zone of control. MidPoint 3.8 and earlier in fact allowed that operation. But in that case it is very difficult to set up authorization policies to make sure that the zone of control is properly maintained. The above example is very simple, but the situation may get really complicated in real-world scenarios, especially in delegated administration and multi-tenancy configurations. In such cases it was really easy to get the authorization statements wrong and give users stronger rights that intended. Therefore the behavior was changed in midPoint 3.9 and such operations are no longer allowed (but see also below). In midPoint 3.9 the zone of control is maintained. MidPoint will not allow any operation where modification of an object would result in that object getting out of authorization zone of control. This has important implications especially for multitenant deployments.

Even though the behavior of midPoint 3.9 zone of control is now more intuitive and much more secure, there may be cases when we need to allow operations that are going outside of zone of control. In that case there is a new zoneOfControl configuration clause for authorizations. Authorizations that need to break zone of control boundaries or authorizations that need to be compatible with midPoint 3.8 may explicitly allow such operations:

Assignment and unassignment are quite powerful operations in midPoint. However, basic create-read-update-delete (CRUD) authorization are quite crude to address the intricacies of midPoint assignments. These authorizations can only allow all assignments or deny any assignments. There is no middle ground. And that is not very practical. However, there is a solution.

There are two authorizations that are designed for the purpose of controlling the assignment and unassignment on a fine level. These authorizations are designed to be target-aware. The target is the object which is assigned or unassigned (role, org, service or deputy user). This can be used to precisely control which objects may be assigned or unassigned.

However, assign/unassign authorizations make sense only in the request phase. The primary goal of these authorizations is to limit the targets of assignment. And that is processed only in the request phase. All that execution phase can see is just a modification of the assignment container. Therefore for the assign/unassign authorizations to work correctly, you have to allow assign in the request phase and modification of assignment container in the execution phase. The default end user role is a good example for this.

Assignment and unassignment authorization can be applied to inducements using the very same principles. There is an authorization clause orderConstraints that controls whether authorization applies to assignment, inducement or both.

This authorization applies both to assignments and inducements. The differentiator between assignment and inducement is so-called order. Order of zero means assignment. Order of one or more means inducement (see Roles, Metaroles and Generic Synchronization page for more details). The orderConstraints clause can be used to set min/max for order therefore limiting authorization to assignment, inducements or both.

The default behavior of assignment/inducement authorizations is to apply only to assignments. Therefore if no orderConstraints clause is present, then the authorization allows assignments only. This behavior is slightly different from other authorization clauses, where no clause means no limitation. But this behavior was chosen for compatibility reasons.

There are "automatic" item in midPoint that midPoint manages by itself. For example roleMembershipRef reference that contains a collection of direct and indirect role memberships for each focus. MidPoint will determine that automatically when assignments are evaluated. The roleMembershipRef values are stored in the repository, so they can be used by quick search operations. There are many items like these: object and assignment metadata, role, organization and tenant references (parentOrgRef, roleMembershipRef, tenantRef), activation metadata and virtual properties (e.g. effectiveStatus), credential metadata and many more.

Those are the items that midPoint logic controls directly. They have exception from execution-phase authorization enforcement. Their modification in execution phase is always allowed. If it was not allowed then midPoint won’t be able to function properly and it may even lead to security issues.

Therefore, there is a general rule: if midPoint manages an item by itself as part of midPoint internal data management or policy management then modification of such item is implicitly allowed in the execution phase of authorization evaluation. This does not need to be allowed explicitly. However, what still needs to be allowed explicitly are the items that are modified by mappings, hooks and other customizable code. To put it simply: If midPoint modifies something by itself and there is no way to turn that off or customize it then such modification is implicitly allowed. If something is modified by a customized logic (mappings, hooks or other customization) then this is not allowed implicitly and you will need explicit authorization for that.

This exception applies to execution phase only. Request phase is not affected. All the items are still controlled by regular authorizations for request phase. Therefore these exceptions do not allow user to modify those items. Attempt to do so must pass through request-phase authorization first. This exception only allows midPoint logic to modify those properties without explicit authorizations.

Self-service password change is one of the most widely used IDM functionality. However, the authorization setup is not trivial due to various specifics that a password has. Let’s go through this scenario by starting with the simplest way and ending with the right way.

The simplest way how to allow change of user’s own password is by using a simple authorization:

This authorization will allow both request and execution of user password modification. Simple. But there are two problems.

Firstly, this authorization will only allow modification of user password. It will not allow modification of account passwords. Therefore if the user password is mapped to accounts (which is the usual case) then the operation will fail. So we need another authorization that allows modification of account password.

This authorization allows to change password on all projections (given by ShadowType and owner combination), but only in the execution phase. Which means that mapped password change can be propagated. It will not allow direct change of account password. If this is desired then also request phase should be allowed.

The second problem with the original authorization is that there are several processes to change the password. E.g. system administrator or call center agent can change a password without specifying the old password value. This is needed to handle the case when a password is forgotten. But a normal user can change the password only if old password value is specified. Therefore there are also two different authorization setups:

Also, it is generally better to allow change of all credentials, not just password. In midPoint 3.3 and later password is the only supported credential type. But later versions will bring support for new credential types. Therefore the complete configuration for self-service password change looks like this: