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"
        }
      ]
    }
  }
}

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

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.

2022 is quickly coming to a close! This is our penultimate product update of the year and it's a big one:

Introducing Dynamic Environments​

By default, all Warrant accounts have shipped with 2 environments: test and prod. These environments are completely isolated and designed to make testing and deploying changes to your access models safe and easy.

One piece of feedback we've continuously received from teams is the desire for custom environments. For example, some developers want their own individual development environment for local testing that's separate from the shared test environment. Others want the ability to define their own test environments like qa or staging. Some even want separate environments for each of the different applications in their stack/product suite.

To solve all of these different use-cases, we're excited to officially introduce dynamic environments! Now, you can create your own environments directly from the Warrant dashboard. Similar to the existing test and prod environments, dynamic environments are isolated from each other and accessible via their own separate API keys. You can create environments to match your different apps, test environments, and/or development teams. Visit your account page to create your first custom environment.

Dashboard Updates​

Lots of usability enhancements within the dashboard this month including:

• Search for users by userId or name on the Users page
• View all of a user's assigned tenants on the Users page
• A new UI to manage teammates on the Account page

Lots of exciting updates to share for September! 🍂

Pricing Tiers & Feature Flags​

Earlier this month, we shipped native support for feature flags & pricing tiers in Warrant. You can now create and manage features and pricing tiers (ex. free, pro, enterprise) for your app directly in the Warrant admin dashboard or via API. Once configured, access to these features and tiers is enforced at runtime in your app using the existing front-end and server-side Warrant SDKs.

Features and tiers are completely dynamic and can easily be changed and overridden as needed. Check out more info in our launch post and if you'd like to get started with Pricing Tiers & Feature Flags, just sign-in to your Warrant account and follow the onboarding guide.

Angular SDK​

We're excited to launch our official Angular SDK! Similar to our Vue and React SDKs, the Angular SDK ships with components and other primitives to help you implement authz checks in Angular web apps.

Firebase Cloud Functions​

We've built Warrant to be easy to integrate with any 3rd party authn provider or home-grown authn solution. One of the more popular authn providers we've seen companies using is Firebase. To make it even easier for Firebase users to start using Warrant, we've created a repo of common cloud/serverless functions that you can deploy to Firebase to get your users hooked up to Warrant in < 10 minutes. The repo has functions to create and delete users and sessions (triggered on Firebase auth events). Check it out here.

Today, we're excited to launch support for Pricing Tiers and Feature Flags!

While our core platform has always supported the ability to implement custom pricing tiers and feature flags, it required a lot of upfront work for teams to implement. We strongly believe these are common problems encountered at every software company so we built native support for pricing tiers and feature flags into Warrant.

What is it?​

Pricing Tiers​

Figuring out how to price your SaaS product is a complex enough problem by itself, often requiring several iterations of experimentation to determine. Tiered pricing (or pricing tiers) is a common pattern for SaaS startups to charge customers for their product today. In this approach, a company grants customers access to premium and enterprise level features only if the customer is subscribed to a paid or enterprise plan. This strategy comes with its own set of challenges: What should I include in my free tier? How much should I charge for a pro/premium tier? What features should be considered enterprise features? With Warrant's built-in support for pricing tiers, you can easily limit access to premium features in your product based on each customer's subscription, giving you the flexibility to control which features are available in a pricing tier and match changing customer personas. You also have the ability to grant/revoke access to individual features per user or customer for one-off scenarios.

Feature Flags​

Software teams looking to iterate quickly and frequently release functionality with reduced risk typically make abundant use of feature flags. Warrant now has built-in support for feature flags, so teams can incrementally release features individually to customers. Common uses for feature flags might be enabling a beta feature for certain users or rolling out a feature only to specific customer segments. When bugs arise, feature flags can be useful for quickly disabling a faulty feature, allowing teams to avoid performing a complete deployment rollback or scrambling to release a fix.

It's hot outside but the team is staying cool and shipping. Here's what we've been up to in the past month:

Hacker News Launch​

We launched on Hacker News earlier this month, check out the discussion here.

New Demo App​

We've created a new demo app to showcase Warrant running within a live web application - managing roles, permissions and access checks. The demo app lets you preview a sample e-commerce store as different users (with different permissions) and see a live access log of all permissions checks as they happen in the app.

Building and maintaining a role-based access control (RBAC) model at a growing company can be a challenge as your application evolves with continually changing product requirements. As requirements and features are updated, your access model needs to keep up. Today, we're excited to introduce a new concept and features to help you manage your RBAC model with less complexity: implied roles and permissions.

What is it?​

Many RBAC models involve some sort of inheritance, where an admin role may have all the permissions of a lesser role plus more admin-specific permissions. This can involve duplication of permission assignments across roles and quickly turn your roles and permissions into a complex mess that's difficult to manage.

We've eliminated the need for this duplication and made it simpler to manage complex RBAC models via API or Dashboard with the concept of implied roles and permissions. With implied roles and permissions, you can define a role or permission that will automatically be implied when a user is assigned a particular role or permission. For example, a manager and basic role can be implied by the admin role so any user with the admin role will automatically be granted the capabilities of both the manager and basic roles.

The two primary ways to view, manage and enforce an access model in Warrant include APIs and the admin UI. Today we're introducing a third way, geared towards power users, especially those that ❤️ automation: a native command-line interface (CLI).