Rocket.chat: Refactor / Improve permissions / channel access control subsystem

Created on 31 May 2018  路  5Comments  路  Source: RocketChat/Rocket.Chat

I really like this project and we are planning to start a closed community (paid) group chat service and would really really like to use Rocket.Chat as the chat platform.. However, it lacks a well organized channel permission / role-based access control subsystem, which makes us unable to use it.. I hope this will be improved soon!!

The main issue with rocket chat permissions is that it's an IRC-style join / invite / kick / ban vs the much much more preferred role-based access control, aka whitelist-based. There shouldn't even be public / private channels, the channel's permissions should make a channel visible / invisible for certain users / groups (roles).

In general, all channels should have a fine-grained permission (ACL) list, "who can do what" with the channel (including channel visibility, join channel, change topic, write messages, speak, attach files, kick, ban, change channel permissions, etc individual permissions). We should be able to manage all channel-permissions on a per-user / per-role basis! And for sure, these permissions MUST be permanent on a channel! The REST APIs should support managing the channel permissions as well. Global channel permissions (join, read, write messages, manage channel permissions, etc) would be great as well, which should override the channels permissions.

There are a huge amount of private (and paid!) chat communities nowadays (financial sector, including crypto chats as I saw in some tickets here). And for these, a fine grained, hierarchical (channel- and system-) permissions system is a MUST!! Eg. they must be able to set up their channels' security based on roles and add/remove users to/from roles based on the users' (active) subscriptions. Rocket.Chat has a role-based access control system, which is great.. Only the channels don't support it properly :(

I saw the 'subscriptions' user / channel relation and also that private channels have a manageable members list.. But its really not how it should work! The users should freely join / leave any channels or make interactions with the channel (write messages / send voice notes, attachments, etc), exclusively controlled by the user's (and the roles' the user is assigned to) global or channel-specific permissions! Currently, if I add a member to a private channel, the user is automatically added / force-joined the channel.. This is not good and very far from a consistent, clear, long-term viable acl/permission system.

So, do you think this this is something that the team can / is going to refactor / improve soon, or shall we look for other solutions instead?! Apologies if something I wrote does not reflect the truth, I am new and if we finally choose to get started with it, I am more than happy to contribute to the project! Thanks!

Most helpful comment

So, something like Discord's "channel overrides"?

All 5 comments

So, something like Discord's "channel overrides"?

Exactly! Discord has this the right way, it has global and channel-specific permission table. Global overrides the channel-specific ones. And it's whitelist based, so by default no one has permission to anything.. But of course, when you create a new server or channel, there are pre-defined general roles (admin, moderator, user) and permissions for the sake of simplicity.. But you can adjust / fine tune them, eg. remove all permissions from a channel and add only specific users or specific roles with variable individual permissions.. Then everything, including whether the users can see / join / interact with the channels are based on this. It gives a clean and fine grained access control and a good base for this product's long-term future.. It also makes it easier to integrate and manage programmatically (with APIs).

I understand that this is a bigger change / refactor. But since Rocket.Chat is still in the v0.x.y phase, it's better to change and adapt to a good design now than to live with a flawed one, which would just create more and more issues in the future.. I hope you guys agree on that.. If not, let me know, might be a good and useful discussion anyways..

I see this issue is on the to-do list, but I'll add support for it.

The server I administer has what amounts to three practical user roles. Each role has slightly different permissions and wildly different private groups. Being able to control at the role level, rather than the individual level, would be a security-and-convenience lifesaver.

Ultimately, I need a matrix of permissions vs. private groups at a role level, with some ability to override on a per-user level. Much like the Discord model.

Right now, I'm okay with roles for global permissions, but manually assigning 14 groups to one user role by going to each group and inviting the user individually is ... tedious, and open to error.

@marceloschmidt

There are several similar ban Issues. I was going to close this in favour of feature request.
Is this going to happen? If not would it be better to close them all and leave the NFR?

https://github.com/RocketChat/feature-requests/issues/25

Going to throw my support behind this as the biggest obstacle to adoption for me at my company. We use Discord in the (small) IT team, and the easiest part has always been managing roles and permissions for groups of channels because of the way that platform can group channels with inherited permissions (overridable too!), and roles can easily have permissions assigned to them. We tried about 10 different chat platforms to overcome the lack of enterprise-wide functionality in Discord that we need for nearly 300 users, and rocket chat came out as clear winner for balance of cost and UX. This particular issue is going to cause a lot of headaches, both in the organization of channels (agree public shouldn't be a specific channel type), and the management of the permissions in each of those channels.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

royalaid picture royalaid  路  3Comments

tanc picture tanc  路  3Comments

Kiran-Rao picture Kiran-Rao  路  3Comments

lunitic picture lunitic  路  3Comments

zeigerpuppy picture zeigerpuppy  路  3Comments