Admin authorisation for VO managers using VO roles

[dianagudu]

It is still unclear at this point what is the use case for the admin API (which can suspend and resume users by sub+iss). Depending on this, implementing the admin authorisation might be easier or more difficult.

The latest understanding we reached in our discussions was that this API will be used by (site-)external admins, who can be:

• security person in the federation
• VO manager

In the first case, how is this specified?
In the second case, if it is done using VO roles, it has to be checked that the user given by iss+sub is member of the same VO (not straight-forward, but doable by checking the local user mapped to the sub+iss and its local groups; we need to be able to retrieve from feudal the local group mapped to a given VO).

[marcvs]

The latest understanding we reached in our discussions was that this API will be used by (site-)external admins, who can be:

* security person in the federation

* VO manager

In the first case, how is this specified?
They will contact us. "They" being some security person for the infrastructure, which I think at the moment is Sander and me. This is merely a feature that will be needed, in case this software is being used in large scale deployments. That security contact can only block and unblock users, right? So it's rather harmless to put me:

"iss": "https://aai.egi.eu/oidc/",
"sub": "d7a53cbe3e966c53ac64fde7355956560282158ecac8f3d2c770b474862f4756@egi.eu"

"iss": "https://aai.egi.eu/oidc/",
"sub": "[email protected]"

"iss": "https://login.helmholtz.de/oauth2",
"sub": "6c611e2a-2c1c-487f-9948-c058a36c8f0e"

"iss": "https://oidc.scc.kit.edu/auth/realms/kit",
"sub": "4cbcd471-1f51-4e54-97b8-2dd5177e25ec",

In the second case, if it is done using VO roles, it has to be checked that the user given by iss+sub is member of the same VO (not straight-forward, but doable by checking the local user mapped to the sub+iss and its local groups; we need to be able to retrieve from feudal the local group mapped to a given VO).

Excellent point. Given my recent encouners with VO admins, this is probably a lot less import to have feature than initally anticipated.

[dianagudu]

All right, adding authorisation based on iss+sub for security people should be easy enough to do, now that this feature is supported for normal users. I assume the security contact can only suspend users with the same issuer?

I suppose I'll put the second point on the back burner for now, it seems to be a high implementation effort for low gain.

[marcvs]

All right, adding authorisation based on iss+sub for security people should be easy enough to do, now that this feature is supported for normal users. I assume the security contact can only suspend users with the same issuer?
If unsure: make it configurable :)
I do see options for both, allowing all issuers and not doing it.

[dianagudu]

First case done in 022ba7b (v0.1.0): admin authorisation by sub+iss is possible, with configurable option to suspend users from any/own OP.

Second case remains:

In the second case, if it is done using VO roles, it has to be checked that the user given by iss+sub is member of the same VO (not straight-forward, but doable by checking the local user mapped to the sub+iss and its local groups; we need to be able to retrieve from feudal the local group mapped to a given VO).