Case study: Mapping and building a unified identity graph across a portfolio of acquisitions

Managing user identities and authorizations across a portfolio of acquisitions and their applications was an identity and access management (IdAM) nightmare for this human capital management provider. Using gdotv, the team built an identity graph in Amazon Neptune to model and coordinate authorizations across both new and existing applications with confidence.

The Company

The company provides human capital management (HCM) software and services to small, mid-sized and enterprise companies, helping them stay compliant and allocate their time, money and teams toward growth. Its HCM solutions – branded and white-labeled alike – let teams tackle payroll, human resources, taxes, timekeeping, attendance, compliance and more.

The Challenge

Following a major strategic pivot, the company acquired a number of different businesses and solutions across its industry: HR companies, payroll software, tax businesses and many others.

Bringing together a diverse portfolio of companies, cultures and applications presented plenty of its own challenges, but one complication quietly lurked beneath the surface: all of these disparate teams and solutions came with their own unique identity stores. On top of that, some software applications were sold and managed directly while others were white-labeled for resellers, complicating how the team could manage authorizations. It was a tangled, multi-layered nightmare for achieving any form of unified identity and access management (IdAM).

As part of the company’s ongoing modernization and consolidation of its growing platform, the Principal Architect is helping lead the effort of unifying identity and access management.

“The linchpin is to have an identity system that is common and unique across all of our various application services,” said the Principal Architect. “Looking at how granular and peculiar some of these legacy applications have their authorizations built out, it made sense to build our own identity graph.”

The identity graph model includes vertices such as tenants, organizations, users, rules, roles, loose roles, resources, definitions and more – each connected by a web of edges and recursive relationships. The resulting authorization tree is complex, to say the least.

The team considered a number of different solutions, but settled on building an abstraction over Amazon Cognito and then deriving all authorizations from the new identity graph to be stored in an Amazon Neptune graph database.

“We could have modeled all of these identities using a relational database, but it was much easier to do in a graph and then extend that model as we discovered new requirements,” they said. “That’s how we ended up choosing a graph database for this project.”

But up to that point the team had only used NoSQL or relational databases, so a graph database presented a sharp learning curve.

“Designing a graph database was one thing, but trying to actually build it out was a different challenge,” said the Principal Architect.

The team had a conceptual graph model in mind, but they needed a tool that helped them visualize and track that data model on a daily basis. At first, they used a Jupyter Notebook for graph visualization. However, graph queries had to be completed in Visual Studio Code, and switching back and forth between the Jupyter Notebook for visualization and VS Code for querying began to slow down the team’s productivity.

“We were already trying to learn something new,” they said. “Graph databases and Gremlin queries were both new to the team, and then we had to learn how to really make use of Jupyter notebooks at the same time. We just wanted an IDE that gave us a seamless, direct experience.”

Fortunately, they didn’t have to search for long.

The Solution

In January 2024, the Principal Architect was looking through the AWS Neptune documentation and found gdotv as one of the listed graph database client tools.

“The minute I saw gdotv, I was like, ‘Okay, we’re buying this,’” said the Principal Architect. “It was exactly what we needed.”

Once the team had tested out gdotv with their Neptune database, the Principal Architect immediately purchased licenses for the team.

“After that, everything we did with the graph database – whether it was debugging or profiling queries – it just went much smoother with gdotv,” they said.

The Results

With gdotv in hand, the team could start building and improving their enterprise-wide identity graph with new confidence.

The most immediate result of using gdotv was a boost in developer experience. With gdotv, developers can connect to different environments and easily test new queries against the data. In addition, the team can save Gremlin queries for repeated use – whether for rapid debugging or just quick insights into the graph – without having to rewrite the query each time.

“You can’t fully quantify DevEx,” said the Principal Architect. “But I can honestly say that using gdotv has made a real difference on the team, and we love it.”

One of the biggest boosts in developer productivity has been gdotv’s help in troubleshooting and debugging the identity graph.

“One time, we were trying to understand why a particular user authorization lacked the proper permissions,” they said. “We were stumped because other users in the same group were working perfectly. But we knew what shape the graph data should be, so we opened gdotv, pulled up the user’s node and expanded the graph around that user. Immediately, we saw that an edge was missing due to a subtle bug in our code, which is why the user lacked the requisite permission. Just being able to visually explore our data and find the issue rather than having to dig through lines of code – that was incredible.”

Another way that gdotv has helped the team is through data model tracking. The gdotv schema viewer helps developers track the state of the graph without having to memorize the data model.

“Using the schema viewer helps since you don’t have to keep the data model in your head just to write good queries,” said the Principal Architect.

Likewise, tracking the existing data model has helped the team diagnose issues and plan the future of the identity graph model going forward.

“One of the first things we did with gdotv in production was look at relationship counts in our current model,” they said. “Those counts helped us quickly identify supernodes that were causing performance issues and fix them accordingly. In the long term, we want to refactor our graph database in such a way that the model can be migrated steadily to a new state, and tracking on minor alterations like these is how we’ll get there.”

Furthermore, gdotv has helped the team not only be more efficient with their day-to-day graph database operations but also be more effective when it comes to graph thinking.

“In a graph model, you’re starting at one point and exploding out from there,” said the Principal Architect. “You’re more spatially oriented and thinking visually. gdotv makes it easier to navigate that graph learning curve.”

For example, there’s one contractor on the team who had never worked with a graph database before. Today, the Principal Architect says the contractor is writing Gremlin queries with ease because they can explore the graph intuitively.

In the future, the Principal Architect hopes the identity graph can also become an internal resource for non-technical stakeholders, with the ability to showcase and explore identity and access management through graph visualization.

While the identity graph is currently the company’s only graph use case, the Principal Architect is open to future possibilities with graph technology.

“If we have any use case that needs a graph database in the future, we will definitely use it,” they said. “And obviously that means using gdotv too.”

Anonymized at the customer’s request.