🚀 July 30th Live Webinar: How to Progressively Enforce & Evolve Schema with Zero Downtime
Register here
Fauna logo
Log InContact usStart for free
Fauna logo
Log InContact usStart for free
© 0 Fauna, Inc. All Rights Reserved.

Related posts

Guide to Database Security Strategies, Policies, and PosturesAnnouncing Fauna Schema: Build, Iterate, and Evolve Schema with Zero Downtime Flexibility Meets Structure: Evolving Document Database Schemas with Fauna

Start for free

Sign up and claim your forever-free Fauna account
Sign up and get started

Table of Contents

abac blog header 3

Decoding Fauna: ABAC vs. RBAC Explained

Kirk Kirkconnell |Jun 26th, 2024|


ABAC (Attribute-Based Access Control) is not so much an extension of RBAC (Role-Based Access Control), but rather a superset regarding flexibility and granularity. They both answer the question, “Does this incoming operation have access to do XYZ,” but each uses different mechanisms to determine the answer.
Authorization Resources

Getting Started with Fauna Authorization

Explore these resources to get started building with Fauna's ABAC and RBAC.

Explore the docs →

Watch the 'Redefining the Principle of Least Privilege' Webinar Recording →

Fauna ABAC tutorial →

Schedule a demo →

In addition to RBAC's roles, ABAC takes this to the next level and enables the real-time evaluation of dynamic information, such as data values in documents, time, and environmental factors like IP addresses, among other things, without requiring extensive coding in applications or middleware.
Here’s how they compare and relate:

Role-Based Access Control (RBAC)

  • Role-centric: Access decisions are primarily based on the static roles assigned to users. Each role has predefined permissions that determine what the bearer of that role can access.
  • Simplicity and manageability: RBAC is generally simple to implement and manage because it categorizes permissions by broad roles, which can be easily assigned to users.
  • Static: The rules are static and don't typically consider the context of a request or the attributes of the resources being accessed.

Attribute-Based Access Control (ABAC) in Fauna

  • Attribute-centric: ABAC uses a variety of attributes (user attributes, resource attributes, action attributes, and contextual attributes) to make access decisions. These attributes can encompass various data points pertinent to enforcing access control policies. This includes personal user information such as age and location, organizational roles assigned to the user, and broader system-level conditions like the time of day or the device used for access. Each attribute can be dynamically assessed to make real-time decisions about the user’s permissions within the system.
  • Dynamic and granular: Policies in ABAC can be very granular and context-sensitive, allowing for more precise control over who can access what, when, and under what conditions.
  • Flexibility: ABAC can accommodate more complex scenarios than RBAC due to its reliance on multiple attributes for making decisions. It can adapt to changing conditions, which would be more difficult or cumbersome to manage in a purely role-based model. Fauna Query Language (FQL) is used to query data to inform decisions. If you can query data using FQL, you can incorporate that query into security decisions.

Relationship between RBAC and ABAC

  • While RBAC is focused on user roles, ABAC uses roles as just one of the many attributes it uses for access control. This means ABAC can implement all the policies that RBAC can, plus additional policies that are too specific or dynamic for RBAC to handle effectively.
  • Thus, ABAC can be seen as a superset of RBAC regarding capability. It offers everything RBAC does, with additional flexibility to incorporate a broader range of criteria into access decisions.

An example of ABAC in action in Fauna

Below is an example of using some simple ABAC permissions in Fauna. This code creates a role named authUser. It limits who gets this role dynamically based on the schedule in their Fauna "identity document," and then if/when they are eligible, they have the ability to create, read, delete, and write on documents in the "workspaces" collection. Via FQL, it queries for the identity of the calling token, known as the "identity document." It then looks for the projectContributor attribute in that document to see if the array in that attribute matches the attribute in the document you are trying to access. Essentially, if you're on the project, you can interact with the documents related to this project.
role authUser
  membership {
    predicate (self => {
      Time.now().hour >= self?.schedule[0] &&
      Time.now().hour < self?.schedule[1]
  privileges workspaces {
    create {
      predicate(data => {
    read {
      predicate(data => {
    write {
      predicate((a, b) => {
        Query.identity()!.projectContributor.includes(a.project) &&
    delete {
      predicate(data => {
The cool thing is that if someone is added to or removed from a project or it is outside of their work hours (the membership predicate), their permissions shift immediately and without manual intervention! The data is secure at the source...the database.
In summary, ABAC in Fauna offers a more flexible and comprehensive approach to access control compared to RBAC, capable of handling complex, dynamic environments by leveraging a wide range of attributes, whereas RBAC offers a rudimentary approach that might be sufficient for environments with fixed access control requirements based on well-defined roles. Implementing ABAC or RBAC for the appropriate use case ultimately makes your overall database security posture more refined and fit-for-purpose.

If you enjoyed our blog, and want to work on systems and challenges related to globally distributed systems, and serverless databases, Fauna is hiring!

Share this post

‹︁ PreviousNext ›︁

Subscribe to Fauna's newsletter

Get latest blog posts, development tips & tricks, and latest learning material delivered right to your inbox.