Role Autoassign Configuration

The policies of automatic role assignment can be specified in roles themselves. Each role can have a condition when it should be assigned:

The role above will be automatically assigned to any user that has property organizationalUnit set to support. Please note that explicit stringify() invocation is needed in this case as the organizationalUnit property is of PolyString type. As all midPoint mapping even this mapping is relativistic. If user becomes an intern (the employeeType property is changed) then the role is automatically assigned. When the user stops being an intern the role is unassigned. Obviously, it also works with multivalued properties and so on. Simply speaking, this is a well-mannered midPoint mapping.

This is all that is needed for simple cases: just specify the condition. MidPoint takes care of all the rest.

Since midPoint 4.2 it is possible to restrict auto assignment evaluation to specific object using selector object. Using example below, autoassignment will be applied only for the user with archetype employee:

The simple example above shows just a very simple mapping. There is just a source and a condition. There is no expression. This is how the mapping is designed. MidPoint prepares the assignment data structure. Then the assignment is passed as a default source to the mapping. Therefore all the mapping needs to do for the role to be assigned is to pass the default input on. And that is just what the default asIs expression evaluator does. Therefore all the the mapping needs to do is to decide whether the assignment has to pass though or not. And that is what the condition does.

This is very simple and efficient way. But it is also quite powerful. The mapping expression is not usually there. But it can be there. The expression can modify the default assignment. For example it can specify assignment parameters, activation and so on.

In fact the mapping is evaluated in exactly the same way as object template mappings. Therefore it has all the powers of an object template mapping. Just the mapping source is populated with prepared assignment and the target is pre-set to assignment container so the mapping is easier to use within roles.

Role autoassignment is a very elegant mechanism. But there are implications. If anything about the user is changed midPoint has to decide whether any new roles have to be assigned. But to do that midPoint has to evaluate all the autoassigment rules in all the roles - even those that are not assigned to the user yet. As some midPoint deployments use a large number of roles this can be a significant performance hit. Therefore there are two configuration steps that need to be taken to enable this mechanism. Firstly, role autoassignment need to be enabled in global system configuration:

Secondlly, each role that has an autoassign rules needs to be explicitly marked by using the autoassign/enabled flag:

This configuration limits the work that midPoint has to do for every operation. MidPoint will only process those roles that are explicitly marked for processing. And midPoint will entirely skip the lookup of the roles if the mechanism is not used at all.

It perhaps goes without saying that the more autoassign roles are there the worse is the performance impact. The actual impact depends on the number of such roles, their complexity and overall complexity of the midPoint deployment. It is usually perfectly acceptable to have tens of autoassign roles. But thousands of autoassign roles are usually not a good idea. And the performance is usually not the worst issue there. Maintenance of thousands of autoassignment rules is very likely to be the real burden. In that case it may be better to consider a more systemic approach by using object template.

Current role autoassignment implementation is simple and powerful. But it may be too powerful for some use-cases. For example, it is not easy to create a nice and simple user interface for the autoassignment expressions as they are very likely to be script expressions. Therefore current midPoint (3.7) user interface does not support that.

Proposed future development is to allow alternative way to specify autoassignment conditions, for example by using search filters or some other formalized method that allows to create an easy user interface.