Policy-Driven Role-Based Access Control

Role-based access control (RBAC) methods have been known for several decades. However, the usual method that comes to a mind when "RBAC" acronym is used is static NIST-like RBAC method from early 2000s. Traditional RBAC is static. assignment of roles to users and static set of privileges (entitlements) in each role. A role has a fixed set privileges, specified by system administrator. Roles are assigned to users using static assignments, a user is either assigned to a role or not assigned. Privileges and user assignments do not change by themselves, system administrator or a similar privileged entity has to change them if needed. This is no small effort, as there are usually a lot of roles to maintain. It is no exception that there are more roles than there are users, which somehow spoils the original idea of reducing system administration effort.

Static RBAC models have numerous drawbacks, including role explosion, huge role maintenance and access review effort, tendency for over-provisioning and so on. It is quite clear that static RBAC methods are not suitable for current access control needs. However, it does not mean the RBAC idea is wrong, or that the concept is completely useless. In fact, the whole role-based idea has many advantages, as we will see later. All that RBAC needs is more flexibility, it needs to be a bit more dynamic. That is exactly what midPoint dynamic RBAC mechanism does.

MidPoint roles are not static. Quite the contrary. Role definition can be dynamic in several dimensions:

Both relation and role parameters are efficient method to reduce role explosion.

Traditional RBAC assumes that users are assigned to roles by some kind of higher authority. However, it is much better to use algorithmic, policy-driven assignment of roles as much as possible. If we can specify a condition when a specific role can be assigned to specific user, it can be done automatically. Even better, we can reverse the condition. We can automatically unassign the role when it is no longer needed. This is an efficient way to combat huge certification effort.

There are several "layers" that can be used to dynamically manage role membership in midPoint:

Dynamic assignment is a crucial mechanism which makes RBAC feasible. Manual management of user-role assignment is one of the most critical problems of static RBAC. Automatic management of this tedious task makes life much easier.

The idea is to make most user-role assignments dynamic, automate all that can be automated.

Individual midPoint features are certainly attractive. However, it is only when they all come together to create very powerful mechanism. Role expressions, conditions, relation and parameters provide dynamic behavior of roles, making them smart. Archetypes, organizational structure and autoassignment expressions control dynamic role assignment. Then there are policy rules that can be used for variety of purposes. On one hand they implement classic features, such as segregation of duties. They can be used to implement advanced features, such as micro-certifications. Moreover, policy rules can be used as a last-resort mechanism to implement almost any kind of policy constraint.

Roles, archetypes, organizational structure, policy rules and other midPoint mechanism all together form a consistent policy to control access to your applications.

In midPoint, we like universal mechanisms and approaches that can be applied to wide variety of cases. This passion lead to the creation of policy-driven RBAC in the first place. While designing our dynamic role-based mechanism, we have figured out that it has far wider applications that just RBAC roles. We have applied the same approach to organizational structure as well. Therefore, divisions, sections, teams, projects, cooperating organizations and business partners can act as roles. There is no need to set up a rule to apply Marketing staff role to every employee in the Marketing department. The department itself can act as a role, providing necessary privileges directly and automatically. Similarly, midPoint services acts as role as well. Therefore, applications, microservices, mobile devices and "things" can automatically grant access to themselves when assigned to user. Archetypes also act as roles, providing direct and easily-manageable birthright access to various types of objects. The same mechanisms that work for roles can also be applied to other midPoint concept, creating a very flexible and extremely powerful policy platform.

Benefits of dynamic, policy-driven RBAC over a traditional static RBAC are quite clear. However, policy-driven RBAC has significant advantages over other approaches as well, such as policy-based access control (PBAC) or attribute-based access control (ABAC).

In policy-driven RBAC the overall policy can be divided to manageable parts. Each role is a self-contained policy statement. It contains expressions that govern privileges granted by the role. It also contains autoassignment rules, that control assignment of the role to users.

policy-driven RBAC naturally divides the policy to roles - small objects that can be easily managed. Each role can have its own independent lifecycle, it can be updated as an atomic unit. Naturally, a role can be related to other roles, e.g. an application role can be part of business roles. This means that change in one role can have indirect effects. However, impact of a role change can be estimated, as the role hierarchy is known. Moreover, there is simulation mechanism in midPoint which can be used to analyze impact of role modification before it is applied.

As they say: there is an exception to every rule. It is no surprise that there will be exceptions to a policy as well. Whether it is access privileges for CEO, emergency access required to resolve a security incident or a bunch of legacy applications that are being decommissioned, there will be access control aspects that do not easily conform to the policy. It is not desirable, yet it is necessary to keep business going smoothly. Other mechanism such as PBAC or ABAC provide no choice that to incorporate such exceptions into the policy itself. However, this effectively legalizes the exceptions, removing incentives to ever sort them out. Moreover, it significantly complicates the policy. This is not a good approach. There is a better way to manage such exceptions in midPoint. Exception can take a form of a special-purpose role which is manually managed and assigned. The role can be clearly marked as being a policy exception, it can be reported, shown in dashboard, it can have assigned a person responsible for clearing it up, it can have an expiration date. It is not swept under the carpet by legalizing it. We clearly admit that there is a policy issue that has to be resolved.

Perhaps the most significant benefit of policy-driven RBAC is its practicality. policy-driven RBAC is still an RBAC - it is compatible with static RBAC. Many organizations still use static RBAC. Such role structures can easily be represented in midPoint. Even organizations that do not use RBAC at all can automatically import static entitlements to midPoint in a form of application roles. This provides a nice starting point to build up a dynamic policy-driven system from the bottom up. Dynamic RBAC can co-exist with static RBAC in midPoint, providing a feasible evolutionary path. Policy-driven approach can be implemented using an incremental approach, without a need for disruptive big bang.

Support for the bottom-up approach is much more important that it may seem. It is a public secret that in too many organizations nobody knows what access employees should have. There is no single person that knows the policy. The policy is amalgamation of many guidelines, processes, rule books, regulations and management decisions, many of which are not documented at all. Codification of such policy in exact, complete, understandable, up-to-date and machine-executable form is next to impossible. However, all hope is not lost. Even though it may not be feasible to determine the exact policy in its entirety, there are data that we can build on. We have current role assignment data. As long as our organization works properly, we can safely assume that majority of the roles were assigned according to policy. We can use this information to mine the policy, to determine what the policy actually is. Of course, it is only approximate technique. Current access is most likely over-provisioned, the policy is not applied in a perfectly consistent way and so on. However, mining can give us practical approximations to start from. Mined policy can be incrementally refined, reviewed and optimized. It is better to have a practical approximate approach than to rely on exact yet infeasible method. Done is better than perfect.

MidPoint 4.8 brings role mining mechanism. Role mining allows to mine role definitions from existing entitlement data. Role definitions form first part of our policy-driven RBAC system. Later on, we plan to introduce policy mining, which will provide mechanism to add the second part: role assignment rules. We rely on machine learning techniques to discover the policy in the dark pool of your identity, entitlement and role data.

MidPoint policy-driven RBAC mechanism may look impressive so far. Yet, midPoint goes one more step further. We have done quite an unprecedented thing. We have applied roles to roles, creating meta-roles. The concept of meta-roles is used to implement midPoint archetypes. Archetypes are used to distinguish various object types and subtypes in midPoint. Simply speaking, Archetypes give us ability to have employees, students and contractors in midPoint, giving each user type a distinctive behavior. In this case archetypes are similar to roles, usually used to provide birthright access to users.

However, interesting thing happens when archetypes are applied to roles. It does not look entirely extraordinary at the first sight. There are the usual Application role and Business role archetypes, distinguishing individual role types. However, archetypes behave as roles themselves, which are now applied to other roles. We have got meta-roles, applying RBAC principles to RBAC itself. For example, Application role archetype can be used to automatically grant access to application catalog to any owner of any application role in the system. This can be done with a single statement in Application role archetype.

Similar method can be applied to organizational units. Archetypes are used to distinguish types of organizational units: divisions, projects, workgroups. Organizational units behave like roles in midPoint. Membership in a project can automatically grant necessary privileges for project members. We already know that. Now, how do we grant a specific privilege to all managers of all projects? One way would be to copy and paste privilege grant to all the projects. However, we really do not like duplication of work in midPoint. We would rather specify that grant in Project archetype, which is automatically applied to all our projects. Now we can have the policy statement specified in one place, applied consistently to all the projects that we have. This is policy-based access control at its best, is it not?