Slack is a pioneer in team communication and collaboration. Over 150K companies globally use the platform for internal and external communication, customer support, and community management. And with 18 million monthly active users the platform is a great real world example of combining role-based access control (RBAC) with fine-grained controls at scale.

Slack provides pre-built roles for admins to manage access to their Slack instances. The number of roles available vary by plan, with five roles available to the free tier and 23 to the enterprise tier. The platform also provides admins with finer-grained controls over some resources. Examples include private channels that are only visible to certain users, and the entitlements available to “Channel Managers” and “Org Admin” roles.

In this post, we delve into these granular roles and permissions, as we explore how they shape access levels within the platform. We then introduce a relationship-based authorization model that provides an elegant way to combine roles and access control lists (ACLs), and paves the way for fine-grained authorization. Read on for all the details.

Roles in Slack

RBAC is a popular authorization model where permissions are aggregated into roles that are assigned to users or groups. It’s simple to set up and reason about, and for those reasons it’s typically the first authorization model organizations implement. However, it does have some limitations. These roles are typically coarse-grained, meaning that they apply across the board. A “Full Member” role in Slack, for example, provides users with access to every public channel in the workspace; we cannot limit their access to specific channels. Private channels are the exception to the rule - more about that later.

Slack provides eight roles that apply across a workspace. These roles are the following, from least to most privileges:

• Invited Members
• Single-Channel Guests
• Multi-Channel Guests
• Full Members
• Channel Managers
• Workspace Admins
• Workspace Owners
• Workspace Primary Owner

Guests and “Channel Managers” are only available on paid plans. Guests have limited access to Slack and can only access a single channel, or a subset of channels. “Channel Managers” have administrative privileges over the channels they are assigned, allowing them to rename or archive the channel, convert a channel from public to private, and more. Here’s the full breakdown of permissions per role.

Combining RBAC with fine-grained access controls

Combining coarse-grained roles with fine-grained permissions is a popular pattern among applications, and Slack is a great real-world example of that pattern at scale. While this is more common among the permissions available for the paid plans, private channels are an example that is available to all plans.

In contrast to public channels, which every “Full Member” can discover, join, and engage with, private channels are only visible to users that have been invited to them. This is an example of fine-grained permissions, as the user’s role alone does not provide them with access, but a combination of a global role and channel specific permissions.

The “Channel Managers” role is another example of finer-grained entitlements in Slack. These users have administrative rights over the channels they are assigned to. They can change the name of the channel, convert it from a public channel to a private one, and even archive a channel.

While “Channel Managers” have the same entitlements over every channel they are assigned, they do not have the same rights and privileges over the other channels in the workspace. These channel-specific permissions are real-world examples of fine-grained access controls. To execute these privileges a user needs to hold the “Channel Managers” role and be assigned to the channel they are attempting to administer.

Enterprise customers have access to three additional roles that further demonstrate the combination of roles with fine-grained controls on the platform. The “Org Owners” and “Org Primary Owner” roles provide users with administrative permissions across workspaces, allowing them to add a channel to multiple workspaces, manage SSO, and more. The “Org Admin” role provides users with administrative privileges over a single workspace, or subset of workspaces under the organization. This is a real-world example of multi-tenant RBAC.

Relationship-based access control (ReBAC) provides an elegant way to combine RBAC-based roles and fine-grained access control lists, which are typically implemented as separate constructs. Using a relationship-based model, we can define “roles” on object types such as workspaces and channels that grant permissions on individual resources.

Relationship-based access control (ReBAC)

ReBAC focuses on dynamic relationships between users and resources rather than static roles, allowing for more granular, adaptive access controls. By using relationships, ReBAC reduces the need for creating multiple specific roles or ACLs and provides a more flexible authorization model. Learn more about RBAC vs ReBAC here.

Anyone that has ever used Google Drive has experienced the fine-grained access controls that come with ReBAC. Zanzibar, Google’s unified authorization system that powers Drive, Docs, Maps, and other popular Google apps, uses a ReBAC model. In fact, the Zanzibar paper, where the search giant shared details about its authorization service, popularized this authorization model.

In Drive, we can share a document with others and determine the level of access they have (“Viewer,” “Commenter,” “Editor”). We can also share a specific folder, or subset of folders, with users, who gain access to all the documents nested within those folders. These granular permissions are what is lacking in RBAC, and achievable with ReBAC.

If we were to model Slack’s authorization system using ReBAC we could create a simpler authorization model that also expands the possibilities of finer-grained authorization. Below is a simplified example of how we could model workspaces and channel permissions using Aserto’s ReBAC modeling language:

model:
  version: 3

types:
  user: {}

  workspace:
    relations:
      channels_admin: user
      guest:          user
      legacy_admin:   user
      member:         user

    permissions:
      can_administer_channel: channels_admin | legacy_admin

  channel:
    relations:
      parent_workspace: workspace
      commenter: user | workspace#member
      writer:    user | workspace#member

    permissions:
      can_delete:  parent_workspace->can_administer_channel
      can_write:   writer    | can_delete
      can_comment: commenter | can_write
      can_read:    can_comment

And here’s a graphical representation of the same model in the Aserto Console:

Go here to download the full manifest.

Seamlessly transition from RBAC to ReBAC

Tools like Aserto and its open-source authorizer Topaz make it easy to harness the power of ReBAC. Topaz supports RBAC and ReBAC out of the box, allowing us to seamlessly transition from one to the other, or combine the two, to provide resource-level controls.

Topaz is fast, flexible, and easy to implement. It offers ~1 millisecond authorization decisions, supports every authorization model, and is easy enough to implement that a single developer can get a POC launched in a day and production-ready in a couple of weeks.

Aserto makes it trivial to write an authorization model for your application - just start with one of our templates (such as the Slack template), and evolve it to fit your needs.

Conclusion

Slack provides users with a combination of pre-built roles and fine-grained authorization to manage access to their workspaces. Combining RBAC with fine-grained controls is a popular authorization pattern among multi-tenant SaaS applications. And while RBAC is a great model for some use-cases, and a popular one too, it has some limitations.

ReBAC is a flexible, graph-based authorization model that enables resource-level authorization. We can use ReBAC to model Slack’s current permission model in an elegant manner, and pave the way for a seamless transition to fine-grained authorization.

Topaz is an open-source authorizer you can use to experience fine-grained authorization for yourself. It supports RBAC, ABAC, ReBAC, and any other *BAC :-) It provides ~1ms authorizations and is “falling off a log” easy to implement. You can launch it in your cloud today to experience fine-grained authorization for yourself.

As always, we’d love to hear what you think! Feel free to share your thoughts or any questions you might have in the Topaz community Slack.