Model Attribute-Based Access Control (ABAC)

Attribute-based access control (ABAC) encompasses any scenario in which you use the characteristics of a resource, a user, or the environment to determine access. This category is so broad that it can often feel paralyzing (“Anything can be expressed as an attribute!”)

In practice, there are a handful of common patterns in B2B apps. For each of these, we provide a guide that includes a description of the pattern, example code, and example tests:

• Public/Private Resources (opens in a new tab) - In collaborative applications, it’s common to let users share resources. One way to share a resource is to mark it as "public" (e.g., a public repo). Public repos are visible to anyone, but an owner can also set a repo to private. The same is true for documents in Google Docs or Dropbox.
• Conditional Roles (opens in a new tab) - Conditional roles allow you to modify the behavior of an RBAC model based on attribute values. For example, you could introduce a protected attribute to your resources. If a resource is protected, members of an organization can’t read it, even if their role would otherwise allow them to.
• Time-Based Checks (opens in a new tab) - You can use this pattern to enable use cases like expiring access, which is useful for both users (e.g., give a user edit access to a repository for just 24 hours) and resources (e.g., make the link public for 7 days).
• Entitlements (opens in a new tab) - Entitlements describe the features and tiers your customers have paid for (e.g., only users that have paid for the Enterprise Tier get access to the auditing feature of your product).