There is a better solution in midPoint. MidPoint has several built-in object types such as roles, orgs, and services. Those data types are built to be extensible and in fact, they are quite generic. The role does not mean just "role in strict RBAC sense". In midPoint, the concept of "role" is much broader. MidPoint roles can easily be used to model RBAC roles, but also job categories, job titles/positions, qualifications, competency certifications, achievements - and even data protection consents. Orgs and services can be used in a similar way:
|Object Type||Can be used to model|
Functional organization structure (company, division, section)
|Service||Server, virtual machine, network service (e.g. application server), application, cloud service|
Mobile device, printer, "thing" (IoT)
Roles, orgs, and services are what we call abstract roles. Which means that all of them behave like roles to some extent. E.g. all of them can be assigned to users, all of them can be subject to policy rules, membership, authorizations and governance policies are evaluated for all of them in a consistent fashion and so on. Therefore there are many benefits:
There is yet another drawback: RBAC roles, authorization roles, job titles - they all have the same object type. They are all
RoleType. How to tell them apart? There is also a mechanism for that: Subtype Archetypes. Subtypes Archetypes can be used to distinguish objects of the same type. Subtypes are completely in hand of the deployer, therefore they can be designed and customized as needed. Future midPoint versions will evolve the concept of subtype even further with Archetypes and Object Collections and Views.There is one more mechanism that can be applied to custom object types: , customize its presentation and behavior. Archetypes are also metaroles. Metaroles are roles that are applied to other (abstract) roles. Therefore metaroles archetypes can be used to assign common behavior for roles, orgs and services. And that is especially desirable when defining a new type of an object. It is quite a common case that all projects will have the same lifecycle: approval of new project creation, establishing project manager, decommissioning of a project and so on. This policy can be defined in "project metarolearchetype" that is assigned to all projects. Therefore it is defined just once and applied everywhere it is needed.
Simply speaking, midPoint does not really need the concept of special generic objects, because every object in midPoint is generic to some extent.