Develop custom access control plug in

[gabrc52]

Features

• You can make semi-unfederated rooms
• You can restrict rooms to specific affiliations (such as student, affiliate, staff)
• You can restrict rooms to a specific moira list or set of moira lists
• Instead of Moira lists, this should ideally be extensible to allow other things people in the general Matrix ecosystem may want. This way, it could be turned into an MSC.
• You should be able to chain rules, for example allow people in any of these 2 lists, or allow any students but non-students in a certain list are allowed
  • how far do we want to go? do we want to have an AND operator, or just an OR operator? any boolean expression? For now let's stick with allowing people if (A1 OR A2 OR A3 OR ...) AND NOT (B1 OR B2 OR B3 OR ...)
• You can optionally make invites override the rules, so that invited users can bypass the rules
• For now, we just need the student-only rooms and can leave other things as unimplemented

Implementation

event name: edu.mit.sipb.custom_acl
state key can be an empty string since we have no use for it

• It might make sense to take the design of m.room.server_acl as inspiration or maybe even make this into a superset of it. Same for m.room.join_rules.
• Each type has a name, which in a MSC would be namespaced but for now we don't need a namespace. Either way, they could become namespaced when migrating to an official event. Note that m.room.join_rules is already namespaced, and so far only supports m.room_membership. We still need to put some thought in how to make it compatible with m.room.join_rules, since we can technically add our own namespaced stuff to it already.
• There is an allow and deny property, and it follows the same logic as the server ACL:

1. if there is no such event, allow
2. if any of the deny entries is satisfied, deny
3. if any of the allow entries is satisfied, allow
4. otherwise, deny

Types

• In general, everything m.room.join_rules and m.room.server_acl already support.
• exact_homeserver: Match a homeserver exactly
• homeserver_glob: Match a homeserver glob
• ip_literal: Match any homeserver that is an IP literal
• moira_list: ACL for the given moira list, as long as the list is either an AFS list or a list the server's kerberos identity has access to read its membership (any non-hidden list or any list daemon/matrix.mit.edu can administer)
• affiliation: Match a specific affiliation
• invited: Match people who are invited to the room. It should match with true if it meant the joiner was invited, otherwise it would match with false.
• mit_community or even mit_alumni (TBD, needs thought but it needs to be an option): Match MIT community members or alumni regardless of what homeserver they are in. This would require a way of verifying their identity (in a similar style as Discord verification, your entry would get denied and you'd get a DM to verify, and then our integration could remember you for future rooms).

Error messages

Element relays the error messages from the homeserver, so if someone tries to join a semi-unfederated room as in the example below, it would be better for the error message to say You are not invited to this room or for the other example You are not invited to this room, please ask a MIT student to invite you.

I don't know how to implement custom error messages while also allowing full flexibility, but we could handle a few special cases, and return a generic error message otherwise. It is also possible that for the case of the moira list ones, we may not want to tell people why they were rejected from a room.

Examples

These are all illustrative but within the MIT context, and do not mean I endorse having rooms like that.

Semi-undefederated room: only people in our homeserver can join unless they are invited

{
  "allow": [
    {"type": "homeserver", "value": "matrix.mit.edu"},
    {"type": "invited", "value": "true"},
  ]
}

Allow anyone in ec-discuss or r-h-t

{
  "allow": [
    {"type": "moira_list", "value": "ec-discuss"},
    {"type": "moira_list", "value": "r-h-t"},
  ]
}

Allow all MIT students or anyone who was invited to the room

This is what we need for classes.

{
  "allow": [
    {"type": "affiliation", "value": "student@mit.edu"},
    {"type": "invited", "value": "true"},
  ]
}

Allow all MIT students and allow all SIPB members regardless of whether they are a student or not

{
  "allow": [
    {"type": "moira_list", "value": "sipb"},
    {"type": "affiliation", "value": "student@mit.edu"}
  ]
}

Allow all EC residents except Tetazoans

{
  "allow": [
    {"type": "moira_list", "value": "ec-residents"}
  ],
  "deny": [
    {"type": "moira_list", "value": "3e-residents"}
  ]
}

Allow MIT kerb-holders (through matrix.mit.edu) who are not MIT students

{
  "allow": [
    {"type": "homserver", "value": "matrix.mit.edu"},
  ],
  "deny": [
    {"type": "affiliation", "value": "student@mit.edu"],
  ],
}

Allow only invited students

Since this would require an AND, it is not implementable through this current proposal, but it can be done by combining a join rule event with this event. If we do a MSC, care is to be taken so that things like this still work.

Notes

• We should get its own repo for it since we want docs and other stuff.

[gabrc52]

Thinking of it a bit more, I'm not sure how this all plays in with federation. I was assuming our home server would be the arbiter but there are more homeservers and this is why the spec about server ACLs has this whole thing about how to deal with noncompliant servers.

Let's just do a simple plugin which handles the classes part first and then actually work in making a new plugin we can publish. The MSC can be a draft since I'd be able to get feedback and iterate.

Rooms don't just live in one home server and if you can't join via one you can join via another.

This means if you let one person from one server in you might be letting in everyone else in that home sever.

[gabrc52]

Yeah it's probably not a good idea to send a MSC yet since they have plans of adding role-based access control and if that is so we might be able to mirror moira lists to that

[gabrc52]

Also we might want to hook user_may_invite too otherwise people might have stuck invites or invites they just can't join and can only decline

[gabrc52]

Also note that the Synapse module API allows returning specific error codes but not messages so that might need work too for friendlier messages