Retirement of Roles

MidPoint does not keep referential integrity - by purpose. If a role is deleted then the assignments will stay. Keeping the assignments saves us from trouble and errors, e.g. unintentional deletion of role. It is easy to re-add the role. But it would be much more difficult to re-add all the assignments. Similarly for role replacement and other use cases.

However, what do to in cases that we need to retire a role and we really need to remove the assignments?

The problem is that clean removal of a role can be a slow process. The role usually gives some privileges. Therefore those privileges may need to be removed first. That can take time. Therefore this needs to be done by an background task.

The administrator could user a Bulk tasks to unassign the role manually and then remove the role. This works in cases when role removal is manual. But what we can do if role removal needs to be an automatic process, e.g. in cases when generic synchronization is used?

MidPoint object lifecycle mechanism comes to the rescue. Instead of deleting a role, the role will be transitioned to a special lifecycle state "retired". Role can be still active in this state and it will grant all the privileges. Then a task can be started to look for all the assignments to the retired role. The task can remove those assignments. Removal of the assignment will mean that all the privileges that the role privileges will be correctly deprovisioned. Roles in the "retired" state will no longer be assigned, therefore the task will eventually clear the slate. The role is no longer assigned and therefore it can be deleted or archived.

There is a similar lifecycle state "deprecated" already. But this state is slightly different. Deprecated roles should no longer be assigned. But no measure are implemented to actively unassign deprecated roles. Deprecated roles may live happily for years and years. On the other hand "retired" roles are quite aggressively unassigned and removed.