Permit.io Launch Week - Day 3: Fine-Grained Modeling

Welcome to day three of Permit.io’s Launch Week! Today, we discuss modeling—specifically, how developers can model their permissions as code. While our UI makes it easy to model role-based access control (RBAC), relationship-based access control (ReBAC), or attribute-based access control (ABAC), we know many developers prefer working directly in code.

That’s why today’s releases are designed to help you model your policies as part of your development workflow.

You can watch the full live stream of these features here:

Let’s dive into the features we’re launching today.

Terraform Provider: Model Policies as Code

We are excited to announce the release of the Permit Terraform Provider, a powerful tool that allows you to manage your policy schemas as code. You’re likely already familiar with Terraform, a popular tool used to manage infrastructure in a declarative way. Now, you can use the same methodology to manage your authorization policies.

The Terraform Provider enables developers to configure and version policy schemas with Terraform scripts, integrating policy management directly into their software development lifecycle (SDLC).

When modeling policies using traditional policy languages like Rego or Cedar, developers face two main challenges: learning a new language and managing the tight coupling between policy and data. This can lead to complex updates and synchronization issues, especially when data changes across versions.

The Permit Terraform Provider decouples policy configuration from data, allowing you to define roles, permissions, and resources using Terraform’s declarative syntax. This means you can model RBAC by defining roles like “admin,” “editor,” and “viewer” and assign different permissions for these roles on resources like documents. Once configured, you simply run "Terraform apply," and your policies are deployed in Permit.

Since policies are now part of your infrastructure as code, you can version them, manage branches, and integrate them seamlessly with your CI/CD pipeline. Whether you’re using RBAC, ReBAC, or ABAC, the Terraform Provider supports all of Permit’s capabilities.

Here’s a step-by-step guide to get started with the Terraform Provider.

Groups API: Simplifying Relationship-Based Access Control

One of the most challenging aspects of ReBAC systems is managing relationships between users and large sets of resources, particularly when dealing with groups. Usually, each relationship requires creating individual tuples between the user and each resource within a group. This can become cumbersome as the number of users and resources grows.

The Groups API adds a layer of abstraction to simplify ReBAC by allowing users to inherit roles across all instances within a group. It allows assigning roles at the group level, automatically applying those roles to all instances within that group.

This means that if a user has a role within a project group, they inherit that role across all documents, tasks, or resources tied to the project. This abstraction dramatically reduces the complexity of managing large-scale ReBAC models.

Whether you’re building a project management tool or any multi-tenant system, the Groups API simplifies access control across related resources, allowing for easier modeling of complex relationships.

Check out our documentation for using the Groups API.

Foreign Key Conditions: Streamlining One-to-One Relationships with ABAC

For developers working with simpler schemas, full ReBAC might be overkill. Sometimes, you only need to handle a single level of relationship—like a foreign key constraint in a database—without the complexity of modeling every relationship explicitly.

The Foreign Key Condition feature allows you to define simple, one-to-one relationships using ABAC without deploying a full ReBAC system.

For example, you might want to grant access to medical visit data based on a foreign key link between a visit and its associated diagnosis. Modeling this with ReBAC introduces more complexity than needed.

Foreign Key Conditions allow you to handle these one-to-one relationships using ABAC. You can model conditions based on related fields (like ensuring that only non-concealed diagnoses are accessible), all while maintaining the simplicity and performance of ABAC. This feature lets you check permissions without explicitly modeling the relationships, streamlining authorization for simpler use cases.

conditions = jsonencode({
    "allOf" : [
      { "resource.concealed" : { "equals" : false } },
      { "resource.practitioner_id" : {
        "object_match" : {
          "match" : {
            "is_advertised" : { "equals" : true }
          },
          "fk_resource_type" : permitio_resource.practitioner.key,
        }
      } },
      {
        "resource.diagnosis" : {
          "all_match" : {
            "match" : {
              "concealment" : { "equals" : false }
            },
            "fk_resource_type" : permitio_resource.diagnosis.key,
          }
        }
      },
    ],

By using foreign key conditions, you keep your policies clean and efficient while integrating basic relationships into your access control models.

Simplified Modeling with Permit.io

We understand that policies are a crucial part of your application infrastructure. By allowing you to manage these policies as code through the Terraform Provider, abstract complex relationships with the Groups API, and streamline simple conditions with Foreign Key Conditions, we hope to make it easier for you to model secure and scalable permission systems.

Stay tuned for tomorrow’s updates as we continue Permit.io’s Launch Week with a focus on integrations!