Projet

Général

Profil

Development #71275

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

Ajouté par Paul Marillonnet il y a plus d'un an. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
14 novembre 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Lié à Authentic 2 - Development #71267: a2_rbac : avoir un rôle interne d’administration des clients d’APIFermé14 novembre 2022

Actions
Lié à Hobo - Development #71288: gérer les accès en fonction de la collectivité d’appartenance du client d’APIEn cours14 novembre 2022

Actions
Lié à 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 novembre 2022

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

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

Actions
Lié à Hobo - Development #72354: Buid hobo en erreur suite à changement dans authenticFermé13 décembre 2022

Actions
Lié à 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’usagerFermé21 décembre 2022

Actions
Lié à 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’APIFermé22 décembre 2022

Actions

Révisions associées

Révision 5a821a88 (diff)
Ajouté par Paul Marillonnet il y a plus d'un an

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

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

Révision a7ffb583 (diff)
Ajouté par Paul Marillonnet il y a plus d'un an

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

Révision 4240f989 (diff)
Ajouté par Paul Marillonnet il y a plus d'un an

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

Historique

#1

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é
#3

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.

#4

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é
#5

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.

#6

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.

#7

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.

#8

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é
#9

Mis à jour par Paul Marillonnet il y a plus d'un an

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

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é
#11

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).

#12

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 ?

#13

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.

#14

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).

#15

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)
#16

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é
#17

Mis à jour par Paul Marillonnet il y a plus d'un an

  • Lié à Development #72354: Buid hobo en erreur suite à changement dans authentic ajouté
#19

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é
#20

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é
#21

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
#22

Mis à jour par Transition automatique il y a environ un an

Automatic expiration

Formats disponibles : Atom PDF