Create a fine-grained permissions to ReqMgr2

[amaltaro]

If I looked at the right file
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/ReqMgr/Auth.py

it seems the only permissions distinctions are for: creating a request (new), approving (assign-approved) and assigning it (assigned).

If someone wants to reject a request, then this person needs to have full privileges (ReqMgr: Admin).

My suggestion would be (for ReqMgr group):

• User: should be able to create, approve and reject workflows. nothing else.
• Operator: should be able to create requests and change their status to anything that is not *-archived
• Admin: full access.

@ticoann does it make sense?

[amaltaro]

And two more comments:

1. We need to keep FacOps: web-service, since this one is used by cmsweb.
2. The same distinctions/privileges should apply to couch docs, though I'm not sure how hard it is (do we need to create a validate-func to each design doc?).

[ticoann]

Hi Alan, Yes I agree what you said.
The plan was, make this configuable for now it is hard coded
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/ReqMgr/Auth.py

Base logic are following.

1. Authentication group and roles are not hosted in reqmgr2 unlike reqmgr1. (It uses the groups and roles from sitedb).
2. permission is tied to group and roles as well as request type. (So we define permission for those combination) i.e. you set set specific group, and/or role to approve StoreResult request but that group won't have approve privilege for other types of request.
   (It doesn't have user level and individual request level control, (i.e. only user who create the request can reject request. - I don't think we need that level of control, but we can add it if it is absolutely necessary.)

[amaltaro]

Thanks Seangchan! Individual request level control is just too much in my opinion as well.

About permissions being tied to groups, did you mean physics group? If so, IMO we could skip it as well, currently there are only a few people creating workflows, I'd go for a single group, easier to manage.

[ticoann]

group and role here is just sitedb group and roles, I am not sure how groups and roles defined there. But it is pretty flexible to define groups and roles, right?

[vlimant]

good !

[ticoann]

@vlimant, Jean-Roch could you give me the list which one needs which permission to have.

Here is some examples

https://cmsweb-testbed.cern.ch/couchdb/_utils/document.html?reqmgr_auxiliary/PERMISSION_BY_REQUEST_TYPE

Permission can be controlled by request type. i.e.
For StoreResult type.
If state transition not specified. DEFAULT_STATE permission will take over.

"StoreResult": {
       "assigned": {
           "group": [
               "reqmgr",
               "facops",
               "dataops"
           ],
           "role": [
               "developer",
               "admin",
               "data-manager",
               "production-operator",
               "web-service"
           ]
       },
       "new": {
           "group": [
               "reqmgr",
               "facops",
               "dataops"
           ],
           "role": [
               "developer",
               "admin",
               "data-manager",
               "production-operator",
               "web-service"
           ]
       },
       "assignment-approved": {
           "group": [
               "reqmgr",
               "facops",
               "dataops"
           ],
           "role": [
               "developer",
               "admin",
               "data-manager",
               "production-operator",
               "web-service"
           ]
       }
   },

[amaltaro]

In face of: #11190, this now becomes higher priority and we need to make sure it's functional. We might want to review how that permission document gets created in reqmgr_auxiliary db, given that I see it only in CMSWEB production but not in testbed.

[amaltaro]

On what concerns permissions based on the request status (or the lack of it), this is what I just came up with:

# Admin roles: 'web-service': ['group:facops'] and 'admin': ['group:reqmgr']
# --> can do anything, any status transition, workflow assignment, priority updates
# P&R: "production-operator": ["group:dataops"]
# --> can do anything, any status transition, workflow assignment, priority updates
# PPD/PdmV: "data-manager": ["group:reqmgr"]
# --> can create requests, set to assignment-approved and reject, update priority

Note that this is actually based on the RequestStatus provided by the end user. So, there is no real distinction of the status transition, but only to which status the request is supposed to go to.

Do people have any comments and/or corrections to make? Tagging a few names that come to my mind, but others are of course welcome to provide their input @haozturk @todor-ivanov @vkuznet

PS.: PdmV being able to reject looks sensible to me in case they injected a workflow that is actually broken. However, they would be able to also reject a workflow that is either completed or closed-out, which is not so desirable.