Privilege Elevation (runAsRef, runPrivileged)

Last modified 17 Aug 2023 11:17 +02:00
Since 4.8
This functionality is available since version 4.8.


Sometimes we need a given expression (e.g., in mappings) to run under elevated privileges and/or a specific principal.


Listing 1: Example use
        <runAsRef oid="..." type="UserType"/> (1)
        <runPrivileged>true</runPrivileged> (2)
            // here we could execute actions that require elevated privileges
            ... midpoint.getObject(...) ...
            ... midpoint.searchObjects(...) ...
1 Switches the identity of the principal
2 Keeps the identity, elevates only the privileges

The <runAsRef> directive has been present since 3.6. It works well but takes some time as it requires the login of the specified principal. The new <runPrivileged> property is much faster: it simply adds #all authorization to the current principal.

Usually, either one of these should be used. However, it is possible to use both: first, a specified principal is logged in, and then their privileges are elevated.


The audit event record was enhanced by the following information:

Table 1. New items in the audit event record
Item Meaning


The effective principal that was used to execute the action. This is the subject whose authorizations were evaluated to determine whether the action is allowed or not. Usually, it is the same as the initiator. But, e.g., when runAsRef is used, the effective principal is the one specified by that directive.


Present if the effective privileges used to execute the operation differ or may differ from the regular (declared) privileges of the effectivePrincipalRef. This is usually the case, e.g., when "runPrivileged" mechanism is used for expression evaluation.

Table 2. Values for effectivePrivilegesModification property
Value Meaning


Privileges were elevated to some degree. It may or may not be the maximum degree (full authorization). Only if we are really sure, the "fullElevation" value is set.


Privileges were elevated to the maximum degree, i.e. to full authorization.


Privileges were reduced to some degree.


Privileges were changed in a different way (maybe some reduced, others elevated).


  1. The improved auditing works only with the native repository implementation.

  2. If the effectivePrivilegesModification property is present, it does not mean that the effective privileges certainly differ from the declared ones. It just means that the elevation/reduction took place; and, as a result, there may be a difference. For example, it a user already has privileges equivalent to full privileges, and "run privileged" expression is evaluated, the result still may be marked with fullElevation value. What is guaranteed, however, is that if this value is not present, then the action was executed with regular (declared) privileges of the principal.

See Also

Was this page helpful?
Thanks for your feedback