Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
titlePlanned feature

This page describes a feature planned for future midPoint versions.

This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.


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 is a limitation. There can be only one extension schema for each type. This was more than enough for identity management deployments up until now. But recent identity management and governance deployments are getting much more ambitious and much more complex. What new deployments need is finer granularity. It is not enough to just have organizational unit. We need division, section, project, workgroup, class, etc. It is not enough to have a role. We need business role, application role, meta-role, protection scope, consent target, etc. It is not enough to have service. We need application, device, printer, server, etc.

There is one very interesting point. None of these concepts are new or radical in any way. 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 not a new concept either. It 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.

MidPoint already has partial functionality to implement this approach almost since the beginning, even though existing functionality is a bit rough. There are properties that we like to call "subtypes". User has employeeType property, organizational unit has orgType property and so on. Those properties are designed to distinguish employees from customers and projects from divisions. This partially works in midPoint 3.6 in earlier and it can be used to differentiate subtype behaviour to some degree. There is a plan for midPoint 4.0 provide basic archetype functionality. More improvements are to follow in subsequent 4.x versions.


That is where the idea of archetypes comes in. Simply speaking archetype is a well-defined subtype. Project, workgroup, application, ... each of them is an archetype. For example project archetype specifies that it is in fact an organizational unit with project subtype. The archetype may also define other nuances: are projects hierarchical or flat? What color and icon should be used when displaying projects in user interface? What are the mandatory properties that each project has? What are the possible relations for the project (member, manager, owner)?

The most significant part of this functionality is user interface. It is possible to use project and application concepts even in current stable midPoint versions - and this is actually used in many midPoint projects. But it is not very convenient. The goal of the archetypes is to make it very convenient. Archetypes should promote project, application, device or any other custom concept to the status of first-class citizens. Once archetypes are implemented the projects, applications and other custom concepts will be easy to create and maintain. They should get the same treatment as the basic built-in types.

Image Removed

This feature is also closely related to custom object lists and object collections, which is yet another feature currently waiting for sponsoring.


TODO: what still needs to be implemented:


MidPoint contains basic archetype functionality since midPoint 4.0. While even this basic functionality is very powerful, there is always a room for improvement. This page describes possible archetype improvements for the future.

User Interface

Archetypes are supported in midPoint user interface. And when combined with object views there is a way how to integrate the archetype to user interface so it looks almost the same way as static midPoint object types. But the archetypes are still quite segregated under their primary object types of users, roles, orgs and so on. E.g. archetype views are always second-level menu items. It may be desirable to create a top-level menu items for some archetypes. E.g. we may want to see "Employees" instead of "Users" as a top-level menu item. Or we may want add additional top-level menu item for projects. This is currently not supported, but it can be implemented.

In a similar fashion we may want to have a single page where any "archetyped" object can be created by a single click:

Image Added

Our current thinking is that there may be an elegant way to support this functionality by using Customizable Dashboards.

Archetype Schema

TODO: Per-archetype schema. Need to address issues: support in prism, handling of data for which the schema disappeared (e.g. unassigned/deleted archetype), GUI



TODO: what still needs to be implemented:

  • custom lifecycle for archetypes


MidPoint has most of the core functionality even today, just some small schema-related parts are missing. But the big missing part is in the user interface. All necessary parts can be implemented if planned properly and if there is a funding for this development. In case that you are interested in sponsoring development of this feature, please consider sponsoring the feature or use the influence that comes with midPoint subscription.

See Also