<expression> <value/> </expression>
Complex values and multiple values must be wrapped in appropriate element for the literal expression to distinguish the value structure. Following example shows definition of two literal values for structured property
<expression> <variable> <name>jack</name> <objectRef oid="c0c010c0-d34d-b33f-f00d-111111111111" type="UserType"/> </variable> <path>$jack/givenName</path> </expression>
If value construction is used in a case where it is likely that most of the values will originate from a single object or a data structure such structure is assigned to the root node of the expression. The root node is kind of a default variable for the expression. Some expression languages can take advantage of the root node but most cannot. Therefore the root node mostly applies to XPath and similar languages. In XPath the root node can be addressed without a variable name. Therefore the following two expressions are equivalent (assuming that user is set as a root node).
<expression> <script> <language>http://www.w3.org/TR/xpath/</language> <code>c:name</code> </script> </expression>
Expressions are normally evaluated using the security principal of the user that initiated the operation. This is best security practice as the authorizations go deep into the system and close to the data. In this it unlikely that an expression would read data or initiate an operation that the user is not authorized for. Therefore the probability of a security breach is reduced.
actor that is present in most expressions still refers to the identity of the user that initiated the operations. This variable is not affected by the
Security of Script Expressions
Script expressions are a code that runs inside midPoint servers. As such, script expressions are incredibly powerful. But with great powers comes great responsibility. Script expressions can do a lot of useful things, but they can also do a lot of harm. There are just a few simple internal safeguards when it comes to expression evaluation. E.g. midPoint script libraries will properly enforce authorization when executing the functions. However, script languages are powerful and a clever expression can find a way around this safeguards. MidPoint is not placing expressions in a sandbox, therefore expressions are free to do almost anything. The sandbox is not enforced from complexity and performance reasons, but it may be applied in future midPoint versions if necessary. For the time being, please be very careful who can define expressions in midPoint. Do not allow any untrusted user to modify the expressions.
See Script Expression Sandboxing for more details.