Allow more fine-grained access permissions

[m-mohr]

[W]e just started leveling up from the simple binary anonymous-vs-authenticated model, by introducing the "early adopter" check for openEO platform.
In the longer term more complex permission use cases might pop, e.g.

• user can only do "light" synchronous processing, but no batch jobs
• user can not store UDP or user can not store private UDP
• user can only have N concurrent batch jobs at the same time
• user has no access to this particular collection, bbox or process
• ....

Originally posted by @soxofaan in https://github.com/openEOPlatform/architecture-docs/issues/105#issuecomment-938642969

Yes, we may need to revamp the "endpoints" solution from GET / and also provide this in the GET /me endpoint on a per-user basis.

Originally posted by @m-mohr in https://github.com/openEOPlatform/architecture-docs/issues/105#issuecomment-938647864

[soxofaan]

I think we already have a working basis for fine-grained permissions:

openeo-api/errors.json

Lines 352 to 354 in f303d65

	"PermissionsInsufficient": {
	"description": "Forbidden. The client did provided correct authentication details, but the privileges/permissions of the provided credentials do not allow to request the resource.",
	"message": "Forbidden. The permissions of the authenticated account do not allow to request the requested resource.",

The description might need some fine-tuning to focus less on authentication and more on authorization,
but back-ends can already use this to implement fine-grained permissions (e.g. like the "early adopter check" in current version of aggregator).

However, I guess you're more thinking about knowing about potential permission issues before sending a request that may fail, e.g. to dynamically adapt an interactive user interface like the web editor or jupyter widgets (hiding features/panels, graying out buttons, ...).
Or do you also have concerns about non-interactive usage (running a python script), and more "turn-based" usage (running a notebook cell by cell)?

[m-mohr]

However, I guess you're more thinking about knowing about potential permission issues before sending a request that may fail, e.g. to dynamically adapt an interactive user interface like the web editor or jupyter widgets (hiding features/panels, graying out buttons, ...).

Yes, indeed. The user experience would get much worse as right now the UIs adapt a lot based on what is exposed in GET / and users should not really see what they can't use (e.g. right now a Platform user would see completely unusable file and web service management tabs).

Or do you also have concerns about non-interactive usage (running a python script), and more "turn-based" usage (running a notebook cell by cell)?

R and Python don't use the endpoint list, right? So there it's try and error. What I believe would be nice to have: Allow users to request an overview of what they can and can't do. That may help to set expectations and avoid some frustration.