Higher-Order Inducements

Generic synchronization is a powerful feature that distinguished midPoint from many traditional IDM systems. Even though the generic synchronization itself is an interesting feature, what makes it incredibly powerful is the combination of generic synchronization with other midPoint features. This is especially true for a combination of generic synchronization with midPoint RBAC system. This page describes how these two features work together to create simple and very powerful configuration schemes.

MidPoint RBAC mechanism has all that you can expect from a provisioning RBAC structure. The most frequently used feature is perhaps role hierarchy. The following diagrams provides an example of a role hierarchy.

All the construction definitions placed inside inducements are applied to the user almost as if they are directly assigned. Therefore the user will efficiently have constructions for four accounts which in turn means that four accounts will be created for this particular user.

What is important here is the difference between assignment and inducement: the inducements are not applied directly. All the inducements from the entire role hierarchy are applied to the object that contains assignment. Which is a user.

The difference between assignment and inducement may seem like an unnecessary complication. But it is not. The true power of this mechanism becomes obvious only when it is used together with generic synchronization. Generic synchronization enables you to synchronize almost all midPoint objects to resources. One typical use of generic synchronization is to synchronize midPoint roles with groups on a resource. For example, we want to create LDAP groups for some midPoint roles. Because assignment is a generic concept that applies to roles and orgs equally as it applies to users, there is a simple way how to do this: we add an assignment with an appropriate group construction statement to every role that want to synchronize to LDAP. But there is a drawback: this needs to be specified in every role. This is simple to do if there is just a single group type with simple static mappings. But that is rarely the case. Also, this configuration would be very difficult to maintain in a long run.

MidPoint has a much better mechanism for this. And the idea is incredibly simple: let’s apply the RBAC mechanism to the roles themselves. This is how the concept of metaroles is born. A metarole is a role that is applied to another (regular) midPoint role. One such example is shown in the following diagram. The Group Metarole is applied to other roles, in this case to the Pirate Captain role.

The regular Pirate Lord, Pirate Captain, Captain, and Pirate roles form a role hierarchy. They are all connected by inducements. This means that everything that is specified in the entire hierarchy will be applied to the user who is at the end of the hierarchy.

The Group Metarole is different. It is connected to the Pirate Captain role by an assignment, not an inducement. This assignment breaks the role hierarchy at that very point. It means that the statements of Group Metarole will not be applied to a user. Remember: all inducements are applied to the object which contains an assignment. But this is the Pirate Captain role in this case. Therefore all the inducements from the Group Metarole will be applied to the Pirate Captain role. Group Metarole is a role that is applied to another role. Group Metarole does not describe what a user should look like. It describes what another role should look like.

Therefore you can simply assign the Group Metarole to any role that you want to synchronize as a group to the resource. All the mappings and configurations are in the metarole. The regular role contains just a simple assignment. Therefore if you want to adjust the configuration you just need to change the metarole and the change is applied to all the affected regular roles using a normal RBAC mechanisms.

This is a very powerful feature. You can create roles that are applied to other roles or orgs. This can be used to define a multitude of synchronization schemes for synchronization of roles to groups and privileges to the resources, for synchronization of parts of organizational structures to many resources in a very flexible way and so on. And all of that configuration is cleanly organized into a couple of metaroles in a proper RBAC fashion. And metaroles are still just roles. Therefore their assignment is properly audited, it is a subject to authorizations, it may be subject to approvals and so on.

In addition to creating LDAP groups from roles, you may also want to add accounts to these groups. This is done through a mechanism that we call high-order inducements in the following steps:

Normal (first-order) inducements work as described above, i.e. all inducements are applied to the first object that has an assignment. Therefore the inducements of Group Metarole were applied to the Pirate Captain role because that is the first object in the chain that has an assignment. However this behavior can be changed by specifying an order of an inducement. The order allows to apply an inducement to deeper levels of the chain than they would normally apply to. A second-order inducement will apply to the second assignment in the chain, a third-order inducement will apply to the third assignment in the chain, etc.

Therefore it is now very easy for a metarole to contain inducements that will apply both to the role and to the user. This is illustrated in the following diagram.

The first inducement in the Group Metarole is a regular first-order inducement. This will be applied to the Pirate Captain role and it will cause that an empty group object will be created on the resource. The other inducement is a second-order inducement. This will be applied to the user because the user is the second object in the chain which has an assignment. This inducement will cause that a new account will be created for a user. But there is still one piece missing. The account is not yet a member of the group. The set-up which does this is illustrated in the following diagram.

The associationFromLink expression is used to create an association between the account and the entitlement (group) which creates a group membership. As this is placed in a second-order inducement, it will be applied to a user and therefore it will be the appropriate user account which will be added to the group.

A complete configuration of the metarole looks like this:

A simple integer definition of order may not be sufficient for all use cases. There are numerous relations that define how objects relate to each other. For example, you may need to define different privileges to organization managers and to common organization members. This is done using complex order constraints that may define requirements for specific relations, order ranges, etc.

Constraints look like this:

The constraint above will limit the application of the inducement only to focal objects that have exactly one assignment on the path that has relation=manager. In other words, this inducement will be applied to the managers of this organization. But it will not be applied to ordinary members.

The order constraints can also specify the order range. For example, the following inducement will be applied to all situations where the order is higher than two:

There are special kinds of assignments that are used to define deputies. These assignments delegate privileges by setting relation to deputy. Therefore they are not considered a part of the normal order when evaluating metaroles. This means that what was originally order 2 will become order 3, etc. See the Deputy page for details.

Meta roles may be assigned to other roles. This is how meta-metaroles are created.

Their usage may not be entirely straightforward in some cases. For example, the associationFromLink expression needs one object to get links from. However, in the meta-meta-meta scenarios, there are many objects to choose from. There is a way to choose the object explicitly using the assignmentPathIndex property of the associationFromLink expression. This index points to the object that should be used as a source from which a link is gotten. Index 0 is the focal object, index 1 is the first (plain) role, index 2 is a metarole, index 3 is a meta-metarole, and so on. Negative index can also be used. In such a case, the order is reversed: index -1 is the last meta-meta-meta-…​-role, index -2 is the last but one, etc.

This feature is related to the following compliance frameworks: