Phoebe

07 Feb 2012

MidPoint version 1.10 code-named Phoebe was released today. Although the changes with respect to the previous version may not be that obvious, there is much that has happened under the hood. There are especially two things that I'm quite proud of: relative change model and RBAC.

MidPoint is now built entirely on the concept of relative changes. All the legacy OpenIDM code was removed and there is a brand new implementation of the IDM logic. Using relative changes seems to be the best approach in identity management as there is no locking and no other support for consistency. MidPoint now treats all changes as deltas that describe relative change to the user or account. This allows to do quite a broad variety of things without being too limited by consistency. Deltas will work without locking, therefore there is not much harm if they are stuck for days waiting for a boss to return from vacation and approve the request. Deltas are easy to merge, therefore the order in which they are applied usually does not matter (we have been careful to have only unordered data in midPoint to allow this). The switch to complete relative changes is a critical move in midPoint evolution. It was planned almost from the very beginning of OpenIDM development and it was finally implemented in midPoint (it seems that this model was dropped in OpenIDMv2 which I considered to be a major mistake). The results that we see in midPoint confirms that we are following the right path.

Second major improvement of midPoint is its RBAC implementation. Traditional RBAC models suffer from a critical problem known as role explosion. The number of roles keeps increasing and multiplying until it exceeds the number of managed identities. Then a hard problem of managing identities transforms to even harder problem of role management. MidPoint solves this problem in two ways that work together very well: flexible role definition and support for RBAC exceptions.

The roles in midPoint are quite smart. Similarly to roles in Waveset they may contain expressions that set account attributes, assigns account to groups, etc. This little feature is quite efficient to reduce the number of roles. However we are going one step further. MidPoint roles can be parametric. The roles can be customized not only at the time role definition is created, it can also be adjusted at the time the role is assigned to user. E.g. we can have a single Assistant role that is parametrized by the department name. Then the expressions in the role algorithmically derive the names of the appropriate groups from the name of the department. One role is enough to support assistants of all departments. When the role is assigned to a user additional department parameter is specified. Therefore the role can derive appropriate group names for each case. This role can even be assigned several times to the same user, usually with different parameters. This can model a situation when an employee acts as assistant for several departments.

What we have learned during all these long years of IDM deployments is that there is no rule without an exception. Completely formalizing access control policies to an RBAC structure is a work similar to that of Sysiphus. As Pareto told us, it may be efficient to cover 80% of cases with 20% of roles. But what to do with the rest? MidPoint allows to specify quite a fine-grained exceptions to the RBAC rules. This allows to specify a "legal exception" from the RBAC rules for each user. In fact, the mechanism for specifying an exception is almost the same as the mechanism used to define a role. It is in fact kind of a "private role" for each user. Therefore the same role analysis and mining principles that work with roles may also work on such exceptions and so the exceptions are not a way towards a dead end as it might appear.

Although both relative changes and RBAC are somehow hidden under the hood now, they work surprisingly well. The next midPoint version Rhea will bring an improved GUI to better present them to the public. Stay tuned. There is more to come ...