Implement ingress control distinguishing between GET and POST to eoapi/stac/collections

[j08lue]

We want to try out how we can use the IAM building block to add authorization to relevant methods in the STAC API Transaction Extension.

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

The first step is to achieve the following behavior on the eoapi/stac/collections endpoint, using the tools available in the IAM building block (KeyCloak, API Gateway, policies):

1. GET requests are allowed anonymously
2. POST requests require some form of authentication and authorization

Acceptance criteria

• A route has been created in the IAM building block that implements the above behavior

[w-scho]

OK @j08lue , let's continue the Slack discussion here.
Can you confirm that the GET route I configured at https://eoapi.apx.develop.eoepca.org/stac/ works basically as expected? If so, I'd add the two missing endpoints (/raster and /vector) and remove the redundant route at /.
I assume that the POST routes for /raster and /vector need to be configured in the same way as for /stac. Is this true?
When accessing https://eoapi.apx.develop.eoepca.org/stac/ I still get a self link with port number 9443: https://eoapi.apx.develop.eoepca.org:9443/stac/
When accessing the "old" URL https://eoapi.develop.eoepca.org/stac/ however, I get a correct self link.

[j08lue]

Can you confirm that the GET route I configured at https://eoapi.apx.develop.eoepca.org/stac/ works basically as expected?

The route returns correctly formatted JSON from the upstream service, so that is ok.

But the garbled self links break clients that want to traverse the STAC object graph, like STAC Browser: https://radiantearth.github.io/stac-browser/#/external/eoapi.apx.develop.eoepca.org/stac/. I ticketed the issue here:

• STAC self links get garbled when eoAPI STAC API is behind an API gateway #103

But I think that is a STAC API specific thing and should not affect /raster and /vector, so please move forward.

I assume that the POST routes for /raster and /vector need to be configured in the same way as for /stac. Is this true?

No, all methods should remain open for /raster and /vector - no changes there. Thanks for checking.

[w-scho]

Hi @j08lue. I just added /vector and /raster to the route configuration as completely unrestricted endpoints.
For completeness, I also added an open route from / to the doc-server-eoapi service as in the old ingress.

[j08lue]

Excellent, thank you! 💯

Let us know when there is any auth we can test for POST.

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

[w-scho]

The route config had a typo in the client name that broke the POST subroute.
I fixed this, and now the route is working for POST if you present a valid JWT (tested with GET vs POST to /stac/search). It currently accepts any user.
I have not configured a group yet. BTW, what would be an appropriate name for a group of users who are allowed to perform POST, PUT and DELETE on the eoAPI? Maybe "eoAPI Admin"?

[j08lue]

what would be an appropriate name for a group of users who are allowed to perform POST, PUT and DELETE on the eoAPI?

These actions on the /stac endpoint are about editing STAC information.

We could either have a general "Platform Admin" group that could grant access to a lot of data and configuration management across building blocks.

Or a "Data Access Admin" specific to this building block.

Or "STAC Editor" just for this one purpose.

Whatever feels most appropriate at this point.

[w-scho]

I think the most natural choice would be to create a "Data Access Admin" group and an associated "STAC Editor" role. This allows adding, removing or restructuring relevant groups without touching the ingress/ route and authZ configuration. I'll try to create an example setup this afternoon.

[w-scho]

I created a group called "Data Access Admin" and added user "eric" to it. I also created a client role named stac_editor on the eoapi client. I associated the group with the role and made the role a prerequisite for accessing the STAC API by other methods than GET. I tested this with users "eric" and "bob", and as expected, Eric was able to send a POST request to the STAC API while Bob wasn't.
Currently the configuration on Keycloak side is not limited to the STAC API, but applies to the "default resource", which spans the whole eoAPI. The route configuration, however, only requires authN/authZ for /stac/*, so the restriction effectively only applies to the STAC API. This is not really clean and may have to be adapted as the protection config evolves.

[j08lue]

This sounds great, thanks!

Btw, I realized that "Data Access Admin" is not accurate, since STAC administration is perhaps even more closely related to the Resource Discovery building block. So maybe "Resource Admin" would be better. But what you set up is fine for now.

The next question is: What authN/authZ mechanisms are currently available to enable a user to POST to STAC API?

There are two services that already want to try out connecting to the protected service - or at least plan how to do that:

1. an interactive STAC editing web application we are developing where users should be able to log in and then POST their updates Define a preliminary auth flow for the STAC CRUD UI #105
2. workflows in the Resource Registration building block - probably a different auth flow, since it is non-interactive / machine-to-machine, I assume. Perhaps @mario-winkler can link to a ticket describing their target service architecture?

Let us discuss this further on the relevant tickets.

Are you planning to make any more changes to the current setup or will you document it anywhere, @w-scho? Otherwise, I'd consider this done!

[j08lue]

Well, and another next step would be to expand this auth to more routes and methods on the same /stac/collections endpoint:

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

[w-scho]

The current status is that everything under the /stac directory except GET requests requires a JWT with role stac_editor. E.g., this also includes POST /stac/search, though this is probably not a modifying operation. So at present the scope of the protection is probably too wide and needs to be narrowed in a next step.

I renamed the group "Data Access Admin" to "Resource Admin."

Regarding authentication:
For the interactive STAC editing web application I assume that users will login via Keycloak using the Standard Flow and that you will be able to pass the resulting access token (JWT) to the STAC API from the web frontend. Authentication can be handled by APISIX or by your application itself, at your option. Passing the JWT will probably have to be implemented into your application, depending on how it actually uses the API.
For pure machine-to-machine access we can configure a dedicated Keycloak client for the calling party that they can authenticate as (like the Workspace BB does) to obtain a JWT. I think @achtsnits knows better how to handle this that I do.

[j08lue]

everything under the /stac directory except GET requests requires a JWT

Right, yes, that needs to be more fine-grained to match the routes mentioned in the above ticket.

For the interactive STAC editing web application I assume that users will login via Keycloak using the Standard Flow and that you will be able to pass the resulting access token (JWT) to the STAC API from the web frontend.

Yes, that OIDC / Authorization Code Flow sounds straightforward (for example here and here). Can we get permissions to register our client in KeyCloak, when our app is ready?

Is the KeyCloak URL still https://iam-auth.apx.develop.eoepca.org?

[w-scho]

I think that I need some more details about the routes to protect or more exactly about the routes that are not listed in the ticket.

1. What should happen to the URIs beneath /stac that are not listed in the ticket (like /stac/search)? Which methods should be allowed there? Should POST etc. be allowed only with authentication or unauthenticated (just like GET)?
2. For the paths listed in the ticket: what shall happen to the methods not listed there? Should they be rejected, or is it OK to let them through? E.g., would it be OK to let a DELETE request on https://eoapi.develop.eoepca.org/stac/collections pass, because it would be rejected by the API anyway, or is it important to block it on the ingress level?

The overall complexity has an impact on the solution to be used. So far, we implemented a simple solution only based on APISIX capabilities, but we will probably have to change to an OPA- or Keycloak-based solution like the ones I suggested for the Workspace API. My preliminary assumption is that the OPA-/policy-based approach could work quite well.

The Keycloak URL you mentioned is correct. So far Keycloak still redirects to https://iam-auth.develop.eoepca.org (without .apx) in some cases, but I am going to change this soon.

I can create/ register a client for you or I can grant permission for this to an existing user or client (like already done for Workspace BB). In order to grant permissions to a GitHub user, this user must have logged in to the IAM at least once so that Keycloak can map their identity.