Custom authorization logic

[pantierra]

While the integration of stac-auth-proxy in (#222 and #358) provides OIDC-based authentication, some deployments may require custom authorization logic beyond the default endpoint protection. For example:

• Collection-level access control (e.g., user A can read collection X but not collection Y)
• Item-level permissions based on custom attributes
• Role-based access control with custom roles defined outside the OIDC provider

Currently, stac-auth-proxy validates tokens and protects endpoints, but doesn't provide hooks for custom authorization decisions.

This is to discuss our approach to this and then implement a solution.

[batpad]

Had a good chat with @alukach around this -

My understanding is that stac-auth-proxy already allows you to define custom Class Paths for an Item filter and / or Collection filter: https://developmentseed.org/stac-auth-proxy/user-guide/configuration/#collections_filter_cls

If I understand correctly, the rough proposal would be:

In eoapi-k8s allow specifying something like: CUSTOM_COLLECTION_FILTER: myfilter.py and create a myfilter.py with your custom filter definition (@alukach to help with an example) - then, as part of the deploy, we just set COLLECTIONS_FILTER_CLS to like stac_auth_proxy.filters.myfilter and handle mounting / copying myfilter.py to the correct location in the container before starting the app.

This sounds to me like it would be the quickest way that builds upon what we already have and allows for customization of the filter logic to fairly arbitrary requirements. This avoids needing to build separate containers for each instance, and each instance only needs to manage their custom filter code.

@emmanuelmathot @pantierra does this seem to make sense? @alukach does this seem to line up with how you're understanding things based on our discussion?

[alukach]

Implementation on IFRC-Go here: IFRCGo/go-deploy#144