One year ago, as the first engineers were joining the team and the first lines of code were being written, we started writing a document called, ‘Thinking Bout Permissions.’ It might seem odd to consider the permissioning model for a product that doesn’t exist yet, and you might also be surprised to learn this document grew to 15 pages of notes, analysis, and proposals about how Omni’s permissioning system could work. We didn’t do this because we think permissions are fun; we did it because we know they are important.
All of this thinking and work leads up to today when we announce the commercial availability of Omni along with a new user permissions system.
Designing a permissions system
The design of a permissions system revolves around choices like which resources and actions can be permissed, how permissions can be granted (and by whom), and what the default permissions are for new users and resources. These choices have a huge impact on how collaboration, security, and administration work in the product.
Google Drive, for example, applies permissions at the document and folder level, gives document creators the power to share and manage permissions for their documents through roles like Viewer, Editor, and Commentor, and defaults to keeping documents in their creator’s private folder. The resulting system is one that emphasizes decentralized ownership and control - even when Drive is adopted by an organization, documents are still private to their creator until shared, and the creator has the power to share their documents with anyone.
This gives users tons of flexibility and is great for peer-to-peer collaboration, but also makes it hard for users to understand what they can access and why, and to find documents that were shared directly from other users’ private folders. I can’t tell you how many times I have shared a link to a document and then had someone ask for permission to it.
Drive’s shared folders offer a more centralized structure to try to balance this out - documents inherit permissions from the folder they are in, users can search across all shared folders they can access, and administrators can grant access to folders to users and groups in a centralized way. But even with folders, Drive’s decentralized core shines through: individual users still own and control the documents they add to a folder, and it’s way too easy to change the permissions of a single document in a folder to have different permissions than the folder defaults.
AWS, on the other hand, made a different set of choices. In AWS permissions policies can be tailored to every type of resource and action (thousands of them), permissions are managed centrally in the AWS IAM service by administrators through a custom policy language, and by default users get access to nothing. As a consequence, there’s no concept of direct sharing between users in AWS - if a user needs access to a resource, they have to ask an administrator to change their permissions to allow it. Having all permissions managed centrally keeps administrators in control, but the level of power and flexibility offered by the AWS IAM policy language also comes with substantial complexity.
Permissions in Omni
Analyzing these examples and others like them have made us realize that different parts of Omni need different permissions tradeoffs. Specifically:
- Control over which features a user can access (e.g. who can manage users, who can create dashboards) depends on their role, so it is well solved by the classic role-based framework and will typically be managed centrally by a small number of administrative users or configured automatically through SAML.
- Access to content like dashboards should be managed in a decentralized way by the content creator or owners, though administrators also need to be able to manage access to folders of content.
- Control over which data a user can query and see depends not only on the user’s role in the organization, but often other attributes like which region they are in or which projects they are working on, so an attribute-based model is appropriate.
Today we are announcing the first step toward this vision with the availability of feature permissions in Omni. Users can now be assigned a role for the organization and a role for each connection within it to granularly control their access. The connection roles available today are:
- Connection Queriers can query all data in the connection in workbooks, create dashboards, and create new fields and views within their workbooks, but cannot promote fields or views into the Shared model.
- Connection Admins can do everything Queriers can do, and additionally can promote into the Shared model, edit the Shared model directly, and manage users on the Connection.
The organization roles available today are:
- Admins can change organization level settings and manage users within the organization. Organization Admins are also Connection Admins of all connections within the organization.
- Members can login to the organization, but must be granted permission to connections directly.
These control features, along with our recently completed SOC 2 audit means we are ready to handle sensitive workloads for complex organizations. We will be releasing new permissioning features frequently over the next few months as we work toward our full vision - new roles, user groups, and data and content permissions to serve both internal use cases and others like embedded analytics. Stay tuned!