MidPoint is developed in evolutionary fashion. When we have started midPoint, many things were considered during the design. But we were not able to implement everything during early years of midPoint development. Therefore some ideas matured in the heads of midPoint developers until their time came. That is also the case of archetypes. The archetype functionality is one of the highlights of midPoint 4.0 “Gutenberg”. And this is the story how the idea of archetypes evolved during the course of midPoint development.
Identity management in early 2000s was all about users and accounts. First-generation IDM systems that were born during that period were quite simple. They could be simple because huge part of the functionality was hardcoded: user has accounts, roles apply to users and so on. But that was almost two decades ago and the world is quite a different place now. Identity management is no longer just about the users. Yes, users are still the primary focus. But we also have to manage business roles, application roles, policies, organizational units, teams, tenants, applications, mobile devices and everything else that has an “identity”. Which is pretty much everything.
MidPoint is a second-generation IDM system. When we designed midPoint we have learned from the mistakes of our predecessors. We have designed midPoint for the new flexible world of widespread identity management. Basic midPoint schema was designed with a focus on several fundamental objects: user, role, org and service. We have always considered those object types to be somehow abstract, to be more than meets the eye. For example, “user” usually represents physical persons. But it can also represent personas, remote actors and so on. The concept of “role” is even more flexible, representing different role types and privilege groupings. And “org” is a complete chameleon. It is used for organizational units, divisions, departments, sections, companies, teams, projects, classes, domains, realms, tenants and almost anything else that can group other objects. Unlike many other IDM systems, this flexibility is an integral part of midPoint design and midPoint had it almost from the day one.
However, one crucial element was missing. It was not very straightforward to distinguish a department from a project. Both of them are “org” objects and they look pretty much the same to all processing code in midPoint. The usual practice was to create a separate organization tree for functional organizational structure with divisions departments and section. And then have another organization tree that was used just for projects. This worked reasonably well for org-like objects. But there is a similar issue with users, roles and services. Those objects can be placed to organizational structures as well. But such configuration can get very complicated. Which means that it is difficult to maintain.
Those of you that are already familiar with the way how we work would probably know that we completely dislike things that are difficult to maintain. Efficient maintenance was the primary motivation to create midPoint in the first place. Therefore during the history of midPoint development we have made several attempts to improve the situation. There was always an employeeType property in midPoint schema. This particular property has deep historic roots. There was always a property like this in IDM systems. Therefore it was quite straightforward to introduce roleType, orgType and serviceType properties. Those properties later evolved into unified subtype. That worked quite well in practice. But that was not a complete solution. There was still more to do.
There is a mechanism in midPoint that is almost never seen in other IDM systems: metaroles. Simply speaking, metaroles are roles applied to other roles. Even though the concept of metaroles may be quite strange, it is a very powerful mechanism. It can be used to distinguish objects. Metaroles can give objects a distinctive behavior and consistently apply differentiated policies to objects. This concept was an ideal foundation for a comprehensive mechanism to distinguish object types. We had that idea in our minds for quite awhile, but the crucial funding to develop the idea was missing. That funding finally came in midPoint 4.0 in a form of platform subscription. And that is how archetypes were born. But more about it next time.