Discovery endpoints must not request authentication

[christophfriedrich]

Currently, when I open https://openeo.mundialis.de/api/v0.3/ I am prompted:

One should be able to discover a backend without the need to sign up. I.e. the endpoints

• /
• /collections
• /collections/{collection_id}
• /processes
• /output_formats
• /service_types
• /udf_runtimes (new in v0.4)

should be reachable without authentication.

For example, this is essential for the Hub -- password-protected backends can't be crawled.

[anikaweinmann]

Okay I will do it in the next days. In the moment you can use as user: user and pw: test.

[anikaweinmann]

The changes are now deployed for v0.3

[christophfriedrich]

This issue re-emerged in v0.4 where I'm prompted for authentication for e.g. the /collections endpoint

[m-mohr]

/collections is working now, but /processes is still asking for authentication.

Another thing I noticed is that /collections is relatively slow. Maybe caching would help? ;-)

[neteler]

@m-mohr ... is that a reason that this backend still stuggles with https://open-eo.github.io/openeo-web-editor/demo/ ?

[m-mohr]

@neteler Partly. All open issues (this, #24 and #25) need to be resolved for the Web Editor and the new mobile app to work on this back-end.

This issue is blocking the openEO Hub from indexing the back-end fully and disallows any client to request the processes.

[m-mohr]

@neteler We thought about working with the GRASS GIS back-end during the summer school, but we would need to get the three open issues fixed. Any chance to get the issues sorted? I don't think it would take ages to fix them...

[anikaweinmann]

@m-mohr is it okay when the endpoints

• /processes/id
• /validation
• /preview
• /process_graphs
• /process_graphs/id
• /jobs
• /jobs/id
• /jobs/id
• /results
  have a basic authentication

[m-mohr]

@AnikaBettge No, all endpoints except the ones for credentials and discovery should just use Bearer authorization. The endoint to send your Basic details to is /credentials/oidc. Please check the documentation, which endpoint exactly allows which type of authorization.

Example with remarks:

Please note that /preview is outdated and now called /results. Also note that /processes/id doesn't exist anymore. It's fine to support them in addition though, just wanted to let you know.

[m-mohr]

So the current status seems to be that authentication was removed from the public endpoints, which is good. Unfortunately, the protected endpoints still request Basic Authentication (instead of a Bearer Token), but the back-end doesn't support /credentials/basic. That means we can't execute anything with the clients on the back-end, unfortunately.

[hwbllmnn]

Can you give me a few more details on how the authentication should work? Now that I added a (non-functional) credentails endpoint I get the option to use the OpenID Connect. What Client ID should I provide there?

[hwbllmnn]

Can I use the /credentials/basic endpoint and provide a token there which will be used with Authorization: Bearer xxx?

[m-mohr]

Hi @hwbllmnn,
sure. It seems you implemented the endpoint for OpenID Connect, which you need software for to handle the OpenID Connect workflow (e.g. KeyCloak). Not sure whether you have such a service running, but your question regarding the client_id seems to imply that you don't have such a service running. In this case, I'd suggest to support the good old HTTP Basic with username and password for now.

Therefore, you'd need to implement the endpoint /credentials/basic instead of /credentials/oidc. /credentials/basic should accept an Authorization header with the encoded username and password (basically just base64 encoded username and password separated by a :, e.g. Authorization: Basic d2lraTpwZWRpYQ==). You'll find more information online how to implement Basic. The endpoint should then return a Bearer token, which the user uses to authentication in the following HTTP requests. This Bearer Token is sent similarly in the Authentication header, e.g. Authorization: Bearer 123456ewfdfiewfi. The token can be any hash basically and you need to store it so that in subsequent calls you can check whether the user is using a valid token or not.

[m-mohr]

Can I use the /credentials/basic endpoint and provide a token there which will be used with Authorization: Bearer xxx?

Yes!

[hwbllmnn]

Ok, thanks. Should I respond to the basic auth using a json like here? https://tools.ietf.org/html/rfc6750#page-10

[m-mohr]

No, that's not required as we don't implement OAuth here. (Thanks for the link anyway, that's interesting.) You can simply respond with a JSON as documented here: https://open-eo.github.io/openeo-api/draft/apireference/#tag/Account-Management/paths/~1credentials~1basic/get
You only need to send the user ID and the token (as access_token).

[hwbllmnn]

Authentication is working now and deployed on demo. A lot of tools are still not working, but at least I can now see the stored jobs and process graphs.

[m-mohr]

Thanks, what tools do you mean?

[hwbllmnn]

Keep in mind I don't know anything about this project, I'm just fixing things ;-)

Anyway, I tried e.g. the add buttons to add jobs/process graphs, which failed with undefined in the URL. I guess there are probably some bugs to work out, also, the validation still fails (I'm currently trying to figure out where the code for the fixed version is).

[m-mohr]

Oh, I see. I think @huhabla fixed the other issues...
I guess the OpenEO-Identifier header is not sent when adding resources.

[hwbllmnn]

We also get CORS errors when things are requested against these undefined locations, like this:

Access to XMLHttpRequest at 'https://openeo.mundialis.de/api/v0.4/jobs/undefined' from origin 'https://open-eo.github.io' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
utils.js:9 Error: Network Error
    at e.exports (createError.js:16)
    at XMLHttpRequest.h.onerror (xhr.js:81)
exception @ utils.js:9
(anonymous) @ JobPanel.vue:153
Promise.catch (async)
createJob @ JobPanel.vue:152
(anonymous) @ JobPanel.vue:164
save @ ParameterModal.vue:58
ne @ vue.runtime.esm.js:1854
n @ vue.runtime.esm.js:2179
Qi.o._wrapper @ vue.runtime.esm.js:6911
xhr.js:172 GET https://openeo.mundialis.de/api/v0.4/jobs/undefined net::ERR_FAILED

[m-mohr]

I'll check why it's undefined, but the issue is likely to also occur on regular requests. What has to be done is explained in the error message, but there's also a page in the documentation on how to send CORS headers.

[m-mohr]

GET /jobs returns a job_id instead of a id. That's why it's undefined. Same could be true for GET /process_graphs (process_graph_id vs. id

[christophfriedrich]

The endpoint /udf_runtimes still replies with a "401 Unauthorized" error code when trying to access it. Could you change that? NO discovery endpoint should require authentication.

See it live here: https://openeo.mundialis.de/api/v1.0/udf_runtimes

Reply:
Status: 401 UNAUTHORIZED
Body:

{
 "code": "Unauthorized",
 "message": "Authorization failed",
 "links": []
}