Product showcase: Permit.io – Application-level permissions with a no-code UI
Managing user access in applications has always been a headache for any developer. Implementing policies and enforcing them can prove to be quite complex, and very time-consuming. Even if a homebrew authorization solution has been developed for an application, sooner or later, problems will arise with scaling the permission system. More roles will need to be created, and further resources and actions will need to be applied – and thus, more developer time will be needed for completing the “Jira tickets”.
One dashboard, many features
Permit.io is a Full Stack Application-level Authorization solution. Rather than building this complex system on your own, Permit provides you with a plug-and-play, out-of-the-box solution for all your authorization needs. Our no-code dashboard allows you to manage your users and their roles, build policies, and check audit logs. It also allows delegating secure access to your end customers with the use of our pre-build embeddable UI components, that are fully customizable and overcome the recursive concept of Authorization for Authorization.
The Permit object model
Your workspace, or in other words, your organization, is at the root of the Permit object model. Within your workspace, you can have multiple projects, and each project can have multiple environments, each with its own set of policies and roles.
Project and environments
Projects are the highest level of encapsulation for your authorization. Every unique service or application that requires its own set of policies and roles is a project. In addition, each project can support multiple environments – allowing different policies for different deployments or configurations.
The Policy Editor
Writing and maintaining good authorization policies is hard. Another feature Permit provides is an extremely simple-to-use Policy Editor. Policies, in general, are difficult to write, especially if you need to do it all in Rego code – a policy language used by OPA (Open Policy Agent), a common policy engine used by many companies.
We designed the policy editor 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 no-code or low-code interfaces. Permit.io combines the power of this powerful authorization engine with the ease of use of a simple web interface.
The policy editor allows you to create multiple types of authorization models including – RBAC & ABAC. Role-based access control (RBAC) is the simplest policy to implement. It consists of a role, a resource, and the action you are performing on the resource. RBAC allows us to analyze the needs of particular users and group them into roles based on common responsibilities.
As you start working with policy creation, you will quickly realize that RBAC might not give you the granularity that you need. This is where Attribute-based access control (ABAC) comes in.
What makes up an ABAC policy?
Attribute-based access control is an authorization model that evaluates attributes (or characteristics), rather than roles, to determine access. The purpose of ABAC is to allow users to define more complex access-control rules to prevent other users from unauthorized actions — those that don’t have “approved” characteristics as defined by an organization’s security policies.
This simplified low-code approach to ABAC, where we can define user sets, resource sets, and manage them in a simple policy table is patented by Permit.
User sets
User sets are groups of users that adhere to predefined attribute-based conditions. These are conditions based on individual user characteristics.
Resource sets
Resource Sets are groups of resources that adhere to predefined attribute-based conditions. These are conditions based on the environment a resource exists in (e.g. time and location).
User management
Users can represent both people and automated entities. Users are assigned to tenants (each user can belong to more than one tenant) and can then be assigned roles and permissions. The roles and permissions granted to the user will decide what actions in your app will be allowed or denied for that user.
Tenants and multi-tenancy
A tenant is a silo of users and resources that share a common organizational identity. Usually, each tenant will represent one of the end-customer companies in your product (e.g. the company that you sell to). With the tenant feature, we enable you to have multi-tenancy straight out of the box.
At its core, multi-tenancy allows every part of the service (i.e. every microservice) to cater to multiple customers without deploying separate instances for each. Most modern applications, especially microservices-based ones, require some degree of multi-tenancy.
Audit logs
Knowing who has done what in your application is critical for multiple reasons, including security, compliance, debugging, and even just plain old monitoring. Audit Logs are a great way to track who did what, when they did it, and why they had permission to do so. They are a useful tool both for you and your team as the maintainers of your application, but also for your end-users, who want to track their own usage and actions within the app.
Permit elements
Permit Elements are a set of prebuilt and embeddable UI components that provide fully functional access control, allowing you to safely delegate them to your end users.
Permit provides many out-of-the-box authorization elements such as User Management, Audit Logs, Approval Flows, API Key Management, Emergency Access – the list goes on and on. Below is an example of the User Management live configuration and preview view.
If you are thinking of implementing authorization in your system, or have a homebrew solution in place that you think needs an update to be more sustainable – learn more about how we can help by visiting www.permit.io.