Archetypes
feature
This page describes midPoint feature.
Please see the feature page for more details.
|
Since 4.0
This functionality is available since version 4.0.
The functionality was further improved in versions 4.1, 4.2.
|
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 Type | Archetype |
---|---|
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 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.
Synergy
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.
Archetypes and subtype
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.
Synergy: Archetypes and Object lists/views
Archetype functionality is a synergistic feature. It is designed as a 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 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.
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.