Closed drnextgis closed 1 year ago
I am not sure STAC specification aims at defining access control over catalogs. Auth strategy is an implementation choice of the tools serving STAC. However, STAC specifications offer several levels of granularity to apply access control strategy: catalog, collection, item, asset. On the implementation side, most of the tools present in the STAC ecosystem can be easily tailored to add a security layer. For instance, on stac-fastapi, an authentication + authorization layer based on OAuth scheme via fastapi framework. Same for titiler with access control either on API controllers or on via STAC catalog access. On our side, we implemented several components serving STAC catalogs applying dynamically grants to items (e.g. permission to view or download high resolution assets) according to the authenticated user and the policy applied. The most we can do in this repository is maybe to add some best practices about security implementation but I am not sure about this...
This is definitely an item worth expanding on in the documentation. We are looking at implementing access control right now with our own STAC project. We are looking at implementing security primarily at a Collection level, the impact on STAC being the insertion of metadata fields around security classification and sensitivity in the STAC Collection. I believe LINZ did something similar by applying a linz:security_classification at Collection level.
There's a related extension: https://github.com/AtomicMaps/authentication
Discussed at STAC sprint.
This looks to be an implementation detail. Generally what people have done is to have a method to remove assets from Items before they are returned unless they are authenticated.
STAC strives to make geospatial information more accessible and there's a general movement to migrate from in-house built catalogs towards services with STAC compliant APIs. In this situation the problem of authorizing user's requests arises naturally. Even though the problem of securing asset URLs can be easily solved using the mechanism of presigned URLs, there is still lack of common practices how the Items themselves can be protected. I believe this problem is affecting a big audience who is willing to migrate to STAC.
As a first step to improve the situation I added a small change to TiTiler.PgSTAC project to allow developers implement their own functions to protect items. Here is an example of how it can be used. It was easy enough since TiTiler.PgSTAC has only a single endpoint to be protected but for other projects (such as stac-fastapi) this approach won't work since they have several endpoints that user can use to get access to the items. In the latter case an authorization middleware could be a solution.
Has anyone already had to solve this problem before? I'd like to hear your input. Thanks!