MidPoint 4.0 and later
This is a limited midPoint feature. This feature currently supports only some specific use-cases. We are perfectly capable to finish the feature, just the funding for the work is needed. Please consider the possibility for supporting development of this feature by using midPoint Platform subscription. If you are midPoint Platform subscriber and this feature is within the goals of your deployment you may be able to use your subscription to endorse implementation of this feature.
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:
- Metaroles can be used to group all the necessary logic, including expressions. Meta roles can be setup by a trusted administrator. Delegated administrators then just "use" the metarole, with possible parametrization using parameters in assignment extension. However, even this method is not yet fully supported in midPoint user interface.
- Object lifecycle mechanism can be used to drive role definitions through an approval process. This can be used to make sure that expressions used in the roles are safe.
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
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 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.
Future of Expression Profiles
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.