Authorization systems are a critical component of modern applications, yet traditional approaches like role-based access control (RBAC) and attribute-based access control (ABAC) struggle to meet the complex access control requirements of today’s enterprises. In this post, we introduce a relationship-based access control (ReBAC) as an alternative for enterprise scale authorization. We explore how the proposed ReBAC architecture uses Amazon Neptune to create a knowledge graph which becomes a highly scalable staging layer and serves as a system of records for the authorization systems. This architecture is capable of processing millions of requests per second while managing billions of relationships. Amazon Neptune, a managed graph database service, is an excellent option for implementing ReBAC because of its ability to efficiently model, store, and query complex relationships between entities.
In this post we dive into aspects of designing a ReBAC-based authorization system and demonstrate how ReBAC effectively addresses common challenges such as role explosion and token bloat. This post provides architects and developers with actionable insights for implementing ReBAC-based authorization systems that can scale across enterprise applications and microservices architectures. You will learn how to modernize your authorization infrastructure with a solution that delivers both fine-grained access control and exceptional performance.
Requirements for authorization at scale
Let’s review the key requirements for implementing authorization at scale.
- Access review: Know who has access to what at all times; maintain clear visibility of permissions across your system.
- Change management: Control who can modify permissions and through what process; establish clear ownership.
- Auditable: Track permission changes with who, what, and when; maintain complete historical records.
- Reliable: Make consistent authorization decisions that don’t fail; the system needs to set the correct authorization for each request.
- Fast: Make sure that permission checks don’t slow down your application; performance matters at scale.
Modern enterprises require sophisticated access management strategies to protect their digital assets while providing operational efficiency. Here’s a quick look at various access control approaches:
Role-based access control
RBAC assigns permissions to roles rather than directly to users, where each role represents a set of actions a user can perform in a system. Users are then assigned to one or more roles, simplifying the management of access rights by grouping common permissions together rather than managing them individually for each user.
Modern applications, especially in microservices architectures, face a critical challenge when using RBAC. As applications grow, teams typically create specific roles for each business function or microservice. Imagine how many distinct roles you’d need just for a social media application’s photo viewing feature alone. This leads to role explosion, where the number of roles grows and becomes unmanageable. The problem compounds when these roles are embedded in authentication mechanisms such as JSON Web Tokens (JWTs). Storing numerous roles in tokens leads to token bloat, resulting in payloads that can reach megabytes in size. Such large tokens cause network performance issues and often fail to pass through the API gateway layer or proxies effectively. This traditional approach to authorization doesn’t scale with modern application needs.
Attribute-based access control
ABAC makes access decisions based on a combination of attributes about the user (such as department, location, and clearance level), the resource (such as sensitivity, type, and owner), and the environment (such as time, location, and device). Unlike RBAC’s rigid role assignments, ABAC provides more flexible and contextual access control by evaluating these attributes against defined policies. The following diagram illustrates the ABAC flow using different policy enforcement components.
The policy-based access control framework consists of four key components working together. The policy enforcement point (PEP) acts as the gatekeeper, intercepting and controlling user access requests. When a request is received, it consults the policy decision point (PDP), which evaluates access policies and makes authorization decisions. These policies are managed and stored in the policy administration point (PAP), where administrators define and maintain access rules. To make informed decisions, the policy information point (PIP) gathers relevant attributes from various sources. In a typical flow, when a user requests access, the PEP initiates the process, the PDP evaluates applicable policies while gathering necessary information from the PIP and finally returns an allow or deny decision, which the PEP enforces.
Enterprise authorization systems face significant challenges when dealing with multiple PIPs spread across microservices, legacy systems, and various data sources. If a single PIP experiences downtime or performance issues, it impacts the entire authorization process. To address this, organizations need to implement a tiered approach for designing a reliable and performant authorization system. Critical authorization components require a minimal recovery time objective (RTO) and recovery point objective (RPO), while less essential components can operate with less strict requirements to optimize costs. This balanced approach helps ensure that critical services maintain high performance while managing infrastructure costs effectively across the authorization system.
Relationship-based access control
ReBAC offers a fundamentally different approach to authorization compared to traditional RBAC or ABAC models. Instead of relying on roles or attributes, ReBAC determines access based on the relationships between subjects (users) and objects (resources). These relationships can be modeled as a graph with nodes and edges, where access decisions follow relationship paths. For example, your ability to view a file in an object store might depend on your relationship to the folder that contains it. For example, if you’re a viewer of a folder, you can access files within it. This relationship-based approach naturally handles hierarchical structures and complex permission scenarios. The model excels at expressing intuitive access patterns that mirror real-world relationships, making it particularly effective for modern applications with complex permission requirements. The following diagram shows the relationship between user, folder, and files.
A typical ReBAC engine can be designed and built to provide scalable and dynamic authorization by modeling relationships between users, resources, and permissions. This engine can use a tuple-based data model to represent relationships, such as user A has access to document B with permission C. The system would perform real-time authorization checks by traversing these relationships, providing fine-grained access control suitable for diverse use cases. The ReBAC engine can support hierarchical permissions, enabling policies to propagate across resource structures, such as folder and subfolder access. Optimized for low-latency and high-throughput queries, ReBAC engine integrated with Amazon Neptune as the backend store can handle billions of relationships efficiently, making it viable for large-scale applications. Consistency can be achieved through techniques such as low-latency replication across Availability Zones and secondary AWS Regions, helping to ensure reliable and predictable access decisions. By abstracting the complexity of access control, this custom-built engine would allow developers to implement secure, flexible, and scalable authorization tailored to organizational needs.
ReBAC helps you to address the limitations of RBAC and ABAC by providing millisecond latency to help ensure scalability and reliability. A ReBAC system can be built using one of the following approaches
- Create a custom ReBAC solution tailored to your needs
- Use popular open-source implementations such as SpiceDB, OpenFGA, or Ory/Keto
- Opt for managed services such as OktaFGA or AuthZed
Reference architecture for building an enterprise-grade ReBAC solution
Amazon Neptune and ReBAC systems serve distinct but complementary roles. Neptune is a general-purpose graph database designed for storing and analyzing complex relationships, such as organizational hierarchies, user interactions, and data lineage. In contrast, ReBAC systems are optimized for real-time access control, efficiently evaluating permissions based on defined relationships. Neptune enables deep relationship queries and analytics such as identifying reporting structures or data dependencies, while a ReBAC system focuses on fast, dynamic authorization checks such as determining whether a user can access a resource. By using Neptune as a source of truth for relationship data and syncing only access-relevant relationships to a ReBAC system, you can minimize duplication while maximizing performance. This hybrid approach allows Neptune to handle large-scale relationship modeling, while the ReBAC system ensures efficient, fine-grained access control in real time. If access control is the sole requirement, a standalone ReBAC system may suffice, but for broader relationship management and analytics, Neptune adds significant value.
Let’s assume we have an employee access control system where the following entities are represented in Neptune:
- Users (employees)
- Documents (resources)
- Roles (manager, editor, viewer)
Nodes and their properties in Amazon Neptune
| Entity Type | ID | Attributes |
| User | alice | {name: “Alice”} |
| User | bob | {name: “Bob”} |
| Document | doc1 | {title: “Report”} |
| Role | editor | {level: “edit”} |
Relationships in Amazon Neptune:
| From (Entity A) | Relation | To (Entity B) |
| alice | has_role | editor |
| editor | can_edit | doc1 |
| alice | reports_to | bob |
The graph data replicated from Amazon Neptune to the ReBAC system (for example, SpiceDB) includes users, roles, documents, and their relationships. In Neptune, entities like alice (User), bob (User), editor (Role), and doc1 (Document) are nodes, while edges represent relationships such as “Alice has the editor role” (alice → has_role → editor) and “Editor role can edit Document 1” (editor → can_edit → doc1). These relationships are converted into tuples: user:alice#member@role:editor (Alice is a member of the editor role) and role:editor#assign@document:doc1 (Editors can edit Document 1). This transformation allows the ReBAC system to enforce access control dynamically, so when checking user:alice edit document:doc1, the system infers that Alice has editing permissions through role inheritance. The migration verifies that Neptune’s entity-relationship graph is now leveraged for fine-grained relationship-based access control in a ReBAC system.
ReBAC implementers provide APIs to define, update, audit and retrieve relationships between users, resources, and permissions. They allow real-time authorization checks to verify if a user or application has specific access to a resource and support exploring and visualizing access hierarchies to understand permission structures and debug issues.
In enterprise environments, data lakes store information from various systems of record. To build a ReBAC system, you need to extract relationships from specific system data stored in these data lakes. The reference architecture shown in the following figure employs one or a combination of micro-batch solutions such as AWS Glue and Amazon Elastic Container Service (Amazon ECS). Additionally, Amazon Bedrock’s large language models (LLMs) can help build graphs by extracting entities and relationships from unstructured data, such as text documents or web content. These models transform raw text into structured data in the form of subject-predicate-object triples, which form the foundation of a graph. They can also disambiguate entities, create unique identifiers, and infer new relationships to enrich the graph. Additionally, LLMs continuously update the graph with real-time data, making sure that it stays current and accurate. This workflow can be triggered using Amazon EventBridge based on data changes within the data lake and orchestrated using AWS Step Functions for execution. The workflow would create or update relationships in Neptune. The relationships are subsequently replicated to ReBAC implementation systems using Neptune Streams.
Managing entitlements using relationships
Let’s explore how ReBAC transforms access management across industries.
Financial services
Consider an industry research firm offering tiered subscription levels such as Platinum, Gold, and Silver. Instead of rigid access rules, ReBAC dynamically controls data access based on subscription entitlements. A Platinum subscriber can access 100% of research data, while Silver members view only 30%.
A typical data flow for the solution is illustrated below:
- Fetch entitlement attributes from the authorization response based on the subscription levels.
- Create queries dynamically for your records system (in this example Amazon OpenSearch Service) using Amazon Bedrock hosted foundation models (FMs) or large language models (LLMs).
- Retrieve data from OpenSearch based on these queries.
- Summarize the content using Amazon Bedrock hosted FMs or LLMs and present it to the user.
Healthcare
As another example, consider a healthcare organization with 10,000 customer service agents. Among them are 2,000 agents managing only outpatient operations. With traditional RBAC, administrators must manually assign roles to each agent. ReBAC simplifies this work. By using relationships and entitlement mapping, ReBAC automatically grants the correct access levels based on agent profiles and tags. This automation, which can follow the guidance in the previous example, reduces manual effort, helps prevent access errors, and scales as the organization grows.
Conclusion
In this post we showed you how ReBAC can help you address the limitations of RBAC and ABAC by offering more flexible and efficient access control compared to traditional methods. This will reduce administrative overhead while maintaining security especially when integrated with Amazon Neptune as source of truth for relationship data to optimize performance and minimize duplication.
For more information, see:
Get started on your ReBAC implementation journey with the concepts and approaches outlined in this post. Try it out and let us know your thoughts in the comments section, and feel free to reach out to us with questions.
About the authors
Sriharsha Subramanya Begolli works as a Senior Solutions Architect with AWS, based in Bengaluru, India. His primary focus is assisting large enterprise customers in modernising their applications and developing cloud-based systems to meet their business objectives. His expertise lies in the domains of data, analytics and generative AI.
Yogish Kutkunje Pai is a Senior Solutions Architect at AWS. In his current role, Yogish helps large global enterprises build solutions on AWS. With expertise in application development, graph databases, and generative AI applications, Yogish brings a wealth of technical knowledge to every customer engagement. Outside of work, Yogish enjoys experimenting with new technologies and cycling.
Source: Read More
