Archetypes

Archetypes in midPoint are a way to define types within types. They serve as a kind of subclassification of objects like users, roles, or organizational units. You can think of archetypes as semantic labels that describe what a specific object represents in your organizational context.

There are several basic concepts in identity management that are used extensively: user, role, organizational unit, service, assignment. While midPoint has excellent out-of-box support and customization options for these concepts, they break further down into more specific subtypes that have distinct meanings and behaviors. For example, there are many subtypes of users (employees, contractors, partners, customers) and orgs (company, section, division, project, workgroup).

This is where archetypes come in. They are are designed to sort objects to such subtypes. Each archetype can have a distinct look and feel, but it can also define specific behavior and policies. Archetypes do not replace midPoint object types like users or roles, instead, they extend them to express their business meaning. In other words, archetypes give structure and semantics to midPoint objects.

Archetypes make midPoint much more flexible without the need for complex customization or coding.

Archetypes are well-defined object subtypes. They build on top of existing midPoint object types, such as User, Org, or Role to provide more specific classifications.

For example, employee, contractor, project, workgroup, and application are all examples of archetypes. A project is only a special case of an organizational unit, much like division, section, company, workgroup, or any other concept that groups identities. An application is a special case of a service, same as 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.

There is an enormous advantage to reusing the existing midPoint concepts. If projects from our example were modeled as organizational units, they would "inherit" all the functionality from an organizational unit out-of-the-box. This means that projects can have managers, they may be used for delegated administration, they can grant privileges to members and managers, and so on. Whatever is already implemented for organizational units, can instantly be reused for projects.

In a similar fashion, an application can inherit an existing functionality from a service (e.g., the ability to grant privileges). This kind of reuse is very convenient and extremely powerful.

The following table lists commonly used archetypes and their mapping to primary midPoint object types:

For example, UserType can be further classified using archetypes as follows:

Archetypes may work as metaroles.

To apply an archetype to an object, assign the archetype to that object as you would normally assign a role. Once assigned, the archetype applies to that object.

This mechanism can also be reversed, and archetypes may be assigned from ordinary roles or orgs.

An 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 a managed lifecycle, it can be localized within a tenant, and so on.

Archetypes are the primary tool to define 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 birthrights to objects. For example, archetypes 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 a very flexible and powerful mechanism to specify birthrights.

Support for custom archetype presentation is an inherent part of archetype functionality. Each archetype can specify details of an 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, for example, employees from contractors, and business roles from metaroles.

Archetypes are integrated with views, and they can be used as implicit collections. Therefore, it is easy to set up a view that will display all employees, business roles, and so on. The list of all archetyped objects can be available directly from the midPoint menu.

Archetypes can also be used with collections. MidPoint supports a form of inheritance for collections which enables you to set up collections such as "active employees" that combine archetypes with additional search filters.

Archetypes allow specifying assignment relations. This means that archetypes can limit the scope of objects and relations that are used in assignments to the archetyped object. For example, a 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 for configuration details.

See Archetype Improvements (Planned Feature) for the details.

This feature is related to the following compliance frameworks: