Policy Editor
Writing and maintaining good authorization policies is hard. The Policy Editor plays a centric part into what we offer at Permit. It was designed to take away the hassle of dealing with complex code, and offer a UI solution that allows both novice and experienced users to create and edit authorization policies with ease - with code or low-code interfaces.
We combine the power of a powerful authorization engine with the ease of use of a simple web interface, making us a very desired product withing many companies.
You can manage policies from the Policy Editor page.
What is a Policy?
A policy is a way of defining rules of how permissions are granted. Within each policy, we focus on a hierarchy view of how permissions are applied.
A policy consists of user roles, actions, and resources.
A policy resides in an environment.
There are two types of policies that we currently support. RBAC (Role-based Access Control) and ABAC (Attribute-based Access Control).
What makes up an RBAC Policy?
Roles
Roles exist on an organization level - whether you change project, tenant, or environment, the same roles exist for you. Roles are assigned to users in the User Management page.
Resources
Resources are tied to the selected environment. A resource is the target object we want to authorize access too.
Actions
Actions are contained within each resource. They are what a person with a specific role can and cannot do. They can be custom and accomodate only to one specific resource.
Resources and Actions are at the core of the Policy Editor and are defined in the editor within the application's configuration or via the API. Once defined, resources and actions become the layout for permissions.
A role that is assigned (checkbox marked) to a resource and action allows users with that role to perform the action on a resource.
Above is a Policy Editor example with two roles (Admin, Viewer) and three resources (task, boards, counts) The Admin can do everything except delete tasks.
What makes up an ABAC Policy?
User Sets
User Sets are groups of users that adhere to pre-defined attribute-based conditions. These are conditions based on individual user characteristics.
Resource Sets
Resource Sets are groups of resources that adhere to pre-defined attribute-based conditions. These are conditions based on an environment a resource exists in (e.g. time and location).
Authorization Models
Permit.io supports multiple authorization models - including RBAC (Role Based Access Control) and ABAC (Attribute Based Access Control). By default the UI is set to work with RBAC & ABAC. Authorization models can always be extended with additional code.
OPA Policies
By default, Permit.io uses the OpenPolicyAgent (OPA) and its code based policy language - which is Rego - to create and maintain authorization policies. Rego code can be created by using the low-code Policy Editor UI, or by directly writing code. Code created through the editor is merged into a Git repository (as part of the Permit.io cloud or one of your choice). The stored policies are then deployed on the fly via OPAL to the multiple PDP microservices that you deploy.
GitOps
We support Rego editing via the GitOps Feature, in which the policy editor commits the Rego code you generate into a git repository of your choice.
The GitOps feature allows you to manage all your policies within Git by subscribing to a Git repository, which will all be tracked and deployed from there by OPAL. Git provides all the versioning.
As mentioned above - Policies created with the Policy Editor are merged into a Git repository, this allows us to create a controlled process for creating and maintaining policies. Code-reviews, tests and approval flows combine easily with GitOps and the Permit.io authorization development life cycle.
The feature is not open to everyone is self-service, however, email us or send us a message on Slack, and we will enable it for you.