Development #71275
contrôle d’accès : gérer l’appartenance à des collectivités pour les clients d’API
0%
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.
Fichiers
Demandes liées
Révisions associées
models: add ou field to api clients (#71275)
api_views: handle ou-wise api-client checks (#71275)
Historique
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #71267: a2_rbac : avoir un rôle interne d’administration des clients d’API ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Assigné à mis à Paul Marillonnet
Il y aurait aussi une partie hobo à gérer, je vais créer un ticket.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #71288: gérer les accès en fonction de la collectivité d’appartenance du client d’API ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à 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 ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Fichier 0002-api_views-handle-ou-wise-api-client-checks-71275.patch 0002-api_views-handle-ou-wise-api-client-checks-71275.patch ajouté
- Fichier 0001-models-add-ou-field-to-api-clients-71275.patch 0001-models-add-ou-field-to-api-clients-71275.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #72151: /manage/ : gérer dans les écrans de clients d’API l’appartenance à une collectivité ajouté
Mis à jour par Benjamin Dauvergne il y a plus d'un an
- Statut changé de Solution proposée à 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).
Mis à jour par Paul Marillonnet il y a plus d'un an
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 ?
Mis à jour par Benjamin Dauvergne il y a plus d'un an
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
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).
Mis à jour par Paul Marillonnet il y a plus d'un an
- Statut changé de Solution validée à 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)
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Bug #72355: tests cassés suite à l’introduction des rôles de gestion des clients d’API par OU dans authentic ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #72354: Buid hobo en erreur suite à changement dans authentic ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à 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 ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à 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 ajouté
Mis à jour par Frédéric Péters il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
a2_rbac: add global management role for api clients (#71267)