Many of today’s identity and access management systems rely on directory information services, to store identity data.  At the foundation of most directory services is the Lightweight Directory Access Protocol (LDAP).  LDAP organizes data in directory information trees (DIT), a hierarchical structure (like a corporate org chart).

‍

‍

Directory Services were foundational to the building of internet applications that are wide-spread today. Directory Services support Role-based access control (RBAC) and Attribute-based access control (ABAC) authorization models and you would typically assign a role by adding a user’s identity as a member of a group (which represents a role). Each object in the directory information tree has a set of properties that are defined by a set of schemas.

‍

‍

Unfortunately these models don’t necessarily reflect the structure of the real world, or even most data models or business models of many organizations. This is why knowledge graphs are critical for the next generation of internet / web services.

Read more about building value with knowledge graphs in our post Delivering knowledge to solve customers challenges.

‍

‍

Knowledge Graphs in practice

‍

In knowledge graphs, the identity objects are stored as a nodes on the graph.  The identity subject’s attributes (or properties) can be defined as labels associated with the node or as separate nodes themselves.  In our example we’ll create them as nodes.  The edge between the identity node and property nodes could be labeled with “HAS” (or other values describing the relationship).  In addition to connecting the identity nodes to property nodes, the nodes and edges can be enriched with metadata that provides more context.  In the example below we can see that some of Barbara’s properties were verified when she was onboarded, using trusted verification, with her passport.

‍

‍

As more data is added to the graph (e.g. additional identities, services, other organizations) we can define relationships between these nodes.  In the example we see that we’ve added additional identities and created other relationships such as Mother_of, Owns, Controls, Member_of.

‍

‍

This knowledge graph is now being enriched with contextual data that allows an organization (maybe a bank, a school, a retail organization) to traverse the relationships and have a much more granular understanding of how the identity data is related.  Both structured and unstructured data can be referenced in the knowledge graph.  We can now begin to infer certain things from the graph as well, such as, if Barbara is married to David and the mother of Nick then David and Nick are probably related.

This synthesis of data through enrichment, data analysis and machine learning opens the door for organizations to provide much more personalized services and opportunities for their customers and users.

‍

‍

Knowledge-based access control

‍

We’ve recently introduced Knowledge-Based Access Control (KBAC) as an evolutionary step forward, which leverages the utility of knowledge graphs to determine permissions by examining how nodes are related in the graph.

Looking back at our knowledge-graph, we can now use the enriched data to implement access policies that examine the relationship between Barbara, and other nodes, and then grant or deny access based on the relationship or relationship metadata.  For example, if you are family with Barbara then you can have access to the shared shopping list, loyalty program, streaming service, etc.

If we wanted to write a policy that allows family members to participate in a loyalty program we could construct a policy in the knowledge graph like the following diagram.

‍

‍

The knowledge graph is traversed, looking for relationships between the nodes that are referenced in the graph.  In this example, Nick Jensen is able to participate in the ACME1 loyalty program because the policy states that anyone that is a MEMBER_OF the Family is eligible.

‍

‍

Now, simply by changing the relationship between the nodes we can modify whether or not an identity should have access.  We are also able to add additional family members to the loyalty program just by adding them as members of the family.  This is a very simple example but hopefully one that demonstrates the capabilities and benefits of using a knowledge graph for access control.

Have questions? Check out our Webinar on Building the Knowledge Graph.

‍