Skip to main content

· 3 min read
Aditya Kajla

Hey Everyone! It's been a while since our last product update. The team has been hard at work this summer with some major improvements to Warrant. We decided to take a quick break to tell you about some of the things we've been working on!

New CLI commands

The Warrant CLI is now the quickest way to get started with Warrant. We've added new commands for listing object types, making assertions on check requests (for testing), and managing objects (create, get, update, delete). The CLI now also supports multiple environments via the env command.

Check out these instructions to install and get started with the CLI.

Update CLI

· 3 min read
Aditya Kajla

Here's what's new with Warrant this month:

Support for ABAC policies (including time-based warrants)

We're excited to announce that the Warrant authorization engine now supports expression and evaluation of ABAC policies in addition to its native ReBAC capabilities. Although most application authorization scenarios can be modeled via ReBAC (e.g. RBAC, fine-grained access control), there are certain scenarios where access depends on an object or environment's attributes.

For example, we might want to express a rule that states that [user:1] is a [member] of [role:admin] but only if that user's requests are originating from [ip-address:192.192.0.1]. Although Warrant's existing ReBAC engine allows us to represent the member relation between user:1 and role:admin, we must also check for the user's IP context at runtime for the full check to pass.

To enable such scenarios, Warrant now supports definition of policies directly within warrants and evaluation of those policies at runtime using 'contextual data' provided by the client. For the example above, we can define a warrant with an IP equality check as follows:

{
"objectType": "role",
"objectId": "admin",
"relation": "member",
"subject": {
"objectType": "user",
"objectId": "1"
}
"policy": "user.client_ip == \"192.168.1.1\""
}

This warrant states that [user:1] is a [member] of [role:admin] if [user.client_ip == 192.168.1.1]. At check time, a request with the following context would result in an access allowed response:

{
"objectType": "role",
"objectId": "admin",
"relation": "member",
"subject": {
"objectType": "user",
"objectId": "1"
}
"context": {
"user": {
"client_ip": "192.168.1.1"
}
}
}

In addition to strict equality (==), Warrant policies also support a variety of operands including comparators, regex and time (expiration) expressions. For more details, check out the docs.

Dashboard updates

We've also made a few significant improvements to the Warrant admin dashboard this month to make finding, viewing and editing your access control data much easier. More specifically:

Dynamic table views & sorting

All table views (e.g. tenants, users, roles, permissions etc.) now support sorting by column (e.g. by 'created_at' date) and dynamic, in-place data fetching via a 'load more' button to make it even easier for users to traverse and search through their data.

Table sort

· 9 min read
Karan Kajla

Over the last couple years, authorization (AKA “authz”) has become a hot topic of debate. Proponents of various authz frameworks, libraries, and philosophies have voiced their opinions on how it should be implemented, jockeying for position to become the de facto way to implement authz. Among the contestants in this debate, Google’s Zanzibar has recently emerged as a popular way of not only modeling and enforcing authorization for modern, fine grained use cases, but also of scaling to meet the requirements of today’s large-scale, cloud-native applications.

· 2 min read
Aditya Kajla

We missed sending out a product update for April but we're back for an even bigger May update! Lots to share including a new milestone for the Warrant open source service as well as some exciting updates to Warrant Cloud!

Warrant open source crosses 350 ⭐s

The Warrant open source service has hit a milestone of 350+ stars! The latest version (0.17.0) ships with MySQL, PostgreSQL and SQLite support along with enhanced debugging for access checks and a revamped events architecture. Check us out and give the repo a ⭐!

· 3 min read
Karan Kajla
Aditya Kajla

Today, we're excited to announce that Warrant is officially open source! Check out the repo here.

A quick recap

We started Warrant in June 2021 with the goal of bringing enterprise-grade access control to all applications. Warrant began as a simple API which developers could integrate into their apps in order to implement and manage role based access control (RBAC). Over time, with feedback from customers, we've iterated considerably on the core platform, evolving it into a complete access control system that supports everything from RBAC to more modern access control paradigms like fine grained access control (FGAC), attribute based access control (ABAC) and relationship based access control (ReBAC).

Our cloud-first and API-first approach has enabled us to build a system that is highly-scalable and performant, to the tune of millions of customer API calls per month. As we look ahead, we want to establish a better community and better practices around application access control, and believe that making Warrant open source is the best path forward.

· 2 min read
Aditya Kajla

Here's our product update for February:

Login with Google & GitHub

By popular demand, Warrant now supports login with Google & GitHub! New users can simply click on the 'Continue with Google' or 'Continue with GitHub' buttons to create their Warrant accounts.

Existing users can also login with Google & GitHub provided that the email address associated with Google and GitHub is the same as the one they used to register with Warrant.

Login with Google and GitHub

· 3 min read
Aditya Kajla

It's a new year and we have lots of updates to share:

Revamped object types, now with type restrictions

We've revamped object types, making them more succinct and easier to work with. Additionally, object types now support type restrictions. For example, teams could previously specify in an object type that a user is an owner of report:A if that user is a member of another object that is an owner of report:A. However, it wasn't possible to specify that the user must be a member of a particular type of object (i.e. a tenant) in order to this inheritance to occur. This is now possible via the revamped object type schema. Check out an example below or read more in our docs.

{
"type": "report",
"relations": {
"owner": {
"inheritIf": "member",
"ofType": "tenant",
"withRelation": "owner"
},
"editor": {
"inheritIf": "anyOf",
"rules": [
{
"inheritIf": "owner"
},
{
"inheritIf": "member",
"ofType": "tenant",
"withRelation": "editor"
}
]
},
"viewer": {
"inheritIf": "anyOf",
"rules": [
{
"inheritIf": "editor"
},
{
"inheritIf": "member",
"ofType": "tenant",
"withRelation": "viewer"
}
]
}
}
}

· 2 min read
Aditya Kajla

Happy holidays! This is our last product update of 2022 and we're excited to share more about what we've been up to leading into 2023:

Major updates to Java & Ruby SDKs

We've made some major updates to our Java and Ruby SDKs, bringing them up to par with all functionality supported by the Warrant APIs. This includes:

  • All RBAC operations including role, permission, user assignment, removal and authz checks
  • Pricing tiers (CRUD operations and authz checks)
  • Features (CRUD operations and authz checks)
  • New Java and Ruby types for Warrant objects and subjects to make creating, deleting and checking warrants easier and safer

Java and Ruby

· 3 min read
Stanley Phu

Maintaining separate environments for development/testing and production is a common practice on most engineering teams as a way to improve team productivity, prevent bugs, and speed up release cycles by giving the team more confidence in the changes being made before they're released to customers. For many teams, this often goes beyond the basic production and test environments that Warrant currently supports, including individual developer environments that allow each developer to work independently with their own, separate set of data. Today, we're excited to introduce custom environments and access control across all environments!

What is it?

Custom Environments

Teams can now create their own custom environments in addition to the pre-existing production and test environments. While production and test work for some teams, others need more environments like staging or QA. Some organizations also want to distinguish between development and test environments if they run automated tests. Other customers have even mentioned wanting to keep their data models separate for different internal applications. With custom environments, you can set up your Warrant environments to mirror your development workflow and your applications & their different environments.

Environment Permissions

Teams can now also limit who has access to each environment. For example, organizations may only want to give a subset of team members access to the production environment, or developers with their own environment might want to limit who has access to it so that their data isn't modified by anyone else. With environment permissions, you can now control who can and can't access your environments in Warrant.