Authorization, or access control if you like, is one of the main pillars of Identity Access Management (IAM). It is therefore pertinent to ask why this problem area is not pouring over with flexible, easy to manage solutions. Rather, the history of role based access control (RBAC) is still casting its long shadow onto IAM, reminding us all that authorization is not a trivial problem.
However, I believe we now have the opportunity to step out of the shadow, with the emergence of a new breed of authorization systems and philosophies. In this post, I describe what I believe is the underlying shortcoming of RBAC, and how this new breed of authorization systems avoid falling into the same trap by being based on open data models and dynamic authorization methods. And at the forefront of these, I see graph based access control systems as the superior class of solutions.
RBAC as a backdrop
To understand the requirements for authorization systems, I believe RBAC makes a good study. The idea of RBAC is that all access decisions can be made based on roles assigned to people trying to access systems and data: If you want to perform some action on some resource, your user has to belong to a certain role.
The idea behind this approach is good: the role based model is easy to understand, and I also believe that it can cover a large number of access control scenarios. However, it has some significant shortcomings; the following exposition is not exhaustive.
The underlying problem is that the RBAC data model is fixed and very compact. This forces the users to make quite severe abstractions of their business when they are entering data into the RBAC model. And since making abstractions is about removing information, you lose information when you populate the RBAC model; the model contains less information than, say, your own database where you have modelled your business.
Due to his discrepancy in information content, before long, you will be faced with an access control question that cannot be answered by the abstract, limited data you have modelled into the RBAC database. And moreover, since you have made a choice for how concepts in your business maps to concepts in the RBAC system, there may be no clear way to model the required new data along the same mappings.
For example, the central concept in RBAC is the role, and a base assumption is that roles are coarse grained. This is what makes the model so enticing in the first place: you only need a small number of roles to manage a large number of users. However, coarse roles soon become a problem when you are faced with modern needs and requirements for fine grained authorization.
Furthermore, roles are static: Say that you have a resource that can only be accessed by users above the age of 18. If you register in the system at the age of 16, you will be assigned the below_18 role, and there is nothing in the RBAC system that detects when you become of age, causing a reassignment to another role. This must be dealt with from outside RBAC.
Now, an authorization system that cannot do authorization is a show-stopper, so you have to make it work. And that is when you start using the roles and data structures in ways you never meant to. The classical example is when the principle of coarse roles is abandoned in an attempt to support fine grained authorization. This ad-hoc approach solves the problem, but it leads to an increase in roles and complexity that makes the RBAC system hard to maintain and administer. Indeed, if the approach is followed all the way through, the end result is a list of roles that is equivalent to an access control list: one role for each entry you would have in the ACL. The situation is commonly referred to as the role explosion problem of RBAC, and may lead to very high administration and maintenance costs.
And, if you are faced with needs for dynamic authorization in changing contexts, such as rules depending on values and relations in the data, or the current authentication level of the user, or different times of the day, or depending on the geolocation of the user. Then there is no way of solving this within the RBAC model framework. And, since the model is fixed, you cannot modify it to answer your problem.
Generalising beyond RBAC
The above challenges of RBAC are well known, but history teaches us an important lesson. You cannot use a predefined, universal model for access control and then expect that model to cater for every possible future access control need. Personally, I think it is possible to use even simple models like RBAC for local access control, and by local, I mean that you can use this model for a small, designated part of your access control needs. And you may even be able to cover all of your access control needs with a patchwork of small RBAC models. (This is not recommended, by the way). But if you try to extend any of these models to the neighbouring system or a larger business domain, not to mention the entire enterprise, there is a good chance you will run into the types of problems mentioned above.
The solution to the problem is as easy as it is daunting: You should not use a dedicated authorization data model to build your authorization system. Rather, you should model your business the way it is. And moreover, you should build rules directly on top of that data governing which users have access to what under which circumstances. This is essentially a guarantee to avoid the problems just described, because any question you can answer about your business is already present in your business data. And any dynamic context that your business is facing can also be presented in the data, and can be evaluated by the rules executing on that data.
The Identity Knowledge Graph and KBAC to the rescue
IndyKite’s solution to the authorization problem is the Identity Knowledge Graph and Knowledge Based Access Control (KBAC). The Identity Knowledge Graph is a graph database where you import all the identity- and business data you want, and model it the way you want, reflecting the needs of your business. The point is that you can import all the data that is required to answer the authorization requests you need, structuring the data exactly the way you think is most natural for the business you are running and the authorization requests you are expecting to handle. The Identity Knowledge Graph is particularly useful in situations where the authorization decisions depend on information from disparate or distributed sources, since all this information can be imported into the Identity Knowledge Graph to provide a unified view of the authorization context.
The authorization rules are defined in terms of policies in the KBAC system. To respond to an authorization request, the KBAC system executes the policies against the Identity Knowledge Graph to ensure that the required preconditions for authorization are fulfilled. Any temporal or other fluctuating data that is reflected in the graph is automatically taken into account, providing what can best be referred to as dynamic context policy evaluation.
And, if you need to import more data to answer more authorization requests, you can just do that. There are no predefined authorization models that force you to make painful abstractions from your business domain. Indeed, graph databases excel over relational databases in their flexibility in adding new data and relations at need, not being bound by database schemas.
Find out more about IndyKite´s Knowledge-Based Access here: www.indykite.com/kbac
