[midPoint] Blog: Road To Archetypes

[Radovan Semancik]

Dear midPoint community,

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” 
<https://evolveum.com/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 
<https://wiki.evolveum.com/display/midPoint/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.

(Reposted from Evolveum blog <https://evolveum.com/road-to-archetypes/>)


-- 
Radovan Semancik
Software Architect
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20190924/dcdf934b/attachment.htm>