All generalizations are dangerous, even this one.
MidPoint has many types of objects hard-coded: users, roles, orgs, services and many more. However, no amount of hard-coded types could ever be enough to describe the vast diversity of the world around us. Hence, there are archetypes, providing a mechanism to describe objects in finer details.
There are five basic types of focal objects:
-
User (
UserType) represents users, usually as physical persons or personas. -
Org (
OrgType) represents groups of other objects, such as organizational units, teams, projects or locations. -
Role (
RoleType) represents roles, responsibilities or policies that can be applied to other objects. -
Service (
ServiceType) represents non-human actors and assets, such as network services, applications and devices. -
Generic object (
GenericObjectType) can represent anything else.
These are focal types, because they can be a focus of midPoint computation. They are the center of start topology, the hub of the hub-and-spoke data mapping model that midPoint is using. E.g. User has several linked accounts. In midPoint parlance, user is the focus, accounts are projections. User data can be mapped to accounts, account data can be mapped to user, but account cannot be mapped to another account. That is the principle of the star topology.
We have already seen that. However, focal objects are meant to be much more than a mere center of data synchronization topology. These objects are meant to have business meaning, to represent entities and concepts from the real world around us. Almost every practical object, entity or concept can be classified to the first four types. Physical persons, personas and other human-like identities can be represented as users. Groups of other objects can be represented as orgs, such as organizations, organizational units, various types of teams, projects, classes, interest groups and task forces. Even concepts that do not immediately come to mind can be represented as orgs, such as locations or nationalities. Concept of service can represent almost any thing, such as devices, network services, applications, databases, documents - even non-tangible assets such as datasets or workspaces. MidPoint roles can be, quite obviously, used as roles for role-based access control (RBAC) purposes. However, they can also represent business concepts, such as jobs, work positions and responsibilities. Roles can even represent very abstract concepts such as policies, classifications and clearances. Almost anything that you can think of, anything which would be described as identity, could be classified in those four types: user, org, role or service. In a very rare case when a concept does not fit in any of these categories, there is always generic object as a last resort. However, the user-org-role-service quartet works so well, that the generic object was not really needed for years and years.
The four types are not just cosmetics, they have specific features that allow them to represent real-world concepts.
-
User has several naming properties, such as full name and given name, which are typical for natural persons. It also has credentials (e.g. password)
-
Org can form hierarchies. There can be orgs in orgs, which is very useful for building organizational structures, or hierarchies of locations.
-
Role is meant to grant privileges to users.
-
Service has credentials, similarly to users. Therefore, service can represent machine agents, robots and similar active things that behave like humans. However, service is meant to represent non-human identities, therefore it does not have human-like names.
This description is somehow simplified. In reality, things are a bit more generic in midPoint. Roles are not the only type of objects that can grant privileges. All role-like objects (known as abstract roles in midPoint) have this ability, which means orgs and services can grant privileges too. Also, all the four focal types can have credentials, at least in theory. There is a significant overlap among the capabilities of the four object types. However, the description above is a nice summarization of the purpose for which the object types were created.
|
Tip
|
Policy
MidPoint 4.9 is introducing another focal object type: policy (PolicyType).
While policies can be represented by roles (RoleType) in midPoint 4.8 and earlier, the new policy type brings clarity.
In midPoint 4.9 and later, there is a clear distinction between quite concrete role and very abstract policy.
This is a nice improvement, which improves thinking about roles and policies by optically separating them.
It also looks very good in user interface.
Other than that, roles and policies work exactly the same.
It is a curious thing, that sometimes even such apparently cosmetic change makes a big perceived difference.
We strongly recommend midPoint 4.9 to anyone who plans to heavily use policies, e.g. in deployments that need to address complex
regulatory compliance scenarios.
|
The four basic object types can represent almost anything we are likely to encounter in identity management world. However, it does not mean that the four types fit all object types perfectly. We often need to distinguish various nuances among object types. E.g. we may want to use colors or icons to distinguish between applications, mobile devices and workspaces.
Basic structure of archetype definition is simple:
<archetype oid="00000000-0000-0000-0000-000000000702">
<name>Person</name>
<archetypePolicy>
<display>
<label>Person</label>
<pluralLabel>Persons</pluralLabel>
<icon>
<cssClass>fa fa-user</cssClass>
<color>green</color>
</icon>
</display>
</archetypePolicy>
</archetype>There is a special archetypePolicy container which is very specific to archetypes.
This container specifies characteristics of archetyped objects, which are objects that have this archetype.
In the case illustrated above, the Person archetype is supposed to apply to users who are physical, natural persons (as opposed to virtual personas).
Archetype policy specifies that the archetyped objects have green icon defined by fa fa-user CSS classes.
Each archetyped object has to be referred to as Person.
Plural form Persons is going to be used in lists and collections of archetyped objects.
This is quite a minimal definition of archetype.
|
Tip
|
Font Awesome icons
MidPoint is using Font Awesome icons, which is a nice collection of icons to choose from.
Font Awesome icons are referred to by their CSS classes.
Readers that have some web design experience would understand.
For the others, just search the web for "font awesome icons", choose an icon and look for snipped of HTML code such as <i class="fa fa-user"></i>.
The value of class HTML attribute is supposed to go to the cssClass property of archetype definition.
Of course, midPoint is open source software, therefore it contains only free Font Awesome icons.
|
We have nice little archetype definition now. However, it does not do much just by itself. Archetype has to be applied to midPoint objects to be useful. As we are in midPoint, archetypes are assigned to objects, of course.
<user oid="00000000-0000-0000-0000-000000000702">
<name>anderson</name>
...
<assignment>
<targetRef oid="00000000-0000-0000-0000-000000000702" type="ArchetypeType"/>
</assignment>
...
</user>When archetype is assigned to an object, the object gains characteristics specified in the archetype policy specified in the archetype.
This means that persons are shown using green color in midPoint user interface, as that is specific in the Person archetype.
Archetypes can be managed and create in midPoint user interface as well. Navigate to menu:Configuration[Archetypes].
Archetypes can specify several aspects that affect look, feel and behavior of archetyped objects:
-
Icon, color, labels and similar presentation properties.
-
Object template, which specifies mappings and other details about individual data items of the object.
-
Provisioning defaults, e.g. specifying that all employees should have an account in enterprise directory.
-
Policies to be applied to archetyped objects.
-
Collecting the objects, providing ability to quickly look them up in searches, menu shortcuts, and so on.
Archetypes can significantly influence archetyped objects, as you will see in the rest of this chapter. This ability makes archetypes very useful. Due to their usefulness, archetypes permeate midPoint configurations. Many archetypes are provided as pre-configured (initial) objects out-of-the-box. Archetypes are also seen in prominent places in midPoint user interface. They also provide prime opportunity for customization. Overall, archetypes are to the core of every midPoint deployment.
An object can have more than one archetype, as long as following rules are followed:
-
At most one structural archetype can be applied to object. Structural archetype provides structure to the object, it specifies icon, color, and presentation of the object. In the future, structural archetype may define schema for the objects.
-
Any number of auxiliary archetypes can be applied to object. Auxiliary archetypes provide additional information, functionality and policies to the objects.
Structural archetypes should be used to represent nature of the objects, characteristics that are unlikely to change.
Good examples are Person or Application.
On the other hand, auxiliary archetypes are more like the roles.
They usually represent characteristics that might change, or characteristics that could be combined.
For example, Employee, Student and Volunteer are good examples, as a Person could theoretically be student and employee of a school at the same time, as well as volunteer for certain activities.
Definition of auxiliary archetypes is almost the same as definition of structural archetypes, except for archetypeType property.
<archetype oid="8070c13e-73ff-11ef-b9ac-7beb1c83f753">
<name>Employee</name>
<archetypeType>auxiliary</archetypeType>
</archetype>|
Note
|
Limited UI support
User interface support for auxiliary archetypes is quite limited in midPoint 4.8.
This is the reason auxiliary archetypes are not used often in midPoint 4.8.
In fact, use of birthright roles is still recommended in midPoint 4.8, instead of using auxiliary archetypes such as Employee.
More on that in next chapter.
|
Archetypes are very useful mechanism for setting up presentation of behaviour of objects. Therefore, midPoint contains a set of pre-defined archetypes, ready to be used. Following table describes the most interesting pre-configured archetypes:
| Archetype | Holder type | Description |
|---|---|---|
Person |
User |
Archetype for natural persons. |
System user |
User |
Archetype for system users, i.e. non-person users that are needed for system to work, such as |
Application |
Service |
Archetype for applications, as a basic building blocks for access control. |
Application role |
Role |
Archetype for roles that directly grant access to applications. |
Business role |
Role |
Archetype for roles that represent business concepts. |
System role |
Role |
Archetype for roles that are essential from the system point of view, such as |
There are other pre-defined archetypes as well, mostly for tasks, cases, reports and marks. These are not important for now. There are no pre-defined archetypes for organizational units in midPoint 4.8. More on that later, in a chapter dedicated to organizational structures.
Archetypes influence many aspects of "life" for midPoint objects.
Therefore, it is a best practice to set proper archetype for object as soon as the object is created.
This approach makes it easier to customize behavior of objects later on.
For this reason, we have set Person archetype for all users created by synchronization from HR system.
This is going to be very useful, as we will see in next chapter dealing with object templates.
Similarly, it is recommended to properly set archetypes for new roles, services, orgs and other objects.
Choosing the right archetypes is quite important, as change of (structural) archetypes is a serious matter. Archetypes define many aspects of object character, presentation and behavior. Change of archetype means quite a substantial change of object nature already. In the future, it is very likely that archetypes could define object schema as well, influencing the way the object is composed and stored. Therefore, change of archetypes would mean a change of its very structure. As object schema changes, new mandatory properties would need new values and values of removed properties should be removed. Therefore, there is already a special method to change an archetype in midPoint. In midPoint user interface, there is btn:[Change archetype] button on object details page that starts a special action of archetype change.
Archetypes naturally work as object collections. Therefore, archetypes can be used to conveniently search for all archetyped objects. Simply use the btn:[Object collection] control in the search bar and select archetype you are looking for. Moreover, archetypes can be used to customize midPoint menu, object details panels and other parts of midPoint user interface. Menu items regarding archetypes are already pre-configured in some cases (e.g. menu:Administration[Users > Persons]).
|
Tip
|
archetypeRef
Archetypes are assigned to objects.
While archetype assignment is limited, it is still quite a complex object to deal with.
As archetype searches are common, midPoint needs to execute them as quickly as possible.
Therefore, there is special archetypeRef reference in archetyped objects, point to applied archetype(s).
However, this reference is operational, it is managed by midPoint internally, it should never be changed by midPoint users.
Archetypes should be managed solely by changing assignments.
Yet, the archetypeRef may still be useful, e.g. when searching for archetyped objects using scripts or midPoint REST interface.
|
Archetypes are abstract roles.
Similarly to orgs and services, archetypes behave like roles.
Inducements in the archetype apply to all archetyped objects.
This is very convenient method to apply default settings to broad classes of users.
Pre-defined Person archetype is especially suitable for this purpose.
Inducements added to Person archetype can be used to set up default accounts and roles for users.
Our deployment at ExAmPLE company goes quite well. We have HR synchronization set up. We have also connected LDAP server and correlated the accounts. However, the LDAP setup is not complete. When new employee is hired, midPoint takes the HR record and creates a user. However, the user is not going to get an LDAP account, as every employee should.
As archetypes work as roles, and all employees have Person archetype, we can easily do what we need.
Setting up default accounts for employees is a simple matter of adding an inducement to the Person archetype.
<archetype oid="00000000-0000-0000-0000-000000000702">
<name>Person</name>
...
<inducement>
<construction>
<!-- OpenLDAP resource -->
<resourceRef oid="8a83b1a4-be18-11e6-ae84-7301fdab1d7c"/>
<kind>account</kind>
</construction>
</inducement>
</archetype>When HR record is synchronized to midPoint, user is created, Person archetype is applied, inducement is processed and LDAP account created.
This configuration almost works, except for one little detail.
New user’s username is generated from employee number.
This is not very convenient for users.
However, we still need one more trick to get there, which is explained in the Focus Processing chapter.
In addition to accounts, archetypes are useful for setting up default roles and privileges.
E.g. Person archetype can be used to grant access to midPoint user interface to all users by adding inducement to End user role.
<archetype oid="00000000-0000-0000-0000-000000000702">
<name>Person</name>
...
<inducement>
<targetRef oid="00000000-0000-0000-0000-000000000008" type="RoleType"/>
</inducement>
</archetype>Archetypes are ideal for provisioning birthright privileges, access rights that are automatically given to users based on their type.
Simply speaking, meta-roles are roles applied to other roles. Ordinary role applies its characteristics to a user. Meta-role applies its characteristics to another role. This is perfectly possible in midPoint, as role can be applied to almost any midPoint object. Then why not apply a role to another role? This may seem like a pretty useless exercise, but the truth is that meta-roles are tremendously useful.
History is repeating, they say. The fact is that repetition is daily bread in almost all identity management deployments. E.g. many business roles have something in common. For example, the business roles have similar approval process. There may be role classes that have similar exclusion policies that are part of global segregation of duties (SoD) policy. There are roles that are tied to entitlements in a systematic way, and so on. Roles, organizational units, services and other role-like objects tend to be quite similar. Therefore, applying meta-roles to them can be very useful.
Archetypes are a prime example of meta-roles.
Business role archetype is a meta-role that applies its policies to all business roles.
<archetype oid="00000000-0000-0000-0000-000000000321">
<name>Business role</name>
<inducement>
<!--
Policies, rules, constructions and other things
that should be applied to all business roles.
-->
</inducement>
</role>Statements in the inducement above are applied to business roles, as opposed to ordinary role where inducements are applied to users.
Similarly, Application archetype applies its inducements to services.
This ability makes archetypes ideal for addressing slight differences in behavior of various object types.
For example, we probably would like to synchronize applications with enterprise application inventory system.
However, that does apply to applications only, and not to other services.
Therefore, Application archetype is ideal place to configure this policy.
|
Tip
|
Reuse in midPoint
Meta-roles are one of the stranger concepts of midPoint, but it goes well with midPoint philosophy.
Meta-roles are roles that are applied to themselves.
This is a reuse of an existing mechanism to create something new.
This is very typical for midPoint.
We always try to reuse an existing mechanism instead of reinventing a new one.
The result is quite unexpected and surprising sometimes.
When we have designed the role-based access control system for midPoint, we haven’t thought about meta-roles at all.
The meta-roles just appeared as a consequence of the design, a consequence that was absolutely unexpected.
Fortunately, we have quickly realized the potential that meta-roles have, and we have put them to a full use.
|
It may be difficult to understand the concept of meta-roles from such a short and very abstract description. Do not worry. As meta-roles are often used in midPoint, we will get back to the meta-roles on several occasions. Meta-roles often allow simplification of complex problems by creating a very elegant solutions. For now, it is enough to remember that roles can be applied to almost anything in midPoint, including themselves.
Archetypes are very flexible, even perhaps a little bit too flexible.
Theoretically, an archetype can be assigned to anything, any type of object.
However, it does not make much sense to use Person archetype on roles or services.
Therefore, midPoint has to constraint the ability to use archetypes.
MidPoint has assignment relation mechanism that can be used to fine-tune the application and use of archetypes.
This mechanism can be configured by using assignmentRelation clause.
<archetype oid="00000000-0000-0000-0000-000000000702">
<name>Person</name>
...
<assignment>
<identifier>holderType</identifier>
<assignmentRelation>
<holderType>UserType</holderType>
</assignmentRelation>
</assignment>
</archetype>In the example above, the assignment relation clause specifies holder type for archetype.
Simple speaking, this is the type that an archetype can apply to, a type that can hold assignment to the archetype.
In this case, the holder type is constrained to user (UserType).
Hence, Person archetype can be applied to users, and no other object type.
Assignment relation is important for maintaining some sanity in the vast flexibility of midPoint platform.
As we know that Person archetype should be applied to users, we can easily detect errors when the archetype is accidentally applied to other object type.
Assignment relation is even more important for the user interface.
Due to the assignment relation specification above, midPoint user interface knows that it makes sense to offer Person archetype as an option for creating new user, but this archetype does not make sense not for org or role.
Several parts of midPoint user interface adapt to assignment relation specified in archetypes.
Clever reader has surely noticed that assignment relation clause is enclosed in an assignment.
This has certainly some deeper meaning.
Clever reader is right once again.
As assignment relation is placed in assignment, it applies to the archetype itself.
In the case above, specification of the holder type applies to the archetype.
Archetype Person can be applied to users (UserType).
On the other hand, we can put assignment relation clause in inducement.
In that case, the clause would apply to archetyped objects instead.
Let’s consider an example of Business Role archetype.
<archetype oid="00000000-0000-0000-0000-000000000321">
<name>Business Role</name>
...
<assignment>
<assignmentRelation>
<description>This archetype can be assigned to role.</description>
<holderType>RoleType</holderType>
</assignmentRelation>
</assignment>
<inducement>
<assignmentRelation>
<description>Business role can be assigned to users.</description>
<holderType>UserType</holderType>
</assignmentRelation>
</inducement>
...
</archetype>There are assignment relation clauses both in assignment and in inducement. The clause in assignment applies to the archetype itself. It states that the archetype is supposed to be applied to roles. We have seen that already. The other clause is placed in inducement. This clause applies to all archetyped object, which means to all business roles. It states that business role can be given to users only, it cannot be given to orgs or services.
This is the principle of meta-roles in practice.
Archetypes are meta-roles, applied to roles.
In this case Business Role archetype is a meta-role that applies to roles, which gives these roles character of business roles.
Assignment relation is an important mechanism to maintain order in amazing flexibility of midPoint platform, especially when this mechanism is coupled with archetypes. Together, this two mechanisms can form variety of object types and relations between them. This is the foundation allowing midPoint to describe vast diversity of identities in the wold around us.
While the underlying mechanism of meta-roles is part of midPoint for a very long time, archetypes were added a bit later. Archetypes embrace the meta-role mechanism, making it nicer and easier to use, while adding some features of their own. While archetypes in midPoint {midpointversion} are already quite powerful, there are still plans for improvement.
Archetypes are supposed to exert tighter control over character of the archetyped object in the future. This means that archetype should control lifecycle of the object and further details of its presentation and behavior. However, perhaps the most important future function of archetypes is to control schema of archetyped objects. As we have seen in Schema chapter, midPoint schema can be extended with custom properties. However, such schema extension is global, it applies to all objects of a given type. Vision for future midPoint gives similar ability to archetypes. In later midPoint versions, archetypes should be able to specify schema extension for archetyped objects. This could make schema management more elegant, cleaner and much more manageable. However, there are also downsides. As archetypes can change, this means that object schema can change as well. New schema applied by new archetype may include mandatory properties, which need values. Scheme of old archetype might have included properties that are not part of new schema. Values of such properties must be discarded, which means destructive operation. There are other complications as well - none of them unsolvable, but none one them easy to solve either.
That is one of the reasons why change of archetype is a special operation in midPoint user interface. This operation is quite simple in midPoint {midpointversion}, however we expect that it will get much more complex later on. Possible consequences of archetype change also led us to limit the application of archetypes. While archetypes are abstract roles, unlike other abstract roles, archetypes can only be assigned to objects directly. Archetypes can only be referenced from an object in a plain, non-conditional, direct assignment, just like we have seen at the beginning of this chapter. Indirect use of archetypes (e.g. referencing archetypes from inducements) is not supported, and it may lead to unforeseeable behavior. When it comes to archetypes, perhaps the best strategy is to keep things simple. At least for now.
Archetypes make midPoint nicer and more elegant. Icons, colors and other nuances that archetypes bring make it easier to navigate midPoint user interface. However, most importantly, archetypes make midPoint data more descriptive. Archetypes can be used to describe variety of identity types, including all the flavors and nuances of the diverse world around us.
Archetypes are build on deep underlying principles of midPoint platform, such as the meta-role mechanism. Yet, archetypes are giving such deep mechanisms a nice human-friendly form.