Businesses have complex organizations and a wealth of information assets to protect and share in order to conduct operations in an agile, performant and secure manner.
Authorization to access and operate on the information assets is currently managed by a tangled nest of isolated systems and individual applications which inhibit an enterprise’s ability to perform simple operations that span the business in an effective manner. It also presents challenges to the business’s ability to comprehend how and when the information assets are shared and accessed by users or systems required to execute effective security, regulatory compliance and risk management audits.
An idealized conceptual model of the Enterprise Authorization domain may be represented like this:
The Party, Identity, Application and Resource entities (along with the multiple intersections between them) must be modeled and managed carefully in order to effectively enforce a business’s authorization policies.
The desired state is for Authorization Data to be managed in a cohesive way across the Organization as Enterprise Master Data. This will provide both the enterprise and users a consistent and uniform data set that can be harvested, cleansed, and back-propagated to source applications to enforce authorization. This process is known as Master Data Management or MDM.
Master Data Management is typically approached as a relational problem resulting in managed data tables with cleansed properties, managed primary keys and possibly foreign key references to other data tables. Master Data governance is performed by a data management team responsible for the curation of the data sets managed. In many cases, a data manager will be responsible for curation of a single data set or unrelated datasets. This approach is appropriate for lists of Customers, Products, Part Lists, Applications, Identities, Roles and Assets. Explicit relationships between data entities can be managed and enforced using foreign key relationships. Recursive and many-many relationships can be easily defined and queried in a relational MDM system. However, the SQL queries required are complex, error prone and generally not performant, often resulting in use of data denormalization views and materialized snapshots to deliver manageable interfaces and meet performance requirements.
Managing master data in a relational manner has been a critical enabler for companies to maintain consistent representations of master data across the applications used by the business to conduct operations. The relational solution isn’t ideal because it introduces unnecessary complexities into the master data model for managing complex relationships that can be represented succinctly using a graph model.
A graph model implemented using a graph database is ideally suited for managing, enforcing and navigating the rich semantic relationships required for Authorization Master Data in a concise way that is familiar to business stakeholders and is difficult to accomplish with relational model mapping. A graph model also supports managing semantic relationship changes in real time cadence to business needs not possible with a relational model.
A simplistic graph model for the Authorization domain
There are several graph databases on the market to consider:
This approach has many benefits:
In a recent engagement we had the opportunity to implement a property graph database solution for authorization for an enterprise desiring to accomplish these goals. The system supports authorization to access and manage owned assets by the customer or on behalf of the customer where assets may be owned by more than one customer.
The property graph database selected for this engagement was one of those listed earlier. Containerized microservices were designed and built using the Command Query Response Segregation pattern as Java Spring Boot applications.
One of the challenges that we had was meeting or beating a performance requirement currently being achieved querying a write-once in memory cache used for authorization. The performance requirement was that 95% of the authorization requests had to complete in 50 milliseconds or less.
We used Gatling to simulate observed load characteristics and access patterns derived from log data metrics produced and gathered from the current production system. The Gatling tests were executed against the REST authorization APIs.
The performance testing and logging exposed issues with our test data, graph traversals, serialization and other code hot spots that could be tuned. The tuned system exceeded our expectations. We were able to meet the performance requirement at 10x the operational load specified.
The resultant solution has significantly better availability characteristics to the prior memory cached relational solution it is replacing and it can successfully deliver the business requirements outlined above for Authorization management.
The new graph based Authorization system is scheduled to be integrated with all customer facing applications of the business which will allow the final decommissioning of several legacy systems that were expensive to license, difficult to extend and support.
The fully integrated graph will serve as an analytical platform to the business used to enable Customer 360° insights, audit and fraud detection not possible in the legacy system.