See the IDM Model Authorizations page for list of action URLs for the "core" authorizations.
Each operation is actually authorized twice when it goes through the IDM Model component:
- request phase - when operation enters the IDM Model component ("request phase") and
- execution phase - when operation leaves the IDM Model component ("execution phase").
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
familyName are mapped to LDAP attributes
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 use 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 account strictly controlled using midPoint policies and we do not want users to mess it 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:
Following action URLs are used for object operations:
|Read||All read operations: getting objects, searching objects, counting objects and so on.|
Since midPoint 3.9 this is a short-cut for get and search authorizations (see below).
|Get||Getting objects by OID. This authorizations applies to read operations where one specific object is retrieved.|
Note: This authorization also applies to search results. While the search authorization governs what can be searched for and how the search filter can be specified, individual results of the search are reduced by using get authorization. E.g. the properties of the object for which there is no get authorization are removed.
|Search||Searching objects. This authorization applies to read operations where many objects are searched to find objects that match particular criteria.|
Note: Search authorization governs how the user can form a search filter and which objects are returned. But each search result is passing through additional reduction by using get authorization (see above).
|Add||Adding new objects. Creating entirely new object.||3.0|
|Modify||Modifications of existing objects.||3.0|
|Raw operation||All operations that involve reading and changing of object in their raw representation. Simply speaking this is the XML/JSON/YAML representation of the object as is stored in the repository. Raw operations can be quite powerful as they go around all the policies. This is not supposed to be used in normal operation. Raw operations are intended for initial system configuration, configuration changes, emergency recovery and so on.|
Raw operation authorization is checked in addition to normal object operation. For example both
|Partial execution||All operations that limit midPoint processing only to certain parts. This is often used to skip some parts of the processing such as approval processing, processing of certain policies and so on. Partial execution can be used to go around the policies, therefore it is considered to be a sensitive operation that requires special autorization.|
This authorization is checked in addition to normal object operation. For example both
Read, Get and Search
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.
Authorizations can be tricky. Especially if there is a large number of them and they are complex. And security best practice effectively prohibits to provide any useful error messages to the user in case that the access is denied. Therefore troubleshooting of authorization issues can be quite a demanding task - as any security engineer undoubtedly knows. However we have tried to make this task easier by implementing an authorization trace. In this mode midPoint will trace processing of all authorization statements and record that in the logfiles. The trace can be enabled by setting the following log levels:
|com.evolveum.midpoint.security||TRACE||Enabled traces of all the security-related processing in midPoint core|
|com.evolveum.midpoint.security.impl.SecurityEnforcerImpl||TRACE||Enables just the processing of authorization statements and security contexts.|
Please note that enabling the authorization trace has a severe impact on system performance as it needs to write many log records for each and every midPoint operation. This trace is not designed to be continually enabled. It is just a troubleshooting tool that is supposed to be used mostly in devel/testing environments to set up a proper security policy.
The ...#modify and ...#changeCredentials authorizations are evaluated in almost the same way by the model. The both allow the modification of the properties specified in the
The bottom line is that the specifics of password change interactions are implemented and enforced in the GUI. The Model is only concerned whether the password change is allowed or denied, but it does not care about the actual process.