Expression Profiles

MidPoint expressions are a very flexible tool that can be used to customize midPoint behavior almost to the extreme. Expressions are used everywhere: mappings, role conditions, reports and all the way up to user interface customization. This flexibility is a fundamental part of midPoint design and it work incredibly well.

However, flexibility also has a dark side. MidPoint expressions are powerful. But for some purposes they may be just too powerful. Expressions, and especially scripting expressions, can do anything. This can be abused by a malevolent attacker to gain unauthorized access to data, disable the system or do almost any kind of damage. This is the very nature of customization based on scripting. Even though the dangers are quite obvious and self-explanatory, we have warned the users about this all the time. The recommendation was not to allow any untrusted user to set up any expression.

However, there is a limit to such an recommendation. Expressions are the fuel that drives midPoint flexibility on too many levels. It is difficult to image really complex configuration where all the roles are designed by system administrator. And it is also difficult to imagine a life with just a static roles. That would easily lead to role explosion. Thanks to midPoint design, there were ways how to work around this problem:

But neither of those mechanism is a complete and definitive solution. The real solution is an ability to limit the power of expressions as needed. Enter: expression profiles.

Expression profiles are definitions, what an expression can and cannot do. For example an expression profile may dictate, that particular expression can only use asIs and path evaluators. And in case that script evaluator is used, only Groovy can be used as a scripting language, the script should be type-checked and only use of particular safe classes should be allowed.

Expression profiles are defined in system configuration. That part is quite easy. But it is much more difficult to specify which expression should be constrained by which profile. Profile specification cannot be a part of expression itself. In that case anyone that can modify an expression could also change the profile and there would be no security at all. Therefore the use of expression profiles is integrated with archetypes. Object archetype assignment does not usually change - and if it does it is quite an unusual and perhaps very special process. Usually only the system administrator has the rights to define archetype definitions. And midPoint is designed to process archetypes very efficiently. Which is extremely important as expressions are evaluated very often. Therefore all of that makes archetypes a very good fit for expression profile specification.

See Expression Profile Configuration page for the details.

The implementation of expression profiles in current midPoint versions is very limited. But that can be improved.

Please see Expression Profiles: Full Implementation page for the details about our plans for the future of expression profiles.