Motivation

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.

Archetypes

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:

Primary Object TypeArchetype
UserType

Employee, Contractor, Partner, Supplier

Student, Teacher

OrgType

Company, Division, Department, Section

Project, Team, Workgroup, Task force, Committee

Class, Research team

RoleType

Business role, Application role, Metarole

Teaching engagement

Protection scope, Consent target

ServiceType

Application, Device, Printer

Provider, Network

Web API endpoint

Archetype Definition

Archetype definition is a special midPoint object (ArchetypeType). Being a midPoint object, archetype has an 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 functionality is a synergistic feature. It is designed to fit together with existing midPoint features, such as RBAC and organizational structure.

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.

MidPoint 3.x used mechanism of subtype to implement parts of the functionality provided by archetypes. Archetypes should provide replacement for subtype functionality (with some limitations). Subtype will still work in midPoint 4.x, but it is no longer a recommended mechanism - except for assignment subtype, which is still useful. Subtypes will be most likely deprecated sometime during midPoint 4.x lifetime and the plan is to remove it completely in midPoint 5.0.

Historical note: the original idea was to implement archetypes as an extension of the subtype functionality. But it was discovered during the detailed design of archetype functionality that we can do it much better. Current form of archetype functionality fits perfectly with existing midPoint features and it is much more powerful than originally planned. Therefore the idea of subtype-based archetypes was dropped.

User Interface Support

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.

Archetype functionality is a synergistic feature. It is designed as an natural extension of another midPoint feature: Object Collections and Views. It is expected that the capabilities of object views will improve in time. There are expected user experience improvements, better customization support and so on. Each time collections&views are improved then also archetypes will get the same improvements.

Archetypes allow to specify 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.

Configuration

See Archetype Configuration page for configuration details.

Future of Archetypes

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

See Also