Skip to content

Commit

Permalink
Enhance "trusted bulk actions" page
Browse files Browse the repository at this point in the history
  • Loading branch information
mederly committed Aug 18, 2023
1 parent 72c3a1a commit 7d37466
Showing 1 changed file with 87 additions and 8 deletions.
95 changes: 87 additions & 8 deletions docs/security/trusted-actions/index.adoc
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
= Execution of Trusted Code by Unprivileged Users
= Execution of Trusted Bulk Actions by Unprivileged Users
:page-since: 4.8
:page-toc: top

== Introduction

#TODO#
Before 4.8, bulk actions were executed in a limited mode for non-superuser principals.
This caused some problems regarding custom GUI actions and scripting policy rules, as described in bug:MID-6913[] and bug:MID-7831[].

== Custom GUI Actions

Expand All @@ -23,8 +24,6 @@ The only limits are those of the user running the JVM.
As the midPoint before 4.8 did not recognize the origin of the code being executed, it employed a simple rule:
To execute a Groovy script (or any other, like Velocity, JavaScript, and so on) from within bulk action, one has to be an administrator.

See bug:MID-6913[] for more information.

=== Solution Overview
The solution is based on determining the origin of any expression or bulk action, and execute it under corresponding _expression profile_.

Expand Down Expand Up @@ -337,10 +336,90 @@ The following example will show such a function:

Please see xref:../privilege-elevation.adoc[] for more information about privilege elevation feature.

== Scripting Policy Actions
== Scripting Policy Constraints and Actions

When talking about policy rules, bulk actions can be present in two places: in `objectState`/`assignmentState` policy constraints and in `scriptExecution` policy actions.

Before 4.8, the bulk actions present in policy constraints were executed with all features (including scripts) enabled, whereas the ones present in policy actions were executed with all or limited features, depending on whether the currently logged-in user had `#all` authorization.

Starting with 4.8, these actions run under an expression profile that is determined in the standard way.
The defaults, however, mirror the behavior before 4.8, as described above.

An example:

.Listing 9. A role with bulk actions in policy rules
[source,xml]
----
<role xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:s="http://midpoint.evolveum.com/xml/ns/public/model/scripting-3"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
oid="128a5458-bcd4-4bf4-b110-664677e73aa4">
<name>role-with-scripting-action</name>
<assignment>
<targetRef oid="988c28d2-f879-4e07-a3cb-5ea7ad206146" type="ArchetypeType"/>
</assignment>
<assignment>
<policyRule>
<policyConstraints>
<objectState>
<executeScript>
<s:execute>
<s:outputTypeName>xsd:boolean</s:outputTypeName>
<s:forWholeInput>true</s:forWholeInput>
<s:script>
<code>
log.info('object = {}', object)
// ...
true
</code>
</s:script>
</s:execute>
</executeScript>
</objectState>
</policyConstraints>
<policyActions>
<scriptExecution>
<executeScript>
<s:execute>
<s:script>
<code>
log.info('focus = {}', focus)
log.info('input = {}', input)
// ...
</code>
</s:script>
</s:execute>
</executeScript>
</scriptExecution>
</policyActions>
</policyRule>
</assignment>
</role>
----

The archetype provides the execution profile, for example:

.Listing 10. An archetype for trusted roles
[source,xml]
----
<archetype xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
oid="988c28d2-f879-4e07-a3cb-5ea7ad206146">
<name>trusted-role</name>
<archetypePolicy>
<expressionProfile>trusted</expressionProfile>
</archetypePolicy>
</archetype>
----

The content of policy rules in objects is generally considered trusted, because the default expression profile allows execution of arbitrary Groovy code present in these objects.
(The bulk actions were a notable exception to this rule.)
Hence, by providing a "fully trusted" expression profile for bulk actions should provide no harm, compared to the state before 4.8.
Of course, in the future we plan to support safe definition of roles by less trusted users, where the expression profile specification will be a crucial point in ensuring the security of such a solution.

== See Also

#TODO#
* xref:/midpoint/reference/expressions/expressions/profiles/[Expression Profiles]

== For More Information
* xref:/midpoint/reference/expressions/expressions/profiles/configuration/[Expression Profile Configuration]

#TODO#
* xref:/midpoint/reference/security/security-guide/[Security Guide]

0 comments on commit 7d37466

Please sign in to comment.