Concepts / Glossary
A quick reference for the authorization terms and Permit concepts used across these docs.
General Authorization Terms
Authorization
Authorization is different from authentication.
Authentication decides who can sign in to your application, by verifying that users are who they claim to be. Authorization decides what they can do once they are signed in.
Policy
An authorization policy is a set of rules that determines access to resources in your application. It combines who (the identity) can do what (the actions their role allows) on which resource (the part of your software being accessed). Policies can add criteria such as roles, attributes, and relationships.
In plain English, a role-based authorization policy looks like this:
A User can perform Action on Resource.
Or,
John who is an Administrator can read a document.
Policy Language
A policy language is a formal way to define the rules, conditions, and logic of a policy. Its standard syntax and semantics let you express authorization rules as code that a policy engine evaluates. Examples include OPA's Rego, AWS' Cedar, OSO's Polar, and more.
OPAL
Open Policy Administration Layer (OPAL) is an open-source project developed and maintained by the Permit.io team. It is an administration layer for policy engines: it detects changes to policy and policy data in real time and pushes live updates to your policy agents.
PDP
A Policy Decision Point (PDP) is a network node that answers authorization queries using policies and contextual data.
In Permit, the PDP is a Docker container that acts as your authorization microservice, often deployed as a sidecar next to your own services.
PEP
A Policy Enforcement Point (PEP) enforces access to resources, usually by asking a PDP for a decision and acting on it.
In Permit, you create PEPs in your code with an SDK (a single line, a function, an API route, or middleware), or outside your code with plugins (reverse proxy, API gateway).
Multi-Tenancy
A system design that lets every part of a service (every microservice) serve multiple customers without deploying a separate instance for each.
AuthZ for AuthZ (aka - Meta Authorization)
Authorization for authorization: permissions and access control applied to the access control system itself. It is recursive, and a critical part of a secure access control system. It includes features such as meta roles, meta audit logs, and API logs.
Authorization Models
An authorization model determines the access a user gets, based on roles, attributes, context, or a combination of them. Policies are commonly structured in these models:
RBAC
Role-based access control (RBAC) is an authorization model that grants access through predefined roles. Permissions are assigned to roles (like "Admin" or "User"), and an administrator assigns roles to users.
ABAC
Attribute-based access control (ABAC) is an authorization model that grants access based on conditions on attributes (characteristics of users, resources, or the environment) rather than roles. It lets you define fine-grained access rules.
ReBAC
Relationship-based access control (ReBAC) is an authorization model that derives permissions from the relationships between identities, groups, and resources. It is most common for nested hierarchies such as org charts and file directories.
Permit.io-Related Terms
MAU
Monthly Active Users (MAU): the identities (end users) you check permissions for in a given month.
A single user can go through thousands of permission checks in a month and still counts as one monthly active user.
MAU is the count of unique user keys you check permissions for in a month, across your workspace (organization). Checking permissions for the same user key in several environments in the same month counts as one MAU.
Read more about user management
Tenant
A tenant is an isolated unit within an environment, used in multi-tenant architectures. Each tenant has its own users, resource instances, and role assignments.
In a multi-tenant system, different organizations use the same application, each isolated in its own tenant. Role assignments are scoped to a tenant, which keeps tenants separate from each other.
Usually each tenant represents one of your customers (a company you provide services to).
Workspace
Your Permit organization account, which holds all of your configuration, projects, and environments. Workspaces are fully isolated from each other.
You can have several workspaces and switch between them, though most teams need only one. Billing is calculated per workspace, based on MAU. See the pricing page for details.
Projects
A collection of environments within a workspace. A project usually maps to one application or service your organization provides.
Environment
A silo of policy and data, usually representing one deployment of a project (for example dev, staging, or prod). You can clone environments, selectively, through the API.
Each PDP syncs with one environment, identified by that environment's secret API key.
Permit Element
A Permit Elements component: an embeddable UI component that gives your end users an access control flow (for example user management or audit logs).
EAP
Early Access Program. Features marked EAP are released, but their APIs may change.