[EOEPCA/IAM] Integration of Resource Discovery BB / EOAPI (Q3)

[w-jfe]

• Administration of Resource Discovery configuration
• Administration of Resource Discovery metadata

[w-jfe]

Related to issues

• Protect eoAPI's STAC API Transaction Extension endpoints resource-discovery#101

• Integration of Authentication & Authorization Mechanism for CRUD API with IAM (API Gateway) resource-discovery#12

[j08lue]

@w-jfe, can you please confirm the rough implementation plan I wrote up here?

• Protect eoAPI's STAC API Transaction Extension endpoints resource-discovery#101 (comment)

As noted, our team was unclear on the steps we would need to take on the BB side, once you implemented the control mechanism. We can get to that when you pick up this work.

[w-scho]

@j08lue I am currently working on the Workspace API route, trying out two different approaches (APISIX + Keycloak vs APISIX + OPA). Based on that, I'd create an APISIX route for eoAPI (probably at https://eoapi.**apx**.develop.eoepca.org/stac/collections). I hope that this will happen during the first half of next week.
I have some assumptions/ questions regarding this:

• Does the term "open" mean that GET requests should be possible anonymously, i.e. even without authentication?
• You only wrote that we have to distinguish between GET and POST. However, I assume that PUT, DELETE etc. should be handled in the same way as POST and also require authN/authZ. Is is sufficient to distinguish cases only by method or should the path also be considered, e.g. by preventing access to everything except the defined endpoints? It may make sense to limit access at least to the /stac or /stac/collections subtree.
• I assume that eoAPI is actually an API in the sense of a machine-to-machine interface as its name suggests. Is it thus correct to assume that the caller will authenticate prior to calling the API and include a JWT in the call?

[j08lue]

Thanks for the confirmation.

Our use case is this:

1. A REST API (STAC API) serves public data, accessible anonymously via GET requests
2. Some of the same endpoints as for data retrieval also allow for POST, DELETE, PUT requests to change the data (CRUD)

See these Transaction Extension docs: https://eoapi.develop.eoepca.org/stac/api.html#/Transaction%20Extension

Does the term "open" mean that GET requests should be possible anonymously, i.e. even without authentication?

Yes, anonymously.

Is is sufficient to distinguish cases only by method or should the path also be considered, e.g. by preventing access to everything except the defined endpoints? It may make sense to limit access at least to the /stac or /stac/collections subtree.

Only by method, please. All endpoints are open anonymously for GET requests but a few can also do POST, DELETE, POST, which require authentication + authorization.

I assume that eoAPI is actually an API in the sense of a machine-to-machine interface as its name suggests. Is it thus correct to assume that the caller will authenticate prior to calling the API and include a JWT in the call?

Not only machine-to-machine.

Expected clients:

1. A web application (STAC Manager)
2. Users in scripts or command-line tools such as Jupyter Notebooks or cURL
3. A data registration service in the Resource Registration building block

These clients obviously have different auth flows.

1. A JWT would be fine for the web application.
2. Scripting users could also be asked to pass a JWT, maybe retrieved via a device auth flow or so?
3. Not sure on this one.

[w-scho]

A first APISIX route for the EOAPI has been provided. It contains subroutes to the four services that make up the EOAPI.
For the STAC API, it also distinguished between GET requests (unprotected) and other HTTP requests (protected).
The STAC API subroute has to be refined further, because not all non-GET requests should be protected. This refinement has been moved to Q4 and will be handled in a separate ticket.

[j08lue]

Follow-up ticket, for reference:

• Expand method-based ingress control on STAC API to more routes and methods resource-discovery#106