|Table of Contents|
midPoint is using a (very) extended version of Role-Based Access Control (RBAC) mechanism. RBAC is originally defined as mostly static structure of users and roles. The original RBAC defines that user assigned to the role gets all the rights implied by the role. If two users have the same role, they have the same rights. However, this leads to the problem of Role Explosion. We hope to solve that problem by enhancing RBAC model with logic. We add ability to specify expressions in role definitions that determine how and when the role is used. Therefore the role can adapt to the attributes of user that has the role or even the role assignment itself can be parametrized. This allows to construct RBAC structures that are using fewer roles and that are much more manageable.
Roles define similar set of access rights. Roles are assigned to users; a user having a role gets the rights defined by the role. We do not place any constraints on the number of roles assigned to the user or the number of access rights (accounts) defined by the role. All the associations can be thought of as many-to-many. Basic role structure is illustrated in a following diagram.
The diagram illustrates the basic mechanism of roles. Users are assigned to the roles using a mechanism called assignment (see below). Roles define access rights on a specific set of resources. The figure illustrates a situation that can be described as:
Captain Jack Sparrow (User) is a captain (Role). Because he is a captain (Role), he should have account in Maritime Information System (Resource) and Rum Supply Management system (Resource). Captain Jack Sparrow (User) is also a pirate (Role). Because of this he should have account in Rum Supply Management system (Resource) and Shipwreck Cove (Resource).
The (simplified) role definitions in XML is as follows:
<role oid="9991"> <name>Captain</name> <inducement> <construction> <resourceRef oid="8881" type="c:ResourceType"/> <kind>account</kind> </construction> </inducement> <inducement> <construction> <resourceRef oid="8882" type="c:ResourceType"/> <kind>account</kind> </construction> </inducement> </role> <role oid="9992"> <name>Pirate</name> <inducement> <construction> <resourceRef oid="8881" type="c:ResourceType"/> <kind>account</kind> </construction> </inducement> <inducement> <construction> <resourceRef oid="8883" type="c:ResourceType"/> <kind>account</kind> </construction> </inducement> </role>
pirate roles get assigned to Jack, the result should be that Jack has three accounts: Maritime Information System account, Rum Supply Management account and Shipwreck Cove account. Roles imply or construct these accounts. A user assigned to a role will get accounts on all resources that the role implies (unless he already has such accounts).
The implied accounts are defined by the
Construction XML structure. It basically defines the resource in which the appropriate kind of resource object (in this case an account) has to be created. It may also specify the object intent (account type), attribute values and an optional condition.
If two or more roles imply accounts in the same resource, usually only one account will be created. The specific behavior depends on the use of intent definition (still work in progress).
Implied Account Attributes
Traditional RBAC Is Not Enough
The usual use of roles is to imply accounts on the resources and therefore ease the user and account administration by employing RBAC approach. However, this is usually not enough to implement efficient and maintainable identity management solution. The simple approach leads to role explosion. The roles needs to contain parts of logic to make them efficient.
Implied Account Attributes
MidPoint role can also specific attributes for the account, e.g. a specific text in the account description field. Attribute values implied by the roles may be fixed (static), but that is usually not sufficient to avoid a role explosion problem. More frequently the implied attributes are derived from other values, e.g. fields of the User object. The principle is illustrated in the following diagram.
The example illustrates following case:
Captain Jack Sparrow (User) is a captain (Role). Because he is a captain (Role), he should have account in Rum Supply Management system (Resource). The account should guarantee all captains a really BIG mug of rum. The mugs of all captains should come with owner's name on it, so no scurvy seadog would dare to touch that mug.
Mappings and expressions are used to define dynamic implied account attributes. Simple paths are perhaps the most easy to use and most useful in common situations. There are also scripting expressions for more complex cases. The default expression language is Groovy, chosen for its similarity to Java. However, the expression model is extensible, there are several supported scripting languages and even more expression languages may be added in the future.
The XML role definition illustrated by this example is as follows:
<role oid="9991"> <name>Captain</name> <inducement> <construction> <resourceRef oid="8881" type="c:ResourceType"/> <kind>account</kind> <attribute> <ref>rum:mugSize</ref> <outbound> <expression> <value>BIG</value> </expression> </outbound> </attribute> <attribute> <ref>rum:mugName</ref> <outbound> <source> <path>$user/givenName</path> </source> <outbound> </attribute> </construction> </inducement> </role>
The role is implying account on
Rum Supply System resource. It is also implying that the attribute
mugSize of such account should be set to value
BIG and the attribute
mugName should be set to the value of user property
givenName. The figure above illustrate how the attribute values "flow" through the definitions.
The figure above is somehow simplified. In fact the role definitions are using mappings to determine attribute values. It is the same mechanism that is used in assignments and resource schema handling section therefore the same features and limitations apply here. Following diagram provides more detailed illustration of use of mappings in the roles. Each mapping has three parts: source, value constructor and target (see Mapping). However some of these parts can be determined by the context in which the mapping is used. Therefore not all parts of the mapping needs to be present when constructing the roles. This is illustrated in the following diagram where the implicit parts of the mappings are marked by dashed outlines. The first mapping in the following diagram determines target the value of account
mugSize attribute. As it is places inside
attribute section of a
construction definition the system can automatically determine mapping target. Therefore only a value constructor is explicitly defined. In this case it is
value clause that constructs a static value
BIG (see the XML snippet above). The second mapping in the following diagram is slightly more complex. It is using user property
givenName as a source (written as
$user/givenName). This is then passed without any modification through
asIs value constructor. This constructor is the default constructor in a mapping therefore there it is omitted in the role specification above. Mapping target is also determined implicitly by the context.
Please see the Mappings and Expressions page for explanation of basic principles of mapping mechanism.
Implied account attributes usually do not need to define the entire set of account attributes. There may be other roles that may assign different attributes to the same account, more values to the same attributes of the account and even conflicting values. The account may also have existing attributes that are managed by "native" tools (outside IDM) or there may be exceptions from the RBAC policy specified for that account using attribute specification in assignments.
See Advanced RBAC Examples page for more information.
Implied Account Entitlements
Entitlements are still work in progress. This section describe design of a feature that will be implemented in later midPoint releases.
But perhaps the most useful feature of roles is that a role can imply entitlements of account on the resource. E.g. the role can imply that the account of a user having such role will be entitled for (assigned to) the group managers on a specific LDAP server. We are using This feature is quite seamlessly merging the concept of implied entitlements, illustrated in following diagram.
The example illustrates following case:
Captain Jack Sparrow (User) is a captain (Role). Because he is a captain (Role), he should have account in Maritime Information System (Resource) and that account has to be assigned to the
The XML role definition is as follows:
<role oid="9991"> <name>Captain</name> <inducement> <construction> <resourceRef oid="8882" type="c:ResourceType"/> <kind>entitlement</kind> <!-- TODO --> <entitlement objectClass="mis:GroupObjectClass"> <value> <mis:id>captains</mis:id> </value> </construction> </inducement> </role>
Assignment is a generic concept of associating user with the things that he should have or belong to. Assignment may associate user with a role, organizational unit or any other kind of object. However, roles and organizational units are the most common object types that are assigned to a user.
Roles are associated to to users using assignment as illustrated by the following example:
<user oid="0001"> <name>jack</name> <fullName>Jack Sparrow</fullName> ... <assignment> <targetRef oid="9991" type="c:RoleType"/> </assignment> ... </user>
Although most assignments are as simple as the one above the assignments may be much more complex if needed. Assignments may be conditional, limited to a specific time period or provide parameters for the roles.
Simply speaking inducements are indirect assignments. Unlike assignments inducements do not apply to the object in which they are specified. Inducements apply to the object that is has assigned the object which contains inducements. E.g. inducements specified in a role will not be applied to the role itself. The inducements will be applied to the user that is assigned to such role.
In all other aspects the inducement and assignment are identical. Both may contain target reference, construction, condition, etc. Unless you are creating a very complex setup there is a simple rule of the thumb to adhere to:
- Users have assignments
- Roles have inducements
Assignments and inducements are internally identical. And in fact there was only an assignment which was used both directly and indirectly in previous midPoint versions (prior to version 2.2). This simple approach works well as long as we only deal with users and accounts. But the situation gets very complex once we allow roles and organizational units to have associated shadows in a similar way that user has account shadow. This is a very powerful feature that is planned for future midPoint versions. Therefore we had to refine and clean up the data model to allow for greater flexibility and expressive power. And therefore we need both (direct) assignment and (indirect) inducement. While it may seem a bit overcomplicated now having a clean and unambiguous data model will greatly pay off in the future.
Roles contain inducements which have identical structure to user assignments. Therefore a role may be (indirectly) assigned to another role using the inducement. This simple principle creates quite a complex and flexible structure of role hierarchy. An example of a role hierarchy is provided in the following diagram.
roles in an RBAC sense with a concept of resource entitlements such as groups and privileges. This part of identity management configuration was quite a difficult task in the past. MidPoint aims at substantial improvement in this field.
Roles can naturally contain other roles therefore creating a role hierarchy. Role hierarchies can be quite complex both in their structure and embedded logic. As midPoint uses the relative change model it is quite easy to merge values from many roles and therefore it allows creation of very complex RBAC structures. Important parts of the hierarchy are exposed to the expressions in individual roles therefore the role hierarchies can be combined with parametric roles (see below) to support very complex and flexible RBAC-like models.
Roles in traditional identity management systems can only be simply assigned to a user or unassigned from a user. And that's all the flexibility. However this is not enough to efficiently model complex real-world scenarios. For example the role of
Assistant can have some generic parts that are common to each assistant but there may be few parts that are specific for each sub-group of users or even for each individual user. For example identification of a building or department for which the assistant works, date of role activation and deactivation, the financial limit that an assistant is authorized to handle, etc. In traditional systems this leads to a necessity of creating roles such as
AssistantBratislava. This alone is quite difficult to manage because there is also need to
ClerkBratislava and the same for office manager, purchasing manager, ... And when it comes to roles such as
PurchasingManagerAssistant2013NewYork5000 it is quite sure that the solution got a severe role explosion problem.
Parametric roles provide a solution for some of the role explosion situations. Parametric roles allow to specify certain role parameters at assignment time. That means that one
Assistant role is usually enough. The identification of branch, building, department, activation and deactivation dates and other role parameters is specified when the role is assigned to the user. The parameters can vary for each user. The expressions in the
Assistant role can use such parameters and determine the specific account attributes and entitlements dynamically. The assignment parameters correspond to the concept of contract or affiliation that are frequently used in business modelling.
This approach dramatically reduces the number of roles needed for the IDM solution and makes the entire RBAC deployment considerably more manageable.
Parametric roles are fully supported by midPoint core (the "engine" or "IDM Model"). But user interface support for parametric roles is still missing. Parametric roles are inherently flexible and customizable thing. Therefore the user interface cannot be hardcoded to support them. User interface needs to adapt to parameters, that can be different for each and every role. Support for this method is feasible, but it is just not implemented yet because nobody had funded such development. In case that you are interested in funding user interface support for parametric roles please consider purchasing a subscription.
This feature is available in midPoint version 3.0 and later.
Things may get really complicated when IDM solution is meant to synchronize much more than just users and accounts. And midPoint is designed to be very generic about what it synchronizes. E.g. an IDM solution may want to create groups on resource as an representation of midPoint roles. But how does midPoint know on which resources the groups should be created? And how they should look like? This is both easy and complex but there is a very elegant solution. MidPoint already has a mechanism for this: RBAC. And by following midPoint approach we try to apply existing mechanisms as much as possible and practical. Therefore we have applied the mechanism or roles to the roles themselves. Thus creating a concept of meta-roles (and meta-meta-roles and meta-meta-meta-roles, ...) This may sound crazy but it in fact a very elegant and powerful mechanism. See Roles and Policies Configuration and Generic Synchronization for more details.