Happy Friday! It's the final day of Launch Week! In case you missed the previous days, you can catch up here: Day 1, Day 2, Day 3 and Day 4.

Throughout the week, we've talked about various nuts & bolts upgrades to the Warrant platform that bring improved performance, resiliency, and safety to the APIs and core authorization service.

Today, we're excited to introduce Warrant templates, a repository of pre-defined and purpose-built object types schemas designed to get you up and running with Warrant in minutes. Simply pick a template that matches your application use-case and deploy it into your Warrant environment using the CLI. Each template also ships with a test suite with sample tests, making it easy to iterate.

We're launching with 4 brand-new templates today, all of which represent common use-cases we've seen developers build with Warrant. Many of these templates make use of the built-in object types already present within Warrant (e.g. roles, permissions) with added object types for more bespoke scenarios.

Devtool​

First up, is a template to model access control within a developer tool. Modern devtools, although focused primarily on the developer experience of their APIs and tooling, are becoming increasingly collaborative. If you're building a devtool and looking to set up a multi-tenant access model that supports multiple users per tenant, custom teams (also per tenant), as well as custom applications and/or projects, this template will get you up and running in no time.

Document store​

The document store template is perfect for anyone building an application with user-generated content that requires 'Google Docs' like sharing and access control. Using the document and folder object types, you can easily create document hierarchies per user and/or team.

Enterprise access control​

A common use-case we often see is internal IT teams looking to build out an enterprise access control system for their organization. Typically, these systems are required to control employee access to vendor-provided software as well as custom, in-house applications. The enterprise access control template is designed for this use-case and comes with organization, team and employee object types that make it easy to set up organization hierarchies and application or environment-specific access rules.

Infrastructure​

Another common internal access control use-case we've come across is 'infrastructure access', typically required in larger companies with multiple teams that have adopted a microservices (or even just service-oriented) architecture. In such models, developers, teams, and even machines, are granted read or write access to specific services based on organization and team hierarchies. If you're looking to build out such an access model, check out this template here.

What's next​

We believe that these templates represent a handful of the common use-cases and access models that developers are looking to add into their applications. But they're by no means exhaustive. We intend for this templates repository to be a living template store and will continue to update it and add new templates over time. That being said, if you have any ideas for new templates, or would like to contribute your own, join us on Slack and let us know!

With that, we're at the conclusion of our first ever Launch Week! Thanks for following along with us this week and we hope you're excited about all the new updates and features we've shared!

Share to Twitter

Share to Hacker News

Share to LinkedIn

Welcome to Day 4 of Launch Week! In case you're just joining us, check out what we launched on Day 1, Day 2, and Day 3.

Yesterday's post detailed many of the enhancements we've made to Warrant over the past few months to improve overall performance and resiliency in production. Today's post is going to focus exclusively on testing and correctness, which are equally (if not more) important in an authorization service.

Testing your authorization model with assertions​

First up, we're excited to announce that the Warrant CLI now supports test assertions! You can now easily write test cases using the CLI to test your access model:

warrant check user:john member permission:create-reports --assert true

An example test cmd that returns true if user:john has the create-reports permission

The Warrant Dashboard has always had a Check Access page where you can quickly check one-off rules. However, what we learned from customers is that they wanted an easy way to write automated tests for Warrant that could be run as regression test suites (either locally or in CI) prior to making any changes to an access model.

So we decided to augment the existing CLI check command with 'assert' capabilities to provide an easy, platform/framework-agnostic way to write test cases. You can now easily write a shell script that sets up a Warrant test environment, runs test cases, and does a full clean-up, all automatically.

Check out the testing guide for more details.

Managing object types via a GitOps workflow​

The most important part of a Warrant authorization model is the object types schema. If you compare Warrant to a relational database, the object types schema is similar to a relational database's table schema. Both define the primitives that drive the underlying data-model. And just like with relational table schemas, Warrant object types might need to be updated as applications change over time.

In order to facilitate safer updates to object types schemas, we've created a new, built-in GitOps workflow that utilizes the CLI, object types APIs, and environments to enable automated testing & deployment of object types changes.

Check out the full guide to get started and set up your workflow.

That's it for day 4! We hope you're as excited about these testing improvements as we are! Join us back here tomorrow for day 5, and be sure to join us on Slack to talk shop, give us your feedback, or tell us what you'd like to see us work on next!

Share to Twitter

Share to Hacker News

Share to LinkedIn

Happy hump day! Day 3 of launch week is focused entirely on some exciting performance and reliability upgrades for Warrant. In case you missed the previous days, here are the links: Day 1 and Day 2.

From the beginning, we've envisioned Warrant as a globally distributed, highly performant and highly available authorization service that developers can easily plug into their applications without worry. Building such a cloud service is tough. We're thankful to our customers who have entrusted us with powering their authorization and helped us evolve Warrant over the past year+ into a service that now processes millions of API requests per day while maintaining 99.995% availability (or < 30m of downtime per year).

Welcome to day 2 of our first Launch Week! On day 1, we introduced the new and improved v2 Warrant API. In case you missed it, you can catch up on the details here. Now let's get into day 2!

Warrant Query Language (WQL)​

In a recent blog post, Why Google Zanzibar Shines at Building Authorization, we detailed why Google Zanzibar is extremely well-suited to handling application authorization. One of the key reasons we covered is that Zanzibar is a stateful, centralized authorization service. This means the authorization rules for an application (along with any other data necessary to make authorization decisions for the application) are stored centrally in Zanzibar, making it possible to query access rules for a user or resource in real time without the need to consult another data source. This allows developers to not only audit users' access rules but to also query Zanzibar directly from their application to fetch only the resources a user has access to.

Today, we're excited to introduce the Warrant Query Language (WQL), a declarative, SQL-like language for querying Warrant for lists of access controlled data from the context of an application. In particular, WQL is there to help developers answer two types of queries from within their applications:

1. Which objects of type T does user U have access to?
2. Which users have access to object O?

Hey everyone! It's finally time to kick off our first ever Launch Week! Before we get started, for those of you who don't know: At Warrant, we're building authorization and access control infrastructure for developers.

The team has been hard at work over the past few months iterating on our platform in close partnership with our customers. We've improved many areas, from developer experience to performance and reliability, while also adding a slew of new features and can't wait to share more about everything we've built. Now let's get started!

On this inaugural day of Launch Week, we're excited to announce two huge releases:

• v1.0 of Warrant OSS, the open source, self-hostable authorization service powering Warrant
• Our v2 API, with tons of new features and improvements to both performance and developer experience

Let's get into the details!

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.

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.

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.

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 ⭐!

Here's our (short but sweet!) product update for March:

Warrant open source​

It's been 2 weeks since we officially open sourced Warrant. It's been exciting to see the feedback from users. If you haven't checked it out yet, check out the repo here, give us a ⭐ and help us drive the roadmap!