<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear midPoint community,<br>
<div class="entry-content">
<p>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 <i>archetypes</i>. The archetype functionality is
one of the highlights of <a
href="https://evolveum.com/midpoint-4-0-gutenberg/">midPoint
4.0 “Gutenberg”</a>. And this is the story how the idea of
archetypes evolved during the course of midPoint development.<span
id="more-5756"></span></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>There is a mechanism in midPoint that is almost never seen in
other IDM systems: <a
href="https://wiki.evolveum.com/display/midPoint/Metaroles">metaroles</a>.
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 <i>archetypes</i> were
born. But more about it next time.</p>
</div>
<div class="entry-content">
<p>(Reposted from <a moz-do-not-send="true"
href="https://evolveum.com/road-to-archetypes/">Evolveum blog</a>)</p>
<p><br>
</p>
</div>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
</body>
</html>