Project

General

Profile

Development #71275

contrôle d’accès : gérer l’appartenance à des collectivités pour les clients d’API

Added by Paul Marillonnet 3 months ago. Updated about 1 month ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
14 November 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

C’est à mon avis typiquement le genre de chose qu’on voudrait pouvoir classer par collectivité (au sens OU) pour pouvoir restreindre les accès à l’API.
Un exemple parmi d’autres, un déploiement multi-collectivités où on veut ouvrir l’API sur l’une des collectivités et pas les autres.


Files


Related issues

Related to Authentic 2 - Development #71267: a2_rbac : avoir un rôle interne d’administration des clients d’APISolution déployée14 November 2022

Actions
Related to Hobo - Development #71288: gérer les accès en fonction de la collectivité d’appartenance du client d’APINouveau14 November 2022

Actions
Related to Authentic 2 - Development #71463: api/rbac : au lieu d’une vérification booléenne sur une permission globale, filtrer automatiquement les querysets en fonction des permissions équivalentes par OU détenues par l’appelantNouveau18 November 2022

Actions
Related to Authentic 2 - Development #72151: /manage/ : gérer dans les écrans de clients d’API l’appartenance à une collectivitéNouveau07 December 2022

Actions
Related to Hobo - Bug #72355: tests cassés suite à l’introduction des rôles de gestion des clients d’API par OU dans authenticRejeté13 December 2022

Actions
Related to Hobo - Development #72354: Buid hobo en erreur suite à changement dans authenticSolution déployée13 December 2022

Actions
Related to Authentic 2 - Development #72688: /manage/ : l’écran de gestion des clients d’API doit filtrer en fonction de l’OU du/des rôles de gestion détenus par l’usagerSolution proposée21 December 2022

Actions
Related to Authentic 2 - Development #72703: /manage/ : l’écran de gestion des clients d’API doit filtrer les rôles ajoutables au client en fonction de l’OU du client d’APISolution proposée22 December 2022

Actions

Associated revisions

Revision 5a821a88 (diff)
Added by Paul Marillonnet 2 months ago

a2_rbac: add global management role for api clients (#71267)

ou-wise api-client management roles will be added in #71275.

Revision a7ffb583 (diff)
Added by Paul Marillonnet about 2 months ago

models: add ou field to api clients (#71275)

Revision 4240f989 (diff)
Added by Paul Marillonnet about 2 months ago

api_views: handle ou-wise api-client checks (#71275)

History

#1

Updated by Paul Marillonnet 3 months ago

  • Related to Development #71267: a2_rbac : avoir un rôle interne d’administration des clients d’API added
#3

Updated by Paul Marillonnet 3 months ago

  • Assignee set to Paul Marillonnet

Il y aurait aussi une partie hobo à gérer, je vais créer un ticket.

#4

Updated by Paul Marillonnet 3 months ago

  • Related to Development #71288: gérer les accès en fonction de la collectivité d’appartenance du client d’API added
#5

Updated by Paul Marillonnet 3 months ago

Paul Marillonnet a écrit :

C’est à mon avis typiquement le genre de chose qu’on voudrait pouvoir classer par collectivité (au sens OU) pour pouvoir restreindre les accès à l’API.
Un exemple parmi d’autres, un déploiement multi-collectivités où on veut ouvrir l’API sur l’une des collectivités et pas les autres.

Et en fait ça passe déjà nécessairement par des rôles de gestion dans les collectivités. Pas sûr qu’on gagne à ajouter quoi que ce soit ici, je vérifie et rejette le ticket ensuite.

#6

Updated by Paul Marillonnet 3 months ago

Si, c’est sans doute quand même intéressant d’avoir des rôles de gestion des clients d’API cloisonnés à une collectivité. Ce serait purement a2, rien dans hobo ; lorsque la personne qui détient le rôle édite un client d’API, il faut vérifier que les rôles ajoutés ne sont pas en dehors de l’OU d’appartenance du rôle de gestion.

#7

Updated by Paul Marillonnet 3 months ago

Paul Marillonnet a écrit :

Si, c’est sans doute quand même intéressant d’avoir des rôles de gestion des clients d’API cloisonnés à une collectivité. Ce serait purement a2, rien dans hobo ; lorsque la personne qui détient le rôle édite un client d’API, il faut vérifier que les rôles ajoutés ne sont pas en dehors de l’OU d’appartenance du rôle de gestion.

Et avec ça un autre bout intéressant : en finir avec les permissions globales dans l’API a2, et au lieu de ça filtrer automatiquement les querysets en fonction des permissions équivalentes par OU détenues par l’appelant.

#8

Updated by Paul Marillonnet 3 months ago

  • Related to Development #71463: api/rbac : au lieu d’une vérification booléenne sur une permission globale, filtrer automatiquement les querysets en fonction des permissions équivalentes par OU détenues par l’appelant added
#9

Updated by Paul Marillonnet about 2 months ago

Voici ce qu’on pourrait passer pour la partie modèle et adaptation de l’endpoint /check-api-client/, je vais faire un ticket pour la partie /manage/, qu’on discute de ce qu’on peut y faire.

#10

Updated by Paul Marillonnet about 2 months ago

  • Related to Development #72151: /manage/ : gérer dans les écrans de clients d’API l’appartenance à une collectivité added
#11

Updated by Benjamin Dauvergne about 2 months ago

  • Status changed from Solution proposée to Solution validée

Je mettrai directement ou comme non-null et valeur par défaut get_default_ou(), aucune raison d'avoir des API client sans OU (on a déjà le souci sur les utilisateurs ne le reproduisons pas ici).

#12

Updated by Paul Marillonnet about 2 months ago

Benjamin Dauvergne a écrit :

Je mettrai directement ou comme non-null et valeur par défaut get_default_ou(), aucune raison d'avoir des API client sans OU (on a déjà le souci sur les utilisateurs ne le reproduisons pas ici).

Mais justement je pensais que ces utilisateurs qui n’appartiennent à aucune OU ne vont être atteignables par aucun client d’API réduit à une OU, et que c’est justement la raison pour laquelle il faut tolérer que ces clients puissent ne pas avoir d’OU. Je loupe un truc ? Comment on ferait pour atteindre les utilisateurs sans OU sans cette possibilité APIClient.ou := null ?

#13

Updated by Benjamin Dauvergne about 2 months ago

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Je mettrai directement ou comme non-null et valeur par défaut get_default_ou(), aucune raison d'avoir des API client sans OU (on a déjà le souci sur les utilisateurs ne le reproduisons pas ici).

Mais justement je pensais que ces utilisateurs qui n’appartiennent à aucune OU ne vont être atteignables par aucun client d’API réduit à une OU, et que c’est justement la raison pour laquelle il faut tolérer que ces clients puissent ne pas avoir d’OU. Je loupe un truc ? Comment on ferait pour atteindre les utilisateurs sans OU sans cette possibilité APIClient.ou := null ?

Y a pas de lien entre APIClient.ou et les utilisateurs visibles ou alors je n'ai pas bien lu le patch. Si un APIClient veut voir tous les utilisateurs il faut lui filer la permission globale custom_user.search_user. Pour moi APIClient.ou c'est juste pour compartimenté l'administration des APIClient en BO.

#14

Updated by Paul Marillonnet about 2 months ago

Benjamin Dauvergne a écrit :

Y a pas de lien entre APIClient.ou et les utilisateurs visibles ou alors je n'ai pas bien lu le patch. Si un APIClient veut voir tous les utilisateurs il faut lui filer la permission globale custom_user.search_user. Pour moi APIClient.ou c'est juste pour compartimenté l'administration des APIClient en BO.

Ok, cette compartimentation peut être une première étape en effet.
À terme je pense qu’il faudrait tendre vers :

Il y aurait avec ça un autre patche (dans un futur cycle toujours) pour s’assurer dans le /manage/ qu’un gestionnaire des clients d’API d’une collectivité Lambda ne peut pas aller accorder des rôles avec des permissions globales ni des permissions d’une autre collectivité Gamma, seulement les permissions pour la collectivité Lambda (car c’est la collectivité d’appartenance du rôle de gestion de clients d’API qu’il détient).

(Dans le fil de discussion de la release du 8 décembre).

#15

Updated by Paul Marillonnet about 2 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 4240f989ae5f3d7be2773bf8eed3fdb05fe42d17
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Thu Nov 17 10:56:30 2022 +0100

    api_views: handle ou-wise api-client checks (#71275)

commit a7ffb583f830a2649f5703ba0d27435e1d9fe19c
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Thu Nov 17 10:13:53 2022 +0100

    models: add ou field to api clients (#71275)
#16

Updated by Paul Marillonnet about 2 months ago

  • Related to Bug #72355: tests cassés suite à l’introduction des rôles de gestion des clients d’API par OU dans authentic added
#17

Updated by Paul Marillonnet about 2 months ago

  • Related to Development #72354: Buid hobo en erreur suite à changement dans authentic added
#19

Updated by Paul Marillonnet about 1 month ago

  • Related to Development #72688: /manage/ : l’écran de gestion des clients d’API doit filtrer en fonction de l’OU du/des rôles de gestion détenus par l’usager added
#20

Updated by Paul Marillonnet about 1 month ago

  • Related to Development #72703: /manage/ : l’écran de gestion des clients d’API doit filtrer les rôles ajoutables au client en fonction de l’OU du client d’API added
#21

Updated by Frédéric Péters about 1 month ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF