In our webinar, Building your Identity Knowledge Base, we described a series of steps you should take when starting an identity knowledge graph project. In this blog, we will go through an example scenario and provide additional details about this lifecycle.
Following the steps in this lifecycle will help you avoid some common pitfalls like trying to “take on the world” when starting an identity knowledge graph project.
Wait, what’s Identity Knowledge? Check out this great blog post where we discuss transforming identity data to identity knowledge.
The Identity Knowledge Graph
As the digital world becomes increasingly complex and identity moves beyond humans and passwords, traditional IAM systems are proving inadequate. An identity knowledge graph, a real-world network of both person and non-person entities—i.e. objects, events, situations, or concepts—and the relationship between them, gives you a lens in which you can view the relationships across your data.
The IndyKite platform empowers organizations to build and leverage Identity Knowledge Graphs in a simple to use platform.
Identity Knowledge Graph Lifecycle
When starting out building an identity knowledge graph there are a few core steps that you’ll want to start with.
These steps are:
- Define the pilot use case
- Define the graph model
- Establish access control
- Deploy, extend, enrich
Let’s unpack each of these steps.
Define the pilot use case
In this scenario we are working with EnergyCo, a fictitious, modern energy company, and they are in the process of building a new electric vehicle charging station network. They want to ensure that their mobile-first, user-experience is world-class.
As part of the IAM team you’ve been tasked with enabling the business by introducing new capabilities, services, and features through the company’s mobile application.
It’s good practice to start small and look for quick wins. Using the data that you already have, within your organization, you know that you can implement the following use cases, in the mobile app:
- Show location of charging stations
- Customers can enroll in Loyalty Program
- Customer can add Vehicles to their loyalty program profile
Now that you have defined the use cases you can then start to create the data model.
Define the graph model
It’s best to start out with a smaller set of data and then build and add more as needed versus trying to boil the ocean right out of the gate. The flexible nature of graph databases allows you to take an iterative approach to the data included. Based on your use cases you should be able to define the entities that you need. For example, our example use cases require us to have Customers, Vehicles, Charging Stations and Loyalty Program(s).
Graphs, by their nature, are used to highlight the relationship between entities. So, then once you have defined the types entities that should be included in your knowledge graph you should then map the relationship by defining the ontology. Don’t worry about being too specific here. Simplicity is your friend that will help you maintain future extensibility.
Again, you want to focus on your use cases and define the relationships that are required to support your use cases without over-engineering the model.
Within IndyKite, your model and ontology are imported into your Customer Space by way of schema files.
A schema file is a JSON formatted text file containing the entities and relationships that you defined in the modeling exercise previously.
In the example below each entity has two properties defined id and label. Id is a randomly generated unique identifier used for reference in relationships and label is a list of one or strings that describe the entity.
The entity section of the file lists the entities (or identities in our case) and includes the properties “id” and “label”. In the relationship section of the file we define the relationship between the entities, identified by their id, and the relationship “type” between the entities. This file will exactly describe the design that you created earlier in the process.
As you can see from the example file above, this file only defines the entities and how they are related. This does not include any of your data or metadata itself.
Establish access control
Once you have the model defined and imported into the IndyKite platform, as a schema, you can then create an Access Policy mapping and import that. Access Policies are a set of rules that define the actions an identity can take on a specific resource. Once enabled, your applications are able to query the IndyKite platform and get policy decisions to determine whether to allow or deny certain actions within your application.
Authorization decisions can be made by querying the authorization service which in turn uses the relationships in the graph to determine whether to respond with an allow or deny decision.
Deploy, extend, enrich
Now that you’ve modeled your graph, imported your schema and your access policies you are ready to deploy. As users continue to use your new services you will be able to find new relationships, uncover new insights and create more value for your user and your business.
Next Steps
Are you ready to start building your Identity Knowledge Graph? Do you want to find out more about IndyKite’s graph-based identity and access management platform? Reach out and let’s talk.
