Skip to end of metadata
Go to start of metadata

MidPoint 3.5 and later

MidPoint has implemented role request and approval functionality almost from the beginning of the project. However the functionality took the user-friendly form described in this page only in midPoint 3.5. It was further improved in midPoint 3.6.

Selecting Roles

Many traditional Role-Based Access Control (RBAC) theories seem to be based on assumption that there is some kind of all-knowing authority that knows which user should have which role. This approach works in some kind of organizations, but in reality such organizations are very rare. In practice the knowledge about roles and role policies is not centralized. It is rather distributed among many people in the organization: application owners have part of the knowledge, line managers have more bits of knowledge, other parts are maintained by security officers and other specialists. It is almost impossible to analyze this knowledge and specify it in a form of an algorithm that a machine can execute. In addition to that, such policy is constantly changing. Implementing this a fully-automated system is almost always infeasible.

Therefore most identity management and governance systems come with an alternative approach: user are requesting role assignment. The request is then routed through an approval process. If the request is approved, then the requested roles are assigned.

However, this approach requires end users to take part in the interaction. End users are usually not experts on RBAC and they do not have comprehensive knowledge about role design and structures used in the organization. Therefore midPoint has a simplified view of role catalog that is suitable for end users. The role catalog is used to present the roles in a similar way as an e-shop presents the products. The roles are sorted into categories and sub-categories. The user may browse the role catalog and select the roles.

Requesting Roles

When user selects the role to request, she or he may put the role in a "shopping cart". Many roles may be selected in this way. This "catalog and shopping cart" paradigm is quite natural for most end users and it requires little to no training. When all the requested roles are in the shopping cart the user can "buy" them. This starts the role request process. First, the shopping cart content is checked for any potential conflicts and policy violations, such as segregation of duties violations. Policy rules that apply to the roles are evaluated and enforced and the request is routed through an approval process as specified by the policy.

Configuration

The "catalog and shopping cart" user interface is ready made and as most parts of midPoint user interface it automatically adapts to midPoint configuration. For example role catalog set up and authorizations are automatically precessed, therefore only those roles that are actually requestable by the user are displayed. However there are still few things that may need to be customized. The customization of this part of the user interface is described in Role Request and Shopping Cart Configuration page.

See Also

  • No labels