Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

See the IDM Model Authorizations page for list of action URLs for the "core" authorizations.

Authorization phases

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 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 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:

OperationURLDescriptionSince
Readhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#readAll 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).
3.0
Gethttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#getGetting 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.
3.9
Searchhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#searchSearching 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).
3.9
Addhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#addAdding new objects. Creating entirely new object.3.0
Modifyhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#modifyModifications of existing objects.3.0
Deletehttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#deleteDeleting objects.3.0
Raw operationhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#rawOperationAll 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 rawOperation and modify authorization are needed to execute raw object modification.
3.7
Partial executionhttp://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#partialExecutionAll 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 partialExecution and modify authorization are needed to execute partial object modification.
3.7

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:

Logger nameleveleffect
com.evolveum.midpoint.securityTRACEEnabled traces of all the security-related processing in midPoint core
com.evolveum.midpoint.security.impl.SecurityEnforcerImplTRACEEnables 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.

...

Info
titleImplementation note

 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 item declaration. The primary difference is in the way how GUI presents and enforces the authorizations. The ...#modify authorization is used in the edit schema (refined schema). Therefore if the ...#modify authorization is present, the GUI will render a read-write widget for password. If it is not present then the password widget will not allow password change. The ...#changeCredentials authorization is not used to compute edit schema. Therefore even if it is present then the password field in the user form will still be rendered as read-only. Therefore the only way how the user can change the password is to use credentials self-service page. And this page will require old user password (if it is set up to do it).

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.

 


See Also