Expression Profiles: Full Implementation

Expression profiles is currently a very limited feature. General infrastructure for expression profiles is implemented in midPoint core, however it is not applied to all expressions. In fact, before 4.8, the only type of expression that is constrained by expression profiles are expressions in reports used in midPoint. In 4.8 the support for expressions for bulk actions (e.g., in task templates or policy rules) was added. As an experimental feature, these profiles can be used to drive role auto-assignment process as well.

For scripting evaluators, the only scripting language that can be constrained by a permission profile is Groovy. Other languages do not have this ability yet. And even Groovy is only constrained on a "compilation level", which is very shallow protection. There is no sandboxing yet.

Support for expression profile identification in archetype policy was added only in 4.8.

There may be performance issues when using expression profiles, especially when used with big and complex permission profiles. The code is not yet optimized for performance.

See Expression Profile Configuration page for more details.

The crucial part of expression profiles is to systematically apply them to all the expressions. It takes just a single unchecked expression to circumvent system security barriers and the impact could be catastrophic. Therefore the implementation should take care that the profiles are always applied for evaluation of all the expressions. MidPoint code is somehow prepared for this, as there is special code that the evaluation must pass through. Just the checks need to implemented and properly initialized from all the parts of the system.

Testing will be also quite a big part of this task. There has to be a huge number of "negative" tests - tests that check that operations are properly denied.

Groovy is the only scripting language that can be constrained now. And even for Groovy the protection is quite shallow, as it is based on capabilities of Groovy compiler. The compiler-based protection only examines the script on the surface. Therefore the script cannot execute System.exit() directly. But somewhere in the system there may be a method which can be tricked to executing System.exit() under some circumstances. If such method is used, the compiler does not know that invoking that method may bring the system down. This can only be achieved by a run-time sandboxing of the script execution. While Java platform supports this concept, it is not implemented into midPoint script evaluator yet.

But that can be improved. We can implement full sandboxing of expression evaluation. In that case the script will be encapsulated in a sandbox. Java platform will check for any attempts that the code could make to escape the sandbox. The check is done at run-time, there even indirect attempts of a script to do any harm can be detected and eliminated. This is a native capability of the platform and it is pretty much bulletproof. And it can apply to all the scripting languages. However, it is not very easy to use and we expect a lot of unexpected surprises - as they often happen when sandboxing is used in practice. Not many libraries are used or tested in sandbox environment, and therefore it is often the case that a library needs much more privileges than strictly necessary. Compiler-based checks would pass in this case, as those are only concerned with the surface of what the script is using directly. But sandbox is "defense in depth", it checks for all the action that script does directly, but also for all the effects that script’s actions are causing indirectly. And those are quite difficult to predict until we get to a practical use cases. This will require a lot of time for testing and fine-tuning. But when done, this will be the ultimate cage to restrain misbehaving scripts.

There are cases when a script has to do something dangerous. As with all the dangerous things in life, it is very important to know how to do them safely. Obviously, there is some need for personal protective equipment. But this is not that easy if we lock up our script in a sandbox which the script cannot escape. We usually want those scripts to execute potentially dangerous code, if it is executed in a safe way. For example, we want the script to be able to access midPoint model interface, as that interface is enforcing authorizations. But that one is quite easy, as we can hardcode such exceptions or make them configurable in protection profiles. But what about accessing custom functions, e.g. functions stored in function libraries. For that we can create a privileged function libraries, whose methods can escape the protection of a sandbox. Privileged actions could be executed safely, as the library code may check for all the proper conditions and limitations before executing privileged operation.

TODO reference to 4.8 partial implementation of this

The performance of expressions is crucial for the overall performance of midPoint deployments. We are doing quite a lot of things to make sure that expression performance is acceptable, e.g. we are caching compiled expressions to avoid the overhead of repeated compilations. The result is that midPoint expressions are lightning fast and there is almost no performance concern of using many expressions. And the use of really many expressions is a typical case for almost all midPoint deployment.

However, things are slightly different when it comes to expression profiles. It is perhaps understandable, that enforcement of the profiles has some inherent overhead. But that overhead does not seem to be prohibitively high. The problem is that current implementation of expression profiles was created for smaller implementations. It was not developed with a performance in mind. Therefore the performance of profile checks in larger deployments should be tested and most likely improved to be practically usable.