Implement granular permission handling in stac-auth-proxy -> Monty collections

[batpad]

There's probably a better place for this ticket, but dropping here for now, as a follow-up to #98 -

We now have stac-auth-proxy setup, using GO as the OIDC provider, configured here: https://github.com/IFRCGo/go-deploy/blob/develop/applications/argocd/production/applications/montandon-eoapi.yaml#L113

Currently, stac-auth-proxy functions as a network proxy, validates the token, and if a person has a token, grants access, and if not, returns Unauthorized - i.e. a user either has access or not.

Now, for various use-cases, we need to have an idea of "Private" collections - i.e. some collections that are accessible (read) to a subset of users. We have full control over adding metadata to the STAC collections, as well as what goes into the JWT token, so we need to figure out the best way to:

• Add metadata to the STAC collections to indicate that they are "private", and have a way to associate users with these collections.
• Add metadata to the JWT token generated by GO, which indicates which collections a user has access to - this could be as simple as an array of collection IDs, but we can figure out the schema based on a better understanding of the use-case and implementation.
• Implement collection filters in stac-auth-proxy that filter available collections for a user based on metadata in the JWT token for the user.

In terms of implementation, I think there probably a few different possible approaches on how we configure the custom filtering in stac-auth-proxy - whether this can some-how be added as configuration, or we need to create a custom run-time for stac-auth-proxy including the filters OR a custom run-time for stac-fastapi, including stac-auth-proxy as Middleware and not as a network proxy. There's probably things that I'm missing, so will be good to discuss and figure out how best to approach this.

cc @emmanuelmathot @alukach @thenav56

[batpad]

Link to ticket in eoapi-k8s where we are discussing a common approach to granular permissions: developmentseed/eoapi-k8s#370

[alukach]

Braindump:

This all sounds pretty straightforward. Figuring out how we want to manage associating collections to users is probably the most complicated portion.

Okay, so let's try to boil this down to some rules:

1. All collections are by default public (i.e. available to any user including anonymous users) unless they are marked with private: true. This sounds like a pretty safe/reasonable assumption.
2. If an authenticated user has the admin scope, they can see all collections. I suggest adding this in as staff likely will want to opt-out of the permissions logic.
3. If a user is authenticated and not an admin, we need to determine which collections they are permitted to access. The simplest way is to just store those in an array on the JWT (as @batpad hinted). I think the determination of whether or not this is a valid strategy comes down to a) how much of a burden it would be for system administrators to associate users with collection IDs; b) how many collections a user would likely have associated, <25 is probably fine, but any more might mean that it would be cumbersome to retain those in the JWT. An alternative to JWTs could be standing up an additional service that would manage the mapping of users to collections. Some simple like a REST endpoints built onto the STAC API (allowing for collection ID validation via db constraint) would be a straightforward approach (SwaggerUI could probably serve as enough of a UI for admins).

Regardless of how 3) shakes out, we will likely need to build out CQL2 filter factories for both the Collections and Items endpoints. Those will be pretty simple in terms of implementing the above logic. I think it may be easiest to simple run a custom stac-fastapi-pgstac wherein we can buildout the CQL2 filters in Python and instead run the STAC Auth Proxy as middleware.

Alternative to building out our own CQL2 filter factories, we could lean on something like Open Policy Agent but I don't know if that brings in a lot of value in this situation as we would still likely need to maintain a mapping of users to collections in some other API or datastore as I'm not aware of OPA having an interface for doing basic record management.

I think we should jump on a call to validate this and then start implementation.

[batpad]

@alukach that all sounds about right.

Minor things:

All collections are by default public (i.e. available to any user including anonymous users) unless they are marked with private: true. This sounds like a pretty safe/reasonable assumption.

Minor clarification: the idea is that nothing will be available to anonymous users - so, by default, all collections will be available to authenticated users (users with a valid token, not necessarily any specific permissions assigned)

b) how many collections a user would likely have associated, <25 is probably fine

I think its safe to say a user will never have access to more than 5-10 "private" collections (if they need to they can just be superusers)

[alukach]

Minor clarification: the idea is that nothing will be available to anonymous users - so, by default, all collections will be available to authenticated users (users with a valid token, not necessarily any specific permissions assigned)

This confuses me.

Minor clarification: the idea is that nothing will be available to anonymous users

So there's no anonymous access?

all collections will be available to authenticated users

I thought we were using a collections claim on the JWT to grant some private collections to specific users (ie not all collections are available to authenticated users, rather only collections that a user is assigned + public collections)

[alukach]

Okay, after syncing with @batpad, I have updated #144 to work as follows:

• Unauthenticated users will not be able to view any collections or items
• Authenticated users will be able to view collections without a private attribute or with private: false and collections that are referenced by ID within the collections claim of their JWT access token. These users will be able to view items from collections following this same logic. For the items endpoints, we cache the IDs of the public collections for 30 seconds.
• Authenticated users with a superuser claim with a value of "true" in their JWT access token will be able to view all collections and items.