This is a follow-up to https://pagure.io/fedora-infrastructure/issue/9580, inspired by my discovery of the Communishift Authorization Operator, which is very similar to (at least part of) what I want.
As Kevin notes at the end of that ticket, upstream doesn't seem to be going in a helpful-for-our-use-case direction with this, so a little system to keep things in sync seems best to me.
I want to one-way sync FAS group membership information to Discourse (specifically, https://discussion.fedoraproject.org/). If a user is added to or removed from a group in FAS, and that user has a Discourse account and there is a Discourse group of the same name, the Discourse user should be added to (or removed from) the corresponding Discourse group.
As a bonus, this can solve another problem: if an account is locked, disabled, or deleted from FAS, the Discourse account should also be locked.
Here's what I envision:
But wait! Before you think "that's too many steps for a mini-initiative!" —
I am familiar with the Discourse API. But I'm not with fasjson. It doesn't look complicated, but then I realized there's a whole bunch of yak-shaving to do around getting a keytab and setting it up so that's available and authenticated and running in infrastructure. And it looks like you have already shaved that yak! — that is, all of these things are very close to what Communishift Authorization Operator already does.
Because most of this is what Communishift Authorization Operator already does, I really hope that this will not be a lot of effort.
I had originally imagined this would trigger on webhooks from discourse. We could still do that, but I think it makes more sense to listen to Fedora Message Bus messages for group changes (https://fedmsg2.readthedocs.io/en/latest/topics.html#fas).
However, there is something I don't understand -- there is fas.group.member.remove, but no fas.group.member.add. (There are .sponsor and .approve, though.) Hopefully you know what's going on here.
We'd also want to trigger on the account being deactivated or disabled — fas.user.update, I guess.
These could trigger different paths in my part of the code (remove, add, disable) but that has more risk of getting out of sync. I think it's better to just send user and grouplist and be done.
In case a message gets lost or out of sync, there probably should also be some occasional out-of-band double-check.
This could all live in the same codebase (maybe all running as one toddler), or the first part (the fas listener) could make a remote call of some sort -- a JSON http POST with the username and a list of groups. (And some auth token!). Maybe something running in OpenShift? I can work with whatever you think makes sense.
The actual code should be pretty simple, and I'll make sure to comment it well so that anyone else can, in the future, fix any issues or make updates.
We're finally getting Enterprise hosting, which will let us combine the Ask and Discussion instances. Having group information will allow us to link permissions for posting in certain areas to group membership, allow teams to polls of just their team, allow teams to get notifications, and so much more. We could also make it so Fedora contributors in certain groups get automatically put to "not a newbie" level (which avoids some frustrations with limits on image uploads, etc.). This will be important as more teams move from mailing lists.
Note: I've edited this a bit since first filed!
Metadata Update from @zlopez:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: dev, high-gain, high-trouble, mini-initiative
Hey, so, I've tried to make this as not-high-trouble-at-all as possible:
Is there anything else I can do for y'all, or do differently, to possibly get this down to "medium-trouble" at least? What are the next steps?
This is looking very similar to what we did with the communishiftauthorization operator.
@mattdm would you be able to provide an API key on the Discourse side, that has enough CRUD permissions for users and groups that we can start testing against?
Just confirming here that you are working on this now @dkirwan ? :)
This is being worked on by @dkirwan and @lenkaseg.
Metadata Update from @zlopez:
- Issue assigned to dkirwan
to comment on this ticket.