Meta-roles

Last modified 22 Aug 2024 16:29 +02:00
Meta-role feature
This page is an introduction to Meta-role midPoint feature. Please see the feature page for more details.
Table of Contents

Introduction

MidPoint roles are usually applied to users. However, midPoint roles are quite universal things. The roles can be applied to almost any midPoint object. Roles can be applied to users, organizations, services - and even to roles themselves. Which creates meta-roles.

Simply speaking, meta-roles are roles applied to other roles. Ordinary role applies its characteristics to a user. Meta-role applies its characteristics to another role or similar role-like object. This is perfectly possible in midPoint, as role can be applied to almost any midPoint object. Applying roles to another roles may seem like a pretty useless exercise, but the truth is that meta-roles are tremendously useful.

Repetition is daily bread in almost all identity management deployments. E.g. all`business roles have something in common. For example, business roles may have the same approval process. There may be role classes that have similar exclusion policies, as part of global segregation of duties (SoD) policy. There may be roles that are tied to entitlements in a systematic way. Roles, organizational units, services and other role-like objects tend to be quite similar. Therefore, defining the policy in one meta-role and applying that meta-role to many roles can be very useful.

Archetypes and policy objects act as a natural meta-roles, which is clearly illustrated by use of policy objects as classifications. Other archetype:abstract-role[abstract roles] such as orgs and services can act as meta-roles too. For example, applications can be quite useful when used as meta-roles.

Mechanism

Meta-roles are (abstract) roles that are assigned to other roles. In meta-roles themselves, inducement is used to apply policies to target role:

<role oid="6924fb9c-a184-11e9-840e-2feb476335f4">
    <name>Account Manager</name>
    <description>
        This is business role that corresponds to account manager job.
    </description>
    <assignment>
        <!-- Metarole assignment -->
        <targetRef oid="a3065910-a183-11e9-835c-0b6edc3d44c3" type="ArchetypeType"/>
    </assignment>
    <inducement>
        <!--
             Privileges specific to account manager.
        -->
    </inducement>
</role>

<archetype oid="a3065910-a183-11e9-835c-0b6edc3d44c3">
    <name>Business role</name>
    <inducement>
        <!--
            Policies and constructions that should be applied to all
            business roles.
        -->
    </inducement>
</archetype>

In this case, archetype acts as a meta-role. In fact, archetype is an archetype:abstract-role[abstract roles], which means that it is just like a role, with some extra mechanisms that add fancy cosmetics to objects, such as icon and colors. Fancy or not, archetype still acts as meta-role, specifying common policies and characteristics for all objects that have the archetype assigned.

At the first sight, meta-roles may seem similar to role hierarchy. However, it is a completely different concept. The crucial difference is that meta-role is applied to the role and not the user. The inducements in the meta-role often contain policies such as approval policy. There may also be construction clauses that create groups or organizational units, which is often used in generic synchronization. We usually do not want to create a group for each user, but we often want to create a group for a role. That’s what meta-role can do.

See Also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback