Managing group membership via authentication

[david (David Taylor)]

This is looking very cool!

@angus

I’ve also had to introduce a new concept of “secondary authorization” at the point of authentication

I am a little hesitant about the ‘secondary authorization’ thing, and also the provider_domain column. Can you elaborate some more on why they’re needed? Seems like they’re quite google-specific… is there a reason we can’t request the admin.directory.group.readonly scope during the first auth request? And maybe just prefix the group name with the domain? (or exclude the domain entirely, since I assume people will only be using this with a single google ‘hosted domain’?)

@angus

You’ll also notice that I’ve ended up adding three new tables. I attempted a few more "lightweight’ solutions, but they each ended up being more convoluted and inefficient when it came to handling updates to a user’s associated groups and a group’s associated groups

Yeah totally happy with 3 tables here - it keeps things cleaner

@angus

• Perhaps serialize the associated_groups label (instead of modelling on the client).

Agreed

@angus

• Perhaps move user_associated_group / group_associated_group creation/destruction to a background job, as with large numbers this could be slow.

We need to be careful here. Any group memberships need to be assigned before the user loads the site for the first time. Otherwise, they won’t see group-specific things the first time they log in (e.g. secure categories). So I think changes to user_associated_group records should be processed synchronously.

But for group_associated_group record changes, I think you’re right. Changes there could affect thousands of users, so they will need to be processed in_batches. I think I’d start by doing it synchronously, with a loading spinner in the UI. That way, admins will clearly be able to see when it’s running/done.

If we see it getting close to 30 seconds (the unicorn request timeout), then we might need to think about a background job.

We might also need to think about adding some DistributedMutex locking here. For example, if a user logs in while a group_associated_group change is being processed, what happens? Happy to discuss this kind of stuff on GitHub once we get the overall architecture finalised.