Role Management at Slack

Controlling which users are able to take which actions is no simple task. Building this into Slack has always been an interesting challenge. In large enterprise organizations, the standard types of roles we offered to customers were too broad, and delegating a generic admin role can grant someone with too much power — what if…

Slack logo
Slack
•
Jake Byman
•12 min read•intermediate•
--
•View Original
ChefgRPCJenkinsJSONPrometheusProtocol BuffersPythonTypeScript

Overview

The article discusses the implementation of a granular role management system at Slack, focusing on the challenges faced with existing roles and the transition to a Role-Based Access Control (RBAC) system. It outlines the historical context, the new requirements for roles, and the technical architecture supporting these changes.

What You'll Learn

1

How to implement a Role-Based Access Control (RBAC) system in a large application

2

Why granular permissions are essential for enterprise applications

3

How to ensure backwards compatibility when introducing new features

Prerequisites & Requirements

  • Understanding of Role-Based Access Control concepts
  • Experience with large-scale application architecture(optional)

Key Questions Answered

What challenges did Slack face with its existing role management system?
Slack's existing role management system was too broad, allowing users with generic admin roles to perform actions beyond their intended scope, leading to potential security risks. The need for a more granular control system was identified to ensure users could only access specific functionalities.
How does Slack's new RBAC system work in practice?
In the new RBAC system, when a user performs an action, their permissions are checked against their assigned roles. If they lack the necessary permissions, the system falls back to legacy roles to determine access. This ensures a robust and flexible permission management framework.
What are the new roles introduced in Slack's RBAC system?
Slack introduced three new system roles: Channels Admin, Users Admin, and Roles Admin. Each role has specific permissions, such as managing channels, adding/removing users, and administering roles, allowing for more granular control over user actions.
How did Slack ensure a smooth rollout of the new permission system?
Slack implemented a phased rollout of the new permission system, starting with internal testing, followed by pilot customers, and finally a full rollout. This approach allowed for monitoring and adjustments based on feedback and performance metrics.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Backend
Grpc
Used for communication between the web application and the permissions service.
Database
Vitess
Used for persisting role information and enabling efficient data retrieval.
Backend
Protocol Buffers
Utilized for defining the communication protocol between services.

Key Actionable Insights

1
Implementing a granular roles system can significantly enhance security and user management in enterprise applications.
By allowing specific permissions for different roles, organizations can minimize the risk of unauthorized access and ensure that users only perform actions relevant to their responsibilities.
2
Utilizing a phased rollout strategy for new features can help mitigate risks associated with deployment.
This approach allows teams to gather feedback and make necessary adjustments before a full-scale launch, ensuring a smoother transition and better user experience.
3
Maintaining backwards compatibility is crucial when introducing new systems to avoid disrupting existing workflows.
By ensuring that new features work alongside legacy systems, organizations can provide a seamless experience for users transitioning to updated functionalities.

Common Pitfalls

1
Failing to account for legacy permissions when implementing a new RBAC system can lead to access issues.
Without proper integration of legacy roles, users may find themselves unable to perform necessary actions, leading to frustration and decreased productivity.
2
Overly broad role definitions can create security vulnerabilities within an organization.
If roles are not defined with specific permissions, users may gain access to sensitive information or functionalities that are not relevant to their job, increasing the risk of data breaches.

Related Concepts

Role-based Access Control
Granular Permissions In Software Systems
Enterprise Application Security
Phased Rollout Strategies