Archetypes

There are several basic concepts in identity management that are used and re-used all the time: user, role, organizational unit, service, assignment. MidPoint has excellent out-of-box support for these concepts. And as midPoint is based on extensible schema from the day one, those concepts can be easily customized and extended with custom properties. However, there are many types of users: employees, contractors, partners, customers. And there are many types of orgs: company, section, division, project, workgroup and so on. MidPoint archetypes can be used to sort object to such subtypes. Each archetype can have distinct look and feel, but it can also define specific behavior and policies. Archetypes make midPoint much more flexible without the need for complex customization or coding.

Simply speaking archetype is a well-defined object subtype. Employee, contractor, project, workgroup, application, …​ each of them is an archetype. The idea is that archetype builds on top of existing midPoint types such as User, Org or Role. A project is just a special case of organizational unit. As is division, section, company, workgroup or any other concept that groups identities. An application is a special case of service. As is mobile device, printer, cloud service, web API endpoint and so on. All those concepts are just specializations of the object types that midPoint already has. And there is actually enormous advantage to reuse existing midPoint concepts. If projects are modeled as organizational units then they "inherit" all the functionality of an organizational unit out-of-the-box. Therefore projects can have managers, they may be used for delegated administration, they can grant privileges to members and managers and so on. All of this is already implemented for organizational units and all of this can be instantly reused for projects. In a similar fashion application can inherit existing functionality of service (e.g. ability to grant privileges). This kind of reuse is very convenient and it is also extremely powerful mechanism. Following table lists commonly-used archetypes and their mapping to primary midPoint object types:

Archetypes are the primary tool to define a birthright provisioning. Archetypes behave as roles. Therefore, any privileges specified in archetype inducements are automatically applied to all the objects that have the archetype. This approach can be used to apply birthright to the objects, e.g. it can specify baseline privileges for all employees or students.

Moreover, archetypes may work as metaroles, specifying common behavior for object types. For example, Project archetypes may specify common behavior for all projects, including baseline authorization for project members and managers. Overall, archetypes provide very flexible and powerful mechanism to specify birthrights.

Archetype definition is a special midPoint object (ArchetypeType). Being a midPoint object, archetype has a natural persistent identifier: OID. OID of the archetype definition is also identifier of archetype itself. Each object of that archetype will contain archetype definition OID. E.g. every employee will contain OID of employee archetype definition object. This OID is used internally by midPoint to process archetypes. But it can also be used for searching objects of a particular archetypes by the custom code or midPoint API clients.

Archetype definition are abstract roles, which means they essentially work as a role. To apply an archetype to an object simply assign archetype to that object as you would normally assign a role. From that point on archetype applies to that object. Archetypes being abstract roles makes them really powerful. That means archetypes may work as metaroles. Or it may the other way around: archetypes may be assigned from ordinary roles or orgs.

Archetype definition is a first-class midPoint object, therefore it has all the usual advantages: it can be organized, delegated administration can be applied, it can be owned, it can have managed lifecycle, it can be localized withing a tenant and so on.

Support for custom archetype presentation is an inherent part of archetype functionality. Each archetype can specify details of object presentation, such as custom object icon and color. MidPoint user interface will display archetyped objects with that icon and color. This makes it easy to distinguish employees from contractors and business roles from metaroles.

Archetypes are integrated with views. Archetypes can be used as an implicit collection. Therefore it is easy to set up a view that will display all employees, business roles and so on. List of all archetyped objects can be available right from midPoint menu. Archetypes can also be used with collections. MidPoint support some kind of inheritance of collections. Therefore it is easy to set up collections such as "active employees" that combines archetypes with additional search filter.

Archetypes allow specifying assignment relations. This means that archetype can limit the scope of objects and relations that are used in assignments to the archetyped object. For example, business role may specify that it can be assigned to any user, but only employees may be owners and approvers of the role. Except for that no other assignments are allowed. This is also supported in the user interface. The user interface will render appropriate buttons for the archetype and limit assignment selection dialogs.

See Archetype Configuration page for configuration details.

MidPoint 4.0 provides quite a rich archetype functionality. However, this can still be improved. See Archetype Improvements (Planned Feature) page for the details.

This feature is related to the following compliance frameworks: