Move shareable authz utilities into Tiled

[nmaytan]

• Code pertaining to access control has been moved into an access_control subdirectory
• The access tags compiler and db schema are made available in Tiled
• Unit test coverage has been added for the new access policy and access control features
• API keys can now be limited to access for only specific tags
• Some improvements/bug fixes

This PR should mean we can close #951

Checklist

• Add a Changelog entry
• Add the ticket number which this PR closes to the comment section

[nmaytan]

Supporting named in-memory SQLite authentication databases is unexpectedly important for the case of creating multiple concurrently logged-in contexts in one process (i.e. for tests).

Tiled loads its configuration as a singleton. If multiple "apps" are created, the singleton is overridden each time. When a context is created for that app, it will use the current value of the singleton. So, if an app + context is created, it will initialize a config singleton (and an authN database according to that singleton). If a second app + context is created, the same thing happens again.

This means that if you gave each app + context a unique authN database URI, the last app + context to be created will have its corresponding URI in the config singleton. This is a problem because if you create contextA -> contextB but then go back to contextA, it will now be given contextB's singleton (which means contextB's database) and, for authentication specifically, contextA will be put in a weird state.

Unfortunately, this exact problem occurs if an unnamed in-memory database is used, because unnamed in-memory SQLite databases exist only for the connection that creates them. Even though the singleton settings are "identical" in this case, each app + context still has a unique database, and contextA still ends up pointing at contextB's database.

To resolve this issue, a named in-memory shareable database can be used. As long as the URI (db name) is identical each time, the config singleton will retain identical values after each recreation for the subsequent context(s). And because this database is now named in memory (and marked shareable), the same database will be used for both contexts - i.e. it will be valid for both of them to use.

[genematx]

I'm thinking, is it possible to declare tag owners in the same section where we declare the main tag definitions? Something like:

tags:
  alice_tag:
    users:
      - name: "alice"
        role: "facility_admin"
        owner: true
      - name: "chris"
        scopes: ["read:data", "read:metadata"]
        owner: false   # default, doesn't need to be set
  chris_tag:
    users:
      - name: "alice"    # here alice is not the owner...
        role: "facility_admin"
      - name: "chris"
        role: "facility_admin"
        owner: true     # ...but chris is
  biologists_tag:
    users:
      - name: "alice"
        role: "facility_admin"
    groups:
      - name: "biologists"
        scopes: ["read:data", "read:metadata"]
        owner: true      # anyone from biologists can apply the tag

i think this would simplify configs and make them more readable. I keep finding myself to having scroll back and forth in the file to check who's the owner of which tag.
Are there any conceptual limitations to this design (e.g. an owner may not be a user of a tag)?

[genematx]

if it's not possible for some reason, maybe adding another key-value pair "owners":{"users":[...], "groups":[...]} under each tag definition could be sensible (essentially merging the two dictionaries together). Right now we have "tags" which contains tags, and then, "tag_owners", which also contains tags (but from a different angle).
When I see a dictionary/list called "tag_owners", I'd expect to find user/group-names there with corresponding tag-names under each of them, not the other way around.

[nmaytan]

Good question - I agree there is a small cost in ergonomics for having them defined in separate tables. This consideration has come up in design discussions, and the reason we decided to separate these is that it's plausible that these tables may each be subject to different permissions. i.e. different roles in the organization may have rights to modify who can apply a tag but not the permissions that tag confers, and vice versa.

This is something we can discuss further, but probably deserves a separate conversation/PR.

The structure of the table just reflects that tags are the focus item, but this direction (vs the inverse) also helps with deduplication & makes it easier to understand in totality who owns the tag.