search

dianagudu / motley_cue

A service for mapping OIDC identities to local identities, with local user management
https://motley-cue.readthedocs.io/
MIT License
8 stars 3 forks source link

Admin authorisation for VO managers using VO roles #20

Open dianagudu opened 3 years ago

dianagudu commented 3 years ago

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:

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 commented 3 years ago

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": "7ca006d6b7e61023cec493a74e57849ae9145815@eduteams.org"

"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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

First case done in 022ba7b85318cadcce914642371a7a091de20ab4 (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).