Skip to main content
Version: 2.0.0

How does Permit.io work?

One of the main challenges of implementing authorization properly is making sure it can evolve along with your application. As our app’s requirements evolve (From a simple Admin - Non-Admin logic into roles, attributes, relationships, and more), it becomes very difficult to maintain a consistent authorization layer without cumbersome spaghetti code.

Here's how Permit can help -

Decoupling policy and code​

A best practice utilized to separate our app’s authorization code from the actual application code. Open-source Policy Engines such as Open Policy Agent (OPA) and AWS’ Cedar provide an excellent baseline for creating such a microservice. Still, this authorization microservice requires a lot of maintenance work, especially around connecting the microservice to the application, its policy sources, the data it needs, and the access-control interfaces we need to build on top.

That’s where Permit comes in - utilizing these existing open source solutions, Permit provides you with a microservice for authorization based on your Policy Engine of choice, an administration layer, OPAL, which keeps the policy engine up to date with the latest policy and data updates, a set of SDKs per your language of choice, and a cloud service to manage it all.

Permit’s Hybrid Architecture​

The Permit architecture consists of two main parts, a Control Plane and a Data Plane:

  • The Data Plane stores all the actual data required to make authorization decisions. This includes authorization policies, names, emails, etc.

  • The Control Plane includes the relationships between various entities required to make authorization decisions (User IDs, Roles, Attributes, etc.).

Basically, the Control plane, through which you make changes and updates to your authorization layer, is managed via Permit’s Cloud Service, while the Data Plane can be fully kept and managed within your own VPC / Network.

This means you can manage your authorization layer with Permit without the need to expose any of your data to the cloud. Some of the benefits of this architecture are:

  • No sensitive data leaves your network/cloud, ensuring your app’s security and compliance.

  • Authorization decisions are made on your side with zero latency.

  • You are not dependent on Permit’s availability to make authorization decisions.

Two main components enable this hybrid architecture - OPAL, and the Permit PDP:

Connectivity Map Diagram

OPAL​

Open Policy Administration Layer (OPAL) is an open-source project developed and maintained by the Permit.io team. It serves as an administration layer for Policy Engines detecting changes to both policy and policy data in real-time and pushing live updates to your agents.

OPAL consists of two elements - The OPAL Server and the OPAL Client

The OPAL Server is hosted as part of Permit’s Could Service. It Creates a Pub/Sub channel for OPAL clients to subscribe to, tracks a Git repository (via webhook/polling) for policy updates, and pushes those updates to clients (as diffs - only updating changes, not the entire thing).

The OPAL Client is deployed as part of the PDP -

The Policy Decision Point (PDP)​

A PDP is a network node responsible for answering authorization queries using policies and contextual data. The PDP provided to you by Permit acts as your microservice for authorization and is deployed as a sidecar to your own services.

Permit’s PDP consists of a Policy Engine and the OPAL Client:

  • The Policy Engine is in charge of evaluating authorization queries, using the policy rules as a source of truth. Authorization policies are written in Policy Languages (such as Rego or Cedar), which the policy engine interprets, providing a decision to any authorization query it is presented with.

    Permit is policy engine agnostic, currently supporting Open Policy Agent and AWS’ Cedar, (With support for more policy engines coming soon), allowing you to choose the one most suitable for your needs.

  • The OPAL Client is deployed alongside the policy agent and keeps it up to date with the latest policy and data. It does so by subscribing to topic-based Pub/Sub updates for both data and policy. Policy and data are fetched from the OPAL Server (Hosted in Permit’s Clout Service) and any other relevant sources (e.g., DBs, APIs, 3rd party services).

The combination of Permit’s Cloud Service, OPAL, and the PDP allows you to manage changes to your authorization layer via Permit (using the UI/API), and have these changes propagated instantly into your application - all without your data ever having to leave your network/cloud.

Contents