entrouvert
/
authentic
16
0
Fork 0
Code Issues Pull Requests 35 Releases Activity

a2_rbac: grant adequate scoped permissions to authn local admins (#78919) #81

Open
pmarillonnet wants to merge 1 commits from wip/78919-authn-local-admin-manager-perm into main
pull from: wip/78919-authn-local-admin-manager-perm
merge into: entrouvert:main
Conversation 2 Commits 1 Files Changed 3 +43 -1
pmarillonnet commented 2023-06-26 10:16:10 +02:00
Owner
Copy Link
No description provided.
pmarillonnet changed title from WIP: a2_rbac: grant adequate scoped permissions to authn local admins (#78919) to a2_rbac: grant adequate scoped permissions to authn local admins (#78919) 2023-06-26 10:32:41 +02:00
pmarillonnet force-pushed wip/78919-authn-local-admin-manager-perm from 6b6cde71b3 to 8c6e8c1f3f 2023-06-26 11:44:38 +02:00 Compare
pmarillonnet force-pushed wip/78919-authn-local-admin-manager-perm from 8c6e8c1f3f to 1a5f5027f4 2023-06-26 11:48:40 +02:00 Compare
pmarillonnet force-pushed wip/78919-authn-local-admin-manager-perm from 1a5f5027f4 to 90aefc7b09 2023-06-26 12:26:47 +02:00 Compare
pmarillonnet force-pushed wip/78919-authn-local-admin-manager-perm from 90aefc7b09 to 151394e5a8 2023-06-26 14:56:14 +02:00 Compare
pmarillonnet commented 2023-06-26 15:09:08 +02:00
Author
Owner
Copy Link

Une première approche, qui paraît pas complètement insensée, est d’accorder aux administrateurs locaux les permissions de visualisation, de modification et de création de moyens d’authentification, sans pour autant les autoriser à supprimer les authentificateurs existants.

C’est un compromis sur une base actuelle un peu floue qui est de cadrer ce que signifie l’appartenance à une OU d’un authentificateur (dans les faits, actuellement, une clé étrangère en base qui n’est pas utilisée).

Une autre piste, que je préfère un peu moins parce qu’elle implique de revenir en arrière sur un terrain qu’on devrait je crois défricher (l’OU d’appartenance des authentificateurs), c’est de retirer complètement les rôles d’administration par OU des moyens d’authentifications introduits dans #66984.

Une première approche, qui paraît pas complètement insensée, est d’accorder aux administrateurs locaux les permissions de visualisation, de modification et de création de moyens d’authentification, sans pour autant les autoriser à supprimer les authentificateurs existants. C’est un compromis sur une base actuelle un peu floue qui est de cadrer ce que signifie l’appartenance à une OU d’un authentificateur (dans les faits, actuellement, une clé étrangère en base qui n’est pas utilisée). Une autre piste, que je préfère un peu moins parce qu’elle implique de revenir en arrière sur un terrain qu’on devrait je crois défricher (l’OU d’appartenance des authentificateurs), c’est de retirer complètement les rôles d’administration par OU des moyens d’authentifications introduits dans #66984.
vdeniaud commented 2023-06-29 12:09:52 +02:00
Owner
Copy Link

Une première approche, qui paraît pas complètement insensée, est d’accorder aux administrateurs locaux les permissions de visualisation, de modification et de création de moyens d’authentification, sans pour autant les autoriser à supprimer les authentificateurs existants.

Mais le rôle s'appelle quand même « Administrateur », pour moi c'est trop de confusion d'avoir deux rôles nommés comme ça qui donnent des droits différents.

C’est un compromis sur une base actuelle un peu floue qui est de cadrer ce que signifie l’appartenance à une OU d’un authentificateur (dans les faits, actuellement, une clé étrangère en base qui n’est pas utilisée).

Non ce n'est pas à ça que sert le champ OU, il est utilisé par le backend OIDC pour créer les utilisateur dans l'OU indiquée, avec une vague idée d'étendre cette possibilité aux autres backends. Ça n'a pas grand chose à voir avec une éventuelle appartenance de l'authentificateur à une OU.

retirer complètement les rôles d’administration par OU des moyens d’authentifications introduits dans #66984.

Pour moi il faut aller dans cette direction, sauf si c'est trop compliqué.

> Une première approche, qui paraît pas complètement insensée, est d’accorder aux administrateurs locaux les permissions de visualisation, de modification et de création de moyens d’authentification, sans pour autant les autoriser à supprimer les authentificateurs existants. Mais le rôle s'appelle quand même « Administrateur », pour moi c'est trop de confusion d'avoir deux rôles nommés comme ça qui donnent des droits différents. > C’est un compromis sur une base actuelle un peu floue qui est de cadrer ce que signifie l’appartenance à une OU d’un authentificateur (dans les faits, actuellement, une clé étrangère en base qui n’est pas utilisée). Non ce n'est pas à ça que sert le champ OU, il est utilisé par le backend OIDC pour créer les utilisateur dans l'OU indiquée, avec une vague idée d'étendre cette possibilité aux autres backends. Ça n'a pas grand chose à voir avec une éventuelle appartenance de l'authentificateur à une OU. > retirer complètement les rôles d’administration par OU des moyens d’authentifications introduits dans #66984. Pour moi il faut aller dans cette direction, sauf si c'est trop compliqué.
bdauvergne requested changes 2023-12-21 11:55:41 +01:00
src/authentic2/a2_rbac/management.py
@ -94,6 +102,7 @@ MANAGED_CT = {
('authenticators', 'baseauthenticator'): {
'name': _('Manager of authenticators'),
'scoped_name': _('Authenticators - {ou}'),
'scoped_grants_global_change_perm': True,
bdauvergne commented 2023-12-21 11:55:37 +01:00
Owner
Copy Link

Ne pas aller dans cette direction comme le dit Valentin, plutôt retirer tous les rôles d'administration des authentificateurs par OU.

Ne pas aller dans cette direction comme le dit Valentin, plutôt retirer tous les rôles d'administration des authentificateurs par OU.
All checks were successful
gitea/authentic/pipeline/head This commit looks good
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b wip/78919-authn-local-admin-manager-perm main
git pull origin wip/78919-authn-local-admin-manager-perm

Step 2:

Merge the changes and update on Gitea.
git checkout main
git merge --no-ff wip/78919-authn-local-admin-manager-perm
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
bdauvergne
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/authentic#81
No description provided.
Delete Branch "wip/78919-authn-local-admin-manager-perm"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?