Restrict access to members of a specific group/groups.

[jeet-parekh]

Hello,

Thanks for your work on this amazing product! I have been using outline as my personal knowledge-base since last month. It's been delightful to use.

I think it would be useful to add an option to restrict access to specific groups within a gsuite or slack org. I have some basic code working to enable this feature. But I'm not primarily a javascript developer, so there could be some improvements. I could open a draft PR if you think this feature should be added to outline.

Thanks again!

[tommoor]

Hey @jeet-parekh – we can take a look, but I don't think we'd merge an approach that blocks access to the entire knowledgebase at a group level. I am interested in an approach that syncs Outline groups <-> Slack groups and then allows setting permissions based on those.

[jeet-parekh]

Makes sense. Right now any user within the organization could access outline. The admin has to go in and manually suspend the user in outline to block their access. I have seen many times that organizations add users temporarily to their gsuite or slack. And many times, these temporary users don't need to access the internal knowledge base. I know that ideally this should be minimized, but it does happen. That's my reasoning. Is there any other way to achieve what I'm trying to do?

Outline groups <-> Slack groups

A 2-way-sync? I don't know the internals of outline well enough so I can't comment anything about this. What do you have in mind?

[jeet-parekh]

@tommoor,

I see a minor wording error. What I'm trying to do is allow access only to specific groups. I'm not trying to block access to groups.

By the way, I made the group-level blocking optional on my fork. If that's your concern.
I added a GSUITE_ALLOWED_GROUPS environment variable similar to the GOOGLE_ALLOWED_DOMAINS. If the env var is present, it'll check for group membership.

[tommoor]

I have seen many times that organizations add users temporarily to their gsuite or slack. And many times, these temporary users don't need to access the internal knowledge base

This seems like a fair use-case, I think if Slack groups synced across to Outline then you could set permissions based on that to disallow a group to sign-in. Two way sync not required, that's a mistype on my part. I guess I feel like it makes sense for this feature to be in the UI, not configuration at the server level.

[jeet-parekh]

Slack groups synced across to Outline

Unless you were using slack just as an example... all auth providers would have some form of groups. Since #1183 is in the works, I think it'd make sense to not limit this feature only to slack groups.

If you sync groups to outline, would it sync the group changes in gsuite/slack instantaneously (say around 5 minutes) to outline? Or would it be a manual sync each time something in the group changes? I feel like this relates to #795 a bit.

Right now, my code will check for group membership on each sign in. Two groups - all(at)example.com and internal(at)example.com - people in internal group can access outline. If a user is removed from the internal group, they won't be able to sign in anymore. But I just realised that they might still show up inside outline. But that's not problematic in a self-hosted environment.

[tommoor]

I think it'd make sense to not limit this feature only to slack groups.

Yah, just an example and a good first pass.

If you sync groups to outline, would it sync the group changes in gsuite/slack instantaneously. I feel like this relates to #795 a bit.

You're right that it relates in that both tickets would require storing the OAuth token in the database. It seems like a first version could just sync groups manually from the admin screen, that way the permissions can be requested separately and not lumped into the sign-in permissions request.

Right now, my code will check for group membership on each sign in

What are you using to identify the groups? IDs / names?

[jeet-parekh]

What are you using to identify the groups? IDs / names?

Right now, I'm using group email address. Like internal(at)example.com. I think using group ids or a combination of both would be better. Just to handle the case when a group has been deleted and created again with the same name but different members.