Role Autoassign Configuration

Last modified 06 Nov 2025 12:52 +01:00

Basic Mechanism

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

Autoassignment mapping in a role
<role>
    <name>Support</name>
    ...
    <autoassign>
        <enabled>true</enabled>
        <focus>
            <selector>  <!-- Since 4.2 -->
                <type>UserType</type>
            </selector>
            <mapping>
                <strength>strong</strength>
                <source>
                    <path>organizationalUnit</path>
                </source>
                <condition>
                    <filter>
                        <filter>
                            <q:text>costCenter = 'A001'</q:text>
                        </filter>
                    </filter>
                </condition>
            </mapping>
        </focus>
    </autoassign>
</role>

The role above will be automatically assigned to any user that has property costCenter set to A001. As all midPoint mapping even this mapping is relativistic. If user cost center is set to A001 (the costCenter property is changed) then the role is automatically assigned. When the user cost center is changed to a different value, the role is unassigned. Of course, it also works with multivalued properties. Simply speaking, autoassignment is a proper well-mannered midPoint mapping.

Condition is all that is needed for simple cases. 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:

Selector example
<autoassign>
        <enabled>true</enabled>
        <focus>
            <selector>
                <type>UserType</type>
                <archetypeRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6" type="ArchetypeType"> <!-- Employee archetype -->
                </archetypeRef>
            </selector>
            ....
        </focus>
</autoassign>

Relation and Other Parameters

The example above implements a very simple case. There is just a source and a condition in the role autoassignment mapping. There is no expression. This is the way the role autoassignment mapping is designed. MidPoint prepares the assignment data structure, which 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. The default asIs expression evaluator does that, therefore there is no need to specify the expression explicitly. All the mapping needs to do is to decide whether the assignment has to pass though or not. That decision is controlled by the condition.

This is very simple and efficient method. Yet, it can be quite powerful as well. The mapping expression is usually not needed. However, it can be specified when there is a need to modify or customize the default assignment. For example, the expression can specify assignment parameters, relation, 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.

Global Configuration and Limitations

Role autoassignment is a very elegant mechanism. However, there are implications. If anything about the user is changed, midPoint has to decide whether any new roles have to be assigned or unassigned. 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, evaluation of all roles can be a significant performance hit. Therefore, the role autoassignment mechanism is not enabled by default. 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:

<systemConfiguration>
    ...
    <roleManagement>
        <autoassignEnabled>true</autoassignEnabled>
    </roleManagement>
    ...
</systemConfiguration>

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

Autoassignment mapping in a role
<role>
    ...
    <autoassign>
        <enabled>true</enabled>
        ...
    </autoassign>
</role>

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

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. However, thousands of autoassign roles are usually not a good idea. 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.

Limitations and Notes

  • MidPoint user interface does not support configuration of role autoassignment.

  • Filter expression evaluator is recommended method for specification of autoassignment conditions (since midPoint 4.10 when the evaluator was introduced). Filter expression evaluator is a safe method for specifying conditions. This approach avoids the need to use potentially dangerous script expressions. Expression profiles can be used to limit dangerous expressions in the roles and other object types.

  • In addition to a condition in autoassignment mapping, there is also an alternative way to specify a filter-based condition for autoassignment. Selector part of the autoassignment configuration may contain a filter. However, unlike the mapping, the selector does not work both ways. When the selector is used instead of mapping, the role is automatically assigned, yet it is not unassgined. The use of filters in the selector is not meant as a repalcement for mapping conditions. The selector is meant to limit the number of objects that are considered for role autoassignment.

Missing/incomplete feature
This is a missing or incomplete feature of midPoint and/or of other related components. We are perfectly capable to implement, fix and finish the feature, just the funding for the work is needed. Please consider the possibility for supporting development of this feature by means of midPoint Platform subscription. If you already 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.
Was this page helpful?
YES NO
Thanks for your feedback