Skip to main content

Introduction

Welcome to Warrant! 👋

Our docs site should have everything you need to get started. If you have any questions, drop by our Slack Community to chat with the team.

What is Warrant?​

Warrant is an application authorization & access control platform built for developers and product teams. It's designed to abstract away the complexity of implementing and managing authorization & access control so teams can focus on building their core products.

Teams use Warrant to implement application authorization & access control models like role based access control (RBAC), relationship based access control (ReBAC), attribute based access control (ABAC) and other custom access models in their apps. We'll cover these and other common use cases in more detail below.

Key features​

  • A centralized, managed authorization service (inspired by Google Zanzibar) for storing and managing authorization models and their associated access rules (we call these warrants)
  • Built-in primitives for common access models like RBAC, multi-tenancy, pricing tiers, and feature entitlements
  • Check API for easy and fast access checks (i.e. Is user:A an editor of document:X?)
  • Query API for easy and fast querying across access rules (i.e. Which documents can user:A edit?)
  • Central event log of all operations to enable easy audit logs, alerting, and debugging of authorization rules
  • Full-stack infrastructure from back-end SDKs to CLI and UI components/self-service applications to add authorization at any layer
  • Connectors to sync users, tenants, and other data from any source (i.e. IdPs, DBs)

Use Cases​

Proper application authorization & access control are typically mission-critical for all types of purpose-built software in industries and verticals such as finance (fintech), healthcare, data & analytics (including machine learning & AI), operations, and internal apps.

Regardless of the industry or vertical, there are common patterns and use cases we've observed that applications regularly use. Here are a few of those use cases:

Role based access control (RBAC)​

Basic RBAC​

One of the most common forms of access control, role based access control (RBAC) involves 3 main entities: roles, permissions and users/subjects. Permissions define 'behavior' that can be grouped into roles (ex. 'admin', 'owner') and assigned to users/subjects. RBAC is common within B2B software and SaaS applications used by enterprises and is often required to abide by compliance, contractual and regulatory requirements.

Warrant supports RBAC out-of-the-box. Follow this quickstart to implement RBAC within your application.

Multi-tenant RBAC (custom roles & permissions)​

Most applications that implement RBAC usually start with a static set of roles and permissions. This works well for relatively simple applications used by one customer (single-tenant). However, this model often breaks down within multi-tenant applications (apps used by multiple customers). Different customers of a multi-tenant application (ex. multi-tenant SaaS) might require different roles and permissions. This introduces a new dimension (tenant) on top of the existing roles, permissions and users and requires a flexible access model to prevent a concept known as 'role explosion'.

Fine-grained access control (FGAC)​

Fine-grained access control (FGAC) is a more granular form of access control that is becoming more popular in apps today. In comparison to more coarse-grained access control like RBAC which grants access based on 'behaviors', FGAC allows for more granular access control that can be defined at an object or resource-level.

For example, while a RBAC policy might specify that [admins] can [edit] [reports], a fine-grained policy can specify that [user:1] can [edit] [report:xsd34].

Content sharing​

One of the most common use cases for FGAC is to enable access control on user-generated content, similar to Google Docs or Box. With FGAC, you can easily define owners, editors and viewers of your own resources and objects (ex. documents, reports).

'Fine-grained' RBAC​

FGAC can also be used in conjunction with RBAC to enable what we call 'fine-grained RBAC'. This is especially common in SaaS apps and developer tools. For example, let's take a cloud infrastructure multi-tenant SaaS that defines a resource called customer-application. A 'customer-application' can have owners, editors and viewers. Now let's say that the users within this SaaS can have multiple 'roles' within their 'tenant' based on their access level. In order to specify an access rule like all [admins] of [tenant:x] can [edit] [all applications] that belong to [tenant:x], we need 'fine-grained RBAC', or the ability to specify resource-level rules by role.

Organization hierarchies​

Another common use case for FGAC is to model complex organization hierarchies, often those found within most mid-large scale enterprises. For example, let's say that we'd like to specify a rule within an organization which states that all [members] of [team:x] can access [report:y87dXfd]. Furthermore, let's say that membership in team:x is driven by org hierarchy and whether a specific person reports to a given manager.

Using an FGAC system such as Warrant, we can model the exact org hierarchy as well as easily define rules such as all [direct reports] of [manager:y] are [members] of [team:x] and all [members] of [team:x] can access [report:y87dXfd] in order to process queries such as can [user:1] access [report:y87dXfd] in realtime.

Regional access control​

Similar to enterprise org hierarchies, apps with complex regional hierarchies are a good use case for FGAC. For example, let's say we're building a supply-chain or operations-focused SaaS app where data and functionality is separated by region. We may have region:east and region:west to distinguish the two core regions with teams and users defined within each region.

Using an FGAC system such as Warrant, we can accurately model the regions and easily make queries against it at runtime to ensure that the right users have access to the right data and functionality.

Self-service (or delegated) access control​

After introducing RBAC or another access control scheme within a SaaS, one of the most common requests that customers make is the ability to manage roles, permissions and rules themselves. We call this 'self-service access control'. Typically, this ability to manage the access control model is exposed to only a handful of trusted users directly within an admin UI (either built-in or linked from the core app).

Warrant supports self-service out-of-the-box. Follow this quickstart to implement it within your application.

Pricing tiers & features (entitlements)​

Although not directly related to security, a common form of access control often used within SaaS is what we call 'pricing tiers & feature entitlements'. Pricing tiers are groups of features within an app, typically assigned based on the end customer's payment tier. Mature SaaS apps often build out their own management and enforcement layer for pricing tiers, in order to support everything from feature overrides and metering to integrations with payment systems.

With an FGAC system like Warrant, pricing tiers and feature entitlements can be expressed as rules like [company:x] is on [tier:enterprise] and [feature:dashboard] is part of [tier:enterprise] in order to easily support runtime queries like can [user:y] which is a member of [company:x] access [feature:dashboard]?

Getting started​

Not sure where to start? Start with one of these:

  • Overview - Take a deep-dive into the different pieces that make up Warrant and understand the overall system architecture
  • Quickstart - Create an account, get API keys, install SDKs and start making requests
  • Guides - Detailed guides on setting up common authorization use cases with Warrant

Further reading​

  • FAQ - Frequently asked questions
  • API Reference - API resource definitions and examples
  • The Warrant Blog - Articles & product updates from the Warrant team
  • Demo App - Live demo of a sample application using Warrant
  • Security - Warrant's security policies