Concepts / Glossary
A quick reference for all authorization, permission, and Permit related terms and concepts.
General Authorization Terms
Authorization
Firstly, it’s important to distinguish between Authorization and Authentication.
Authentication handles who can log in to your application, by verifying their identity and checking they are who they claim to be, while Authorization handles what they can do once they are inside.
Policy
An authorization policy is a set of rules that determines access to a resource within your application. It consists of a combination of who (Their Identity) can do what (Their role and, respectively, the actions they are allowed to perform) with a resource (On which aspects of the software). Policies can include additional criteria such as Roles, Attributes, and Relationships.
In simple English, an authorization policy (In this case, Role-Based) would look something 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 and structured way of defining rules, conditions, and logic for specifying policies. It provides a standardized syntax and semantics for expressing authorization rules and access control requirements, making it easier to manage and enforce security policies. There are many different policy languages, such as 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 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.
PDP
A Policy Decision Point (PDP) is a network node responsible for answering authorization queries using policies and contextual data.
In Permit, the PDP is provided as a docker container meant to act as your microservice for authorization - often deployed as a sidecar to your own services in your own architecture.
PEP
A Policy Enforcement Point (PEP) enforces access to resources, usually by querying a PDP for the decisions to enforce.
In Permit, PEPs can be created across the stack in code via the SDK (single line, function, API route, middleware), or outside your code via plugins (Reverse Proxy, API Gateway).
Multi-Tenancy
A system design aspect that allows every part of a service (i.e., every microservice) to cater to multiple customers without deploying separate instances for each.
AuthZ for AuthZ (aka - Meta Authorization)
Authorization for Authorization; the ability to assign permissions and access control on the access control system itself. A recursive yet critical part of creating a secure access control system. Includes features like meta roles, meta audit logs, API logs, and more.
Authorization Models
Authorization models determine the level of access or permissions granted to users based on factors such as user roles, attributes, contextual information, or a combination of these factors. There are several models in which these policies can be structured:
RBAC
Role-based access control (RBAC), is an authorization model used to determine access control based on predefined roles. Permissions are assigned to roles (Like “Admin or “User”), and roles are assigned to users by the administrator.
ABAC
Attribute Based Access Control (ABAC) is an authorization model that determines access based on conditions applied to attributes (or characteristics), rather than roles, allowing the definition of fine-grained complex access-control rules.
ReBAC
Relationship-Based Access Control (ReBAC) - is a permissions model in which permissions are deduced from the relationships between identities and various nested groups and resources. ReBAC is most common for nested hierarchies (e.g., org charts, file directories).
Permit.io-Related Terms
MAU
Monthly Active Users (MAU) - the identities (end-users) you check permissions for on a monthly basis.
A single user identity can perform 1000s of permission checks in one month - this will still count as 1 monthly active user.
MAUs are calculated by the count of unique user keys for which permissions are verified within a given month across your workspace (organization). This implies that verifying permissions for the same user (identified by its key) multiple times across different environments within the same month counts as only one MAU.
Read more about user management
Tenant
Tenants represent a single instance of the application's environment, often used in multi-tenant architectures. Each tenant is a separate, isolated unit with its own set of users, data, configurations, and permissions.
In multi-tenant systems, different organizations or groups use the same application but operate within their own isolated environment. Permissions and policies can be defined at the tenant level, ensuring separation and privacy between different tenants.
Often, each tenant will represent one of the end-customer companies in your product (i.e., a company you provide services to).
Workspace
Your Permit organizational account, under which all of your configurations, projects, and environments reside. Workspaces are completely siloed from one another.
You can have multiple workspaces and switch between them - although usually, you'd only need one. Billing is calculated based on MAU and Tenants per Workspace.
Projects
A collection of environments contained within a workspace. Projects usually correlate to a specific application/service your organization provides.
Environment
A silo of policy and data, usually representing a specific deployment of a project (e.g., dev, prod, staging). Environments can be cloned (selectively) via the API.
Each PDP is synced to a specific environment via the secret environment API key
Permit Element
An embeddable UI component presenting an access control flow to end-users (e.g., user management, audit logs).