”Kärt barn har många namn”

‍

That Swedish saying translates into something like “Dear child has many names”, perfectly fitting how the authorization market is currently evolving. 

It starts to get crowded in a market that, up until lately, only has been open to a few vendors and some daring early adopters. New vendors (ranging from very small start-ups to Cloud powerhouses) are entering the space at a rapid speed. 

New concepts such as Open Policy Agent (OPA), Google Zanzibar, Amazon Verified Permissions, and Strata’s IDQL are breaking new ground. In addition, new (or even resurrected) access control concepts such as ReBAC, IndyKite’s KBAC, and RAdAC, Just-in-Time-AC that now in different ways, are challenging the more established concepts such as RBAC, ABAC, and PBAC. 

So now, (only) four weeks into my new job at IndyKite, it is time to share some initial perspectives on KBAC and how it fits in the authorization landscape. 

The IndyKite platform includes several IAM services and capabilities that range from onboarding users to authentication, federation, authorization, and data utilization. That means that IndyKite sometimes can’t and shouldn’t be compared to more specialized vendors that only do one thing. Nevertheless, Knowledge-Based Access Control (KBAC) is IndyKite’s definition and dynamic authorization implementation that builds on the platform’s inherent connected data layer, the Identity Knowledge Graph. Hence its name. 

‍

The need for a new model 

Authorization and access control is an incredibly vast and complex area. In most organizations, this is an area that is fragmented and a topic that has been neglected for years. Part of that neglect is that it is hard to formulate a cohesive approach to change and to present a strong business case. No product or service will solve all aspects, and we need to apply a modern strategy to drive the transformation to get to a better place. 

That is, we need to use the current predominant access method, Role-Based Access Control (RBAC), only when and where it makes sense. But we should stop using this method as the only way to grant access. RBAC is, for example, very useful in providing coarse-grained access to an application. For more functional, transactional, and data-level use cases, the externalized and dynamic approach is a far better option. An example of where this new authorization model can and should be applied is in Zero-Trust Architecture initiatives, where dynamic authorization service(s) can enable consistent access control across the different architectural layers.

Here are some simple policy examples to highlight the differences in authorization granularity that will help you better understand the need for a new model (mapped by granularity and flexibility below):

• Alice can access the healthcare application (application access)
• Bob can read patient records (functional access)
• Caroline can read patient data of patients that belong to the hospital where she currently works (data access)
• David can only read patient records of patients that he treats (transaction/record access)
  ‍

‍

Granularity in authorization is a critical point as it’s what separates use cases and differentiates the breadth of authorization approaches. As digital services become increasingly sophisticated, they naturally require more granular authorization. 

A new approach is required that will include a more holistic view than today. It does not need to be one (!) central service, but it for sure needs more central control and governance. By implementing shared authorization services that multiple applications and infrastructure can use to consume authorization, we can start enforcing consistent access controls across the system landscape, building competence in the organization, and using standard processes that will lead us toward better insights and a mature governance model for authorization. 

‍

The way forward - Externalized and Dynamic Authorization‍

The two major identity analyst firms, Gartner and KuppingerCole call the area “Externalized Authorization Management” (EAM) and “Dynamic Authorization Management” (DAM). If we highlight the leading keyword from both firms’ definitions, we get “Externalized” and “Dynamic”. These two words sum up nicely how I would define the area. Authorization should (if possible) be externalized from applications, services, and infrastructure. The dynamics help us with the ability to apply “context” to authorization controls i.e. “Who can access what under which circumstances?” 

This is where KBAC comes in, as a dynamic and externalized authorization approach that handles the complexity required for today’s use cases. Built on the identity knowledge graph, a flexible and dynamic graph data model, KBAC allows organizations to model authorization policies on top of their identity and business domain data. 

The underlying identity knowledge graph provides a “map” of all these identities and their relationship with the business resources. The KBAC policies will then be crafted on top of that data model and use the defined relationships between the nodes in the graph e.g. a user (Alice) and a resource (Car XYZ). 

At run-time, an application can query the KBAC service for questions like “Can Alice drive Car XYZ?”. This query will trigger policy evaluations that match the request. The request will be translated into a graph query that traverses the relationships between Car XYZ and the identity Alice to determine if this path exists. If a path exists, the response from KBAC service to the application is a “permit”. The application could also ask questions like “Which cars can Alice drive?”. This would lead to a policy response of a list of cars that Alice, according to the graph, can drive. 

At IndyKite, we strongly believe in the Identity Knowledge Graph as a foundation to enable real business value to organizations. It provides a reflection of the “real world” of a business’ operation. The data model can be used for fast-traversing the most complex information structures (product hierarchies, contracts, organizations etc.), that exist within any organization of some size. This fast execution of request-response is crucial for run-time access control. 

The graph model also helps you extend and use that data to solve data-sharing challenges like user-initiated delegations, Power-of-Attorney, or consents, which are areas closely related to authorization and access control.   

In my next blog, I will dive a bit deeper into comparing different authorization models and explain more about how KBAC works.

‍

Learn more

Want to learn more about KBAC? Download the KBAC product sheet or watch a webinar where we discussed KBAC in depth.