Assignment vs Inducement

Assignment is a policy statement that assigns something directly to the object in which the assignment is. Therefore if user has an account assignment then this account should be created for this user. Plain and simple.

Simply speaking inducements are indirect assignments. Unlike assignments inducements do not apply to the object in which they are specified. Inducements apply to the object that is has assigned the object which contains inducements. E.g. inducements specified in a role will not be applied to the role itself. The inducements will be applied to the user that is assigned to such role.

Even though the inducement is placed in the role it does not imply any kind of shadow for the role itself. The account shadow is implied for the user, not the role. Therefore the inducement is indirect. It is "inducting" the assignment in a different object.

Assignments and inducements are internally identical. And in fact there was only an assignment which was used both directly and indirectly in previous midPoint versions (prior to version 2.2). This simple approach works well as long as we only deal with users and accounts. But the situation gets very complex once we allow roles and organizational units to have associated shadows in a similar way that user has account shadow (a.k.a. Generic Synchronization). This is a very powerful feature. But for this feature to work well we had to refine and clean up the data model to allow for greater flexibility and expressive power. And therefore we need both (direct) assignment and (indirect) inducement. While it may seem a bit overcomplicated it greatly pays off on the side of flexibility and the ability to elegantly handle even very complex situations.

In all other aspects the inducement and assignment are identical. Both may contain target reference, construction, condition, etc. Unless you are creating a very complex setup there is a simple rule of the thumb to adhere to:

You want to deviate from this rule usually only if Generic Synchronization is used.

Let’s get into a more complex setup now. Let’s have a role that has both assignment and inducement. Like this:

The assignment in a role imply an entitlement to be created as a representation of the role itself. Therefore a group "Captain" will be created on the resource. But the inducement does not imply anything for the role itself. The inducement is actually completely ignored until the role is assigned to a user. In that case the inducement will behave in a similar way as if an equivalent assignment was placed directly in the user. It is "inducing" the assignment in a different object (in this case user). Therefore the inducement in the role causes that an account will be created for the user.