Skip to main content
Version: 2.0.0

Learn the basics of Permit & Authorization

A quick reference for all the Permit and otherwise permission, authorization, IAM buzzwords, and authorization concepts.

Authorization (AuthZ) vs Authentication (AuthN)​

While closely related, authorization and authentication are different. To simplify with a metaphor - imagine a person is about to enter your home:

Authentication is about identifying who is at the door and deciding whether they may enter or not.

The Authorization comes in as soon as the person is in your house, and handles their permissions inside the house - can they open the fridge? Sleep in your bed? Read your diary?

To conclude:

  • Authentication (AuthN) - Who is the user
  • Authorization (AuthZ) - What is the user allowed to do

Dive deeper with this video

Decoupling your policy from code​

One of the key challenges of implementing authorization correctly is to support its ever-changing needs and growing complexity as the project requirements evolve. This complexity can be broken into two main parts - architectural complexity, and feature or model complexity.

Architectural complexity​

Naturally, your code evolves as you are adding additional microservices and logic. As a result, additional authorization logic is added ad-hoc to solve specific cases, which eventually leads to inconsistencies in authorizations throughout the system.

Feature and model complexity​

Authorization requirements starts with - "We only need an 'Admin' and a 'Not Admin' roles", just to quickly discover that additional roles, models, and rules are required as requirements arrive from customers, colleagues, security, compliance, and partners. Soon RBAC (role based access control) is replaced by ABAC (attribute based access control), GBAC (graph based access control), and/or hybrid models; and more and more access-control features are built on top.

Decoupling Policy and Code in general​

To avoid being encumbered by said complexity, we can use the best practice of decoupling policy from code. Ideally, we use a separate microservice to provide authorization to the rest of the system. Open-source solutions like OPA (Open Policy Agent) and its policy language Rego are an excellent baseline for creating such a microservice. Still, it requires 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.

Decoupling Policy and Code with Permit.io​

With Permit.io, you get the best in class authorization solution ready-made:

  • A microservice that is based on OPA and OPAL.
  • A set of SDKs per your language of choice to work with.
  • A cloud service to manage it all.

Decoupling Authorization data from application data​

While the information for running a product overlaps with the data used to authorize it's access, the two are different. First, the authorization doesn't require all the data used by the application. Second, the data relevant for authorization often extends to additional data sources that are not the application's core, i.e., billing, CRM, identity providers.

With Permit.io, you get a handful 3rd party data integrations from various sources and a pipeline based on OPAL.

Terminology / Glossary

MAU​

Tenant​

  • Tenant a silo of resources and users; which in policy terms means only users within a tenant can act on the resources within the tenant
  • Often a tenant would represent an end-customer of yours, but sometimes you'd want multiple tenants to represent a single logical customer tenant (for example if you have multiple departments within each logical tenant).
  • Read more about tenants here

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 - but usually you'd only need one.
  • Billing is done based on MAU and tenants per Workspace.

Project​

  • a collection of environments. Contained within a workspace.
  • Usually corresponds to an end application or services

Environment​

  • A silo of policy and data.
  • Usually represents a specific deployment (E.g. dev, prod, staging) of a project.
  • Environment can be cloned (Selectively) via the API
  • Each PDPs is synced to a specific environment via the secret environment API key

Permit Element​

  • An embedable UI component presenting a permissions flow to end-users
  • e.g. user-management, audit-logs

General Terms

Models​

RBAC​

  • Role Based Access Control - A permissions model in which all permissions for an identity are derived from a role (e.g. Admin, Viewer) that is assigned to it

ABAC​

  • Attribute Based Access Control - A permissions model in which permissions are deduced from conditions on a sets of attributes. ABAC is the most comprehensive model - most other model can be described as subsets of ABAC.

ReBAC​

  • Relationship Based Access Control - A Permissions model in which permissions are deduced from the relationships between identities and various nested groups and resources (e.g. ). ReBAC is most common for nested hierarchies (e.g. org charts, file directories)

Architecture​

Multi-tenancy​

  • A system design aspect which allows every part of a service (i.e., every microservice) to cater to multiple customers without deploying separate instances for each. Read more in our blog.

AuthZ for AuthZ​

  • Authorization for Authorization; the ability to assign permissions and access control on the access control system itself. A recursive yet critical part of a secure access control system (often neglected). Includes features like meta roles, meta audit logs, api logs and more.

Topology​

PDP​

  • Policy Decision Point - a network node in responsible for answering authorization queries (using a policy and contextual data)
  • In Permit.io a PDP is provided as a container - meant to act as your microservice for authorization - often deployed as a sidecar to your own services.
  • AKA : Authorizer, Permitter, Microservice for authorization, sidecar
  • Full article

PEP​

  • Policy Enforcement Point - a point which enforces access to resources, usually queries a PDP for the decisions to enforce.
  • In Permit.io - PEPs can be created across the stack in code vai the SDK( single line, function, route, middleware), or outside your code via plugins (Reverse Proxy, API Gateway)

Contents