Support for multiple agencies

[mrsimpson]

Motivation

When offering a solution based upon MDS core to multiple agencies (cities), it is essential that each agency can only access its own data, particularly geographies, policies and audit results.
Currently, MDS core does not feature such a partitioning, as per what we've seen so far.

Ideas

Declaring ownership

1. An organization as owner of data: For each entity which needs a scoped visibility, explicitly add the owner (the agency) to the database.
2. An individual as owner of data: For each entity, persist the human who created the instance along with it. During each interaction with the MDS APIs, the JWT token may contain information about the individuals from which data is allowed to be seen.

How and when data is filtered

a) During each interaction with the MDS APIs, the JWT token may contain information about the owner. If specified, the repositories implicitly add another filter (for the organization or the owning individuals).
b) A middleware could filter which data before it's getting returned. This could also be achieved by maintaining the information in metadata of each instance.
c) Finally, it is an option to pre-filter candidates of each entity: In an external persistence, the information about ownership is being persisted. When reading data, this storage is queried first, candidate identifiers are being retrieved and passed on as filters to the actual query (e. g. an array of policy_ids).

In our current implementation, we're using variant 1a, as it's the most straight forward one when in control of the whole "request to database" chain. We'd also like to contribute that, but it'd be a change in a lot of places, so we'd first like to get your ideas and a judgement about which type of contribution you'd accept.

[janedotx]

If no data sharing is required between agencies, then we stand up different environments per agency. If data sharing is required between agencies, we managed permissions using jurisdictions: https://github.com/openmobilityfoundation/mobility-data-specification/blob/26705816a4dd23d23a41cbd24d99948d2674b6f0/jurisdiction/README.md

Hope that helps.

[mrsimpson]

@janedotx Thanks for the insight! When we had a look at jurisdictions, we came to the conclusion, that those are a different from an agency: While we were looking for an option to serve multiple cities within the same SaaS-offering (an organizational, non-physical grouping), jurisdictions were a geographical entity that is governed by one or more agency

Jurisdictions are an optional service that are served by a coordinated group of agencies.
Within a collection of agencies under a single MDS software deployment, those agencies need to coordinate and share relevant data between one another when their jurisdictions overlap.

When adapting MDS core for our purpose, we therefore decided not to use jurisdictions but instead implement Row Level Security in Postgres to make the runtime tenant aware (without changing all the APIs).