When a user performs an action, we check the permissions needed for that action. When a user takes an action, the ability to take that action is checked based on whether the user has a role that encompasses the needed permissions. Role-Based Access Controls (RBAC)Ī system in which users are granted access to certain resources based on their role in that system. For example: in an Enterprise organization, someone can be a Channels Admin across an entire company (where the entity is the Enterprise), or on a single workspace on that enterprise (where the entity is the workspace).
A role is assigned with respect to an entity. EntitiesĪn entity is an object in Slack for which we assign a user a given role. For example, a role could be a Channels Admin, someone who is authorized to make administrative changes to channels, such as the ability to create, rename, and archive. RolesĪ role is defined as a set of permissions.
Slack open roles archive#
For example, the ability to invite a user to your workspace, to archive a channel, or to view users across your organization. PermissionsĪ permission is defined as the ability to perform some action in Slack. A walk-through of our data modelīefore diving into how we solved this problem, let’s get some terminology clear first. We need the ability to delegate these roles at an organization level (for our Enterprise Grid tier of customers) or at the workspace level. We opted to create a Role Based Access Control (RBAC) system, such that users can be granted one or more roles that are given the permissions associated with those roles. Additionally, we needed to make sure the existing roles worked alongside this new system. We needed a granular roles system to break down the core abilities of the generic admin users. This type of user is able to take any administrative action. This is the head administrator of the organization.This type of user has the ability to perform the administrative actions above, as well as additional compliance abilities, such as the ability to set up Data Loss Prevention (DLP) and retention settings.Users with this role perform the majority of administrative tasks across a team. This type of user is the basic administrator of any organization, and can make a wide variety of administrative changes across Slack, such as renaming channels, archiving channels, setting up preferences and policies, inviting new users, and installing applications.When an administrative change needs to be made, these users need the support of admins and owners to make the changes. This is the base type of user that does not have any particular administrative abilities, but has basic access to the organization’s Slack workspaces.This type of user is limited in their ability to use Slack, and is only permitted to see one or multiple delegated channels.To date, we’ve had limited roles for what users are able to do. We’d like to share the problems we were facing with roles, the solution we implemented, and our plans for the future. We needed to build a system that was more flexible and allowed for granular permissions. 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 you only want a specific user to be able to manage specific channels? When you make them an admin, they are able to perform a wide variety of actions beyond the scope of the intended purpose, and can view dashboards and see information that is unrelated to managing channels. Building this into Slack has always been an interesting challenge. Controlling which users are able to take which actions is no simple task.
0 kommentar(er)
