Demonstrate stac-auth-proxy for user-private collections in EOEPCA

[j08lue]

Some EOEPCA platforms have the need to distinguish between public and (user-)private resource collections in their data catalogue.

stac-auth-proxy is a versatile solution that

• abstracts the STAC-specific part
• provides recipes and hooks to implement platform-specific logic
• right in a FastAPI STAC API runtime (stac-fastapi-pgstac, stac-fastapi-*), such that there is no reverse HTTP proxy (with all the complexity that adds) but just logic right in the STAC API

We would like to bring this solution into the Data Access building block and document the following concepts

1. eoAPI STAC API can distinguish between public and user-private collections
2. we have a nice and documented way to configure which collections belong to which user (dedicated fields in STAC?)
3. we review whether/how this could be applied to the STAC API provided by pycsw
4. we review whether/how this could work for OGC API - Records provided by pycsw
5. we compare it with existing solutions such as GeoNode / pycsw
   • please consult @kalxas - something with repository filters, perhaps?

Acceptance criteria

• stac-auth-proxy deployed with Data Access BB in DLR terrabyte and/or the EOEPCA+ dev cluster
• configured to filter collections that belong to individual users (platform IAM)

[j08lue]

This is how the NASA VEDA STAC API filters collections by tenant: https://github.com/NASA-IMPACT/veda-backend/blob/dbd05924d7c04eeeec9ed88cc445a7b33a312261/stac_api/runtime/src/app.py#L93-L136

[pantierra]

Yesterday, @achtsnits, @alukach, and myself had a meeting and discussed our approach to STAC API access protection.

We agreed that we will use stac-auth-proxy internal record-level-auth capabilities for collection-item and item-level filtering.

The PR EOEPCA/eoepca-plus#78 introduces the basic structure for enabling stac-auth-proxy and preparing the eoepca_filters.py to add the permission business logic there.

Sidenote: We also discussed relying on OPA for the permission logic, as this is being used overall on the system, but we discarded it unanimously that this will introduce limitations (on the STAC search in particular) and will make the OPA rules most likely much too complex.

In next steps we can build up the actual permission logic in iterative steps, test and adjust until it fits.

[j08lue]

Framework implemented, filtering logic needs to be added based on project needs.

Reducing resources from 80 hours to 60 on this ticket, follow-up work in

• Implement permission logic for STAC API for EOEPCA+ demo #203