This is the last of a blog series on the topic of authorization models. This final piece will  provide an overview of IndyKite’s Knowledge-Based Access Control (KBAC) which is one of the key services of our Identity Platform. 

The IndyKite Platform offers both wide and deep Identity and Access Management (IAM) capabilities for organizations that want to provide exciting and secure user journeys. These capabilities include user onboarding, authentication, federation, authorization, and secure data sharing. 

‍

Platform Architecture

The IndyKite platform is a cloud-native solution delivered in a Software-as-a-Service (SaaS deployment model. That means that the solution is a centrally deployed service in the cloud which makes it ideal for B2C and B2B scenarios where the use cases, in full or partially, depending on external data to the organization using the platform. 

The IndyKite platform is built on a connected data tech stack with a strong IAM layer on top. At its core is the Identity Knowledge Graph that enables organizations to aggregate data from multiple sources, building an operational data layer that supports complex and sophisticated use cases – going well beyond traditional IAM usage. For example, the platform can be used for personalization, recommendations, delegations, and more, which are key to driving new business value and constructing compelling user journeys. This is a new way of thinking about identity solutions, moving beyond a security focussed, cost prevention strategy, to how identity can achieve greater security while enabling business growth and value creation.

Since the KBAC service uses the Identity Knowledge Graph when making decisions, it is important to understand this graph data model and why IndyKite has built the platform using this model. 

Early on, IndyKite (and our founder, Lasse Andresen) recognized that connected data models are the future of CIAM. In order to be able to embrace the complex and sometimes very “messy” information structures of large organizations we needed to be able to model those structures in a phased approach. This is a main driver for using graph databases. To allow an organization to think big about their business models, but to be able to start small, scaling up as you mature and grow. 

The graph model allows you to be flexible in your data structure and to be able to change while running. This means that you can use the model of ‘Nodes’, ‘Relationships’, ‘Properties’, and ‘Metadata’ to describe and store a highly contextual representation of an organization’s “real world”. The flexible and intuitive graph model helps to balance the complexity as the scope grows. 

Organizations can populate the Identity Knowledge Graph with its specific business domain data, like store locations, households or groups, loyalty membership, smart devices, products, and payment services, etc.

The platform offers simple and flexible means for an organization to onboard data into the Identity Knowledge Graph and to keep the data in sync when data is added, modified, and deleted during its day-to-day business operations. 

However, it is essential to understand that an organization should only populate the graph with data that is needed to solve the targeted use case. It's not intended to use the Identity Knowledge Graph as a general data lake. For example, large sets of transactional data should not go into the graph database. If transactional data needs to be represented, you have the possibility to ‘reference’ that data in the graph model without needing to pull in the complete data set. An example of when data does (!) require to be represented in the Identity Knowledge Graph is when making access decisions. To successfully use KBAC, then the data needs to be represented in the graph. 

‍

‍

KBAC Model

The KBAC model enables contextual and real-time decisions from the same data that closely follows how you have modeled your business domain. 

In the “PEP-PDP-PIP-PAP” authorization model (described in part 2 of this blog series) the IndyKite platform plays the parts of the PDP, PIP, and the PAP. The PEP is the client application that queries the PDP for authorization decisions. 

The platform exposes the ‘authorization service’ (PDP) as a set of gRPC-based API endpoints.  Client applications and services (PEP) can be integrated using the platform’s APIs or the IndyKite SDKs (available for Node, Python, and Go). The SDKs package the required APIs into a single bundle that makes the integration effort a smooth and easy process for the developer.

The Identity Knowledge Graph is used as the PIP and the IndyKite administrative console acts as the PAP.  

‍

Policy Model and Management

The KBAC policy structure follows a “Subject - Resource - Action - Condition” model where the elements can be described as:

• The ‘subject’ represents the entity, which normally is a user but can be anything. 
• The ‘resource’ represents a business object, which is normally some kind of asset such as a passport, a car, a payment method, etc. 
• The ‘action’ represents what operation is performed on the ‘resource’, such as ‘create’, ‘delete’, ‘use’, or ‘drive’, etc.  
• The ‘condition’ represents the context for allowing access which means the criteria for when access should be granted such as if a delegation exists or if the user is an assigned driver of a car.

Using this model, we can easily map out the logic of the WHO-WHAT-WHEN-WHERE-WHICH-HOW-WHY of authorization using a policy. 

IndyKite uses a low/no-code approach to policy authoring (PAP). Authorization policies can be crafted and managed by using the platform’s visual policy editor (drag and drop tool) or by writing policy-as-code in a JSON document. 

‍

Policy Evaluation

Let’s look at an example from the retail industry, where the business data includes information about stores, households, loyalty programs, campaigns, products, payment services, and receipts, which are interconnected with the identity data of customers and family members.

An example policy could delegate a controlled payment process between a parent and a child within a loyalty program. 

In such a case, the Identity Knowledge Graph (PIP) needs to include a defined schema to support this delegation as well as data that represents the nodes and relationships to support the use case. 

For example,  the parent can create a “delegation relationship” between themselves and their child and set a transaction value limit of say $30. This will allow the child to action their delegated authorization for transactions up to that amount via the loyalty app, without the parent present.  

Note: The IndyKite Platform supports the user to create that relationship and store it in the graph. That is one more example of why we have chosen to design the system with an operational data store based on a graph database. This topic was also discussed at the end of part 2 of this blog series.

So, the natural language policy looks like this: 

“A child of a loyalty member can use a delegated payment method up to a set limit.”

The policy defines:

• Subject: ‘Child’
• Resource: ‘Loyalty Credit Card’ (payment method)
• Action: ‘Pay-by-Delegation”
• Condition: ‘Transaction limit value’

Policy evaluation is triggered by matching the authorization PEP request's ‘resource’ (Loyalty Credit Card) element plus the ‘action’ (Pay-by-Delegation) element. 

If the graph query finds a path through the nodes and edges (PIP data) between the ‘resource’ and the ‘subject’ the user should be granted access i.e. the policy effect is  ‘permit’. If no path is found the policy effect is  ‘deny’. Both the policy request and policy decisions are logged in the platform’s audit service. 

By using graph data to derive authorization we gain several benefits. The data model supports the fast computation of the semantic details of the graph objects i.e. nodes, edges, properties, and metadata as these are persistently stored in the database.  

Another benefit is that if the underlying data structure changes (and it will as you derive more and more requirements) the policy does not need to change (providing the Subject, Action, Resource remains l the same). This means you can scale and adjust as you go, without having to rewrite your policies.  

‍

Open Policy Agent Integration

Open Policy Agent(OPA)is an open-source-based rule engine that can be used for authorization and is popular in the market. OPA makes use of policies written in REGO language and which has been a successful combination to attract developers. 

At IndyKite, we see OPA as a  partner (rather than competitor) to expand the use and reach of externalized dynamic authorization to scale in an organization. 

IndyKite offers an OPA Plug-in that allows a developer to use a local OPA instance. Additionally,  the execution of REGO policies enables OPA to call out to IndyKite for authorization based on the graph data.   

‍

The Road Ahead

The IndyKite platform is evolving at a rapid pace and we look forward to keeping you informed as we move along our journey.

The authorization areas we will focus on are related to policy life-cycle management and usability, DevOps integrations, auditing/analytics, and Machine Learning for authorization. 

In summary:

KBAC is a dynamic authorization service that is part of a low/no-code SaaS-based IAM platform that builds on connected data technology and can be used by organizations to integrate their digital applications and services to secure access to critical data in rich and exciting user journeys.

If you’d like to learn more about how Knowledge-Based Access Control can provide value for your business, please get in touch. 

If you want to learn more about how to build your knowledge base and establish your authorization policies, check out a recent webinar where we walked through the process. 

‍

‍