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 3.7 to unify these properties into a common
subtype property and slightly extend the functionality. But more than that is needed to make this really smooth user experience.
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.
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.