|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.
<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).
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
The role can also imply 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.
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.
Implied Account Entitlements
Entitlements are still work in progress. This section describe design of a feature that will be implemented in later midPoint releases.
<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>
Main article: Assignment vs Inducement
See Assignment vs Inducement for more details.
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 and Organizational Structure
This feature is available since midPoint 3.6.
Note: it is perfectly OK for some dynamic roles to be marked as idempotent - even if the role contains complex expressions and conditions. If those conditions depend only on the environment or properties of the focus then their outcome does not depend on their position in assignment/inducement hierarchy and these roles can be made idempotent.