Jobs migration: define authorization model

[nitrosx]

Summary

Define who can do which action on jobs endpoint and have a flexible configuration.

Output should be a permission matrix and environmental variables name to configure who can view and edit jobs

[nitrosx]

[nitrosx]

Updated documentation:
https://scicatproject.github.io/documentation/Development/v4.x/backend/authorization/authorization_jobs.html

[nitrosx]

Implemented in PR issue-712 as I was working on the dataset authorization.

[nitrosx]

Jobs authorization is now in master as PR issue-712 has been approved and merged.
Once we pull master in release-jobs, we should be good.

[sbliven]

I think we now have a good sense of the instance authorization. The documentation still needs to be updated and @despadam can verify that the logic matches the documentation.

[sbliven]

I started reading about CASL trying to fix some authorization bugs and now I have questions.

1. Why does AuthOp.enum have a different endpoint authorization for each subject (dataset_create, job_create, sample_create, etc)? Shouldn't this just be can('create', DatasetClass), can('create', JobClass), etc)?

2. The JobsCreateAny and similar actions check ownerGroup: { $in: user.currentGroups }. Is this just copy-pasted from dataset? Jobs don't have an ownerGroup so this doesn't make sense.

3. Should instanceAuthorization be implemented as a PolicyGuard instead of within the call? Or at least using casl abilities rather than throwing the HTTPException directly?

PS I now understand why AuthOp.enum was originally called Action.enum. It's the correct CASL term.

[nitrosx]

@sbliven I will try to answer your questions:

1. When I started review the authorization, I realized that we were not able to reach the level of granularity that we were looking for by using the generic actions, like create. Back than I decided to have end-point specific actions. At the moment I am still convinced that it is the right choice, although we should review the CASL definition and see if we can simplify it. I was saving the review after we are done with the current releases.
2. I will check but it might very well be. I'm planning to work on this next, so stay tuned
3. Long story short: you need to do extra work to be able to access the data of the specific item that you are working on in the PolicyGuard, so I decided to implement the InstanceAuthorization within the function where the data is already loaded.

Let me know if you have more questions.

[despadam]

Covered by:

• Jobs migration: tests #626
• remove job configuration in jobInstance to enable casl authorization #1395