midPoint is used a (very) extended version of Role-Based Access Control (RBAC) mechanism. RBAC is originally defined as static structure. 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. Therefore the role can adapt to the attributes of user that has the role or even the role assignment itself can be parametrized.
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 above illustrates the basic mechanism of roles. Users are assigned to the roles using a mechanism called assignments (see below). Roles define access rights on a specific set of resources. The figure illustrates a situation that can be described as:
The (simplified) role definitions in XML is as follows:
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 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
Account Construction XML structure. It basically defines the resource in which the account has to be created, account type and 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 account types (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.
Figure: Implied account attributes
The example illustrates following case:
Expressions are used to define dynamic implied account attributes. The default expression language is XPath, chosen for its simplicity and popularity (e.g. it is also used as a default expression language in BPEL). However, the expression model is extensible and more expression languages may be added in the future.
The XML role definition illustrated by this example is as follows:
Implied account attributes usually do not 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.
TODO: Point to advanced explanation and examples
Implied Account Entitlements
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 the concept of implied entitlements, illustrated in following diagram.
Figure: Implied account entitlements
The example illustrates following case:
The XML role definition is as follows:
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.
See Assignment page for more details.