Introducing the Polytomic Permissions Engine

Today we're launching the Polytomic permissions engine, a true RBAC (role-based access control) system. This is a powerful and extensible system to take care of all your permissioning needs, no matter how nuanced or complex.

What is RBAC?

Role-based access control is a way to restrict system access to users based on their designated roles and what permissions are enabled for said roles.

That's a mouthful so let's use an example :). Consider a Sync Editor role. This role may only have permissions to edit syncs but not anything else: editing models, adding users, and modifying connections are all disallowed actions. Any user whose only role is this one will be unable to do anything except edit syncs.

The Polytomic permissions engine

Our permissions engine consists of three building blocks:

- Users
- Roles assigned to users
- Security policies with particular actions enabled for designated roles

Both roles and security policies can be created in a custom fashion; you aren't tied to the system defaults. It is this property that makes the system powerful.

A security policy is an object containing a list of actions. For example, create, edit, query, and others. Each action can be enabled for one or more roles.

To enforce a policy, attach it to any object in Polytomic (models, syncs, connections, etc).

This allows a rarely-encountered fine-grained level of control. For example, to restrict syncing to Snowflake to a certain role (let's call it 'Data Engineer'), you simply follow these steps:

1. Create the role Data Engineer.
2. Create a policy and allow its sync_to action for the role Data Engineer.
3. Attach this policy to your Snowflake connection.

That's it. From then on, all users' attempts to sync to Snowflake will automatically enforce this policy.

Permissions power

The previous example is a small one. There are many bigger possibilities. Because you have control over individual attributes of any number of policies, you can construct an enforcement framework for whatever you require.

When it comes to permissions, many apps offer a preset list of roles to choose from. But that proves too restrictive as your organization grows. What if you want to enforce permissions that aren't covered by the default roles? It's impossible to anticipate every team's needs.

We have chosen to set default roles and policies in addition to the permissions engine. This way the best of both worlds is obtained: you can ignore everything and stick with the defaults if you need nothing more. But if you do, you have the comfort of knowing you can design and enforce to your requirements

To read more details you can head over to our documentation. And, as always, feel free to get in touch with any questions or comments.