Produits Entr'ouvert » Authentic 2

C'est quelque chose qui aurait du être fait pour GLC mais il a été impossible de leur faire exprimer le besoin ou non-besoin de la chose (à l'origine on devait même avoir un identifiant unique partagé par tous les partenaires, c'est nous qui avons fait le forcing pour que l'identifiant soit dirigé).

Au niveau OIDC ce n'est pas compliqué à faire, juste implémenter le hook a2_hook_api_modify_queryset et filtrer en fonction des autorisations OIDC.

Je ne capte pas le rapport avec oidc, sans doute pas clair, je parlais de la gestion d'accès qu'on peut avoir dans /manage/services/<id>/, "Rôles autorisés à se connecter à ce service".

Ha ok cette fonctionnalité n'existait même pas pour moi, donc oui on peut faire ça aussi, mais je ne vois pas trop comment savoir que l'accès à l'API est actuellement fait pour le compte d'un service, pour l'instant je n'ai ce fonctionnement qu'avec OIDC (développé pour GLC, authentification à l'API via les client_id/client_secret OIDC, compte de service donc).

l'accès à l'API est actuellement fait pour le compte d'un service

Je n'imaginais pas cette partie, j'avais juste en tête la possibilité de faire /api/users/?service=<xxx>, comme aujourd'hui on peut faire /api/users/?ou__slug=<xxx>.

Ok je comprends c'est pour ne pas synchroniser trop alors que moi je voyais ça comme ne pas voir ce qu'on ne doit pas voir, j'ai bien compris maintenant. On peut faire comme tu le proposes.

Les services n'étant pas unique par slug je demande deux paramètres, le slug de l'OU et le slug du service.

Les tests passent pas.

FieldError: Cannot resolve keyword 'authorized_roles' into field. Choices are: admin_perms, admin_scope, admin_scope_ct, admin_scope_ct_id, admin_scope_id, allowed_services, attributes, autho
rizedrole, child_relation, description, external_id, id, members, name, ou, ou_id, parent_relation, permissions, service, service_id, slug, uuid

ack

Je n'imaginais pas cette partie, j'avais juste en tête la possibilité de faire /api/users/?service=<xxx>

Pour confirmation, les users inclus dans la réponse sont ceux qui ont droit de se connecter à ce service (via la gestion des accès par rôles sur l'objet service) et non ceux qui ont déjà fait un SSO avec ce service (en ayant au passage potentiellement donné leur consentement). Et le user qui fait cette requête doit lui-même être autorisé pour ce service.

Mikaël Ates a écrit :

Je n'imaginais pas cette partie, j'avais juste en tête la possibilité de faire /api/users/?service=<xxx>

Pour confirmation, les users inclus dans la réponse sont ceux qui ont droit de se connecter à ce service (via la gestion des accès par rôles sur l'objet service) et non ceux qui ont déjà fait un SSO avec ce service (en ayant au passage potentiellement donné leur consentement). Et le user qui fait cette requête doit lui-même être autorisé pour ce service.

Oui c'est bien uniquement ceux qui ont une autorisation pour ce service, à noter que dans le cas d'un service sans rôle d'autorisation, ça devrait renvoyer tous les utilisateurs mais là tel que c'est écrit ça ne va en renvoyer aucun.

Par contre tous les utilisateurs ayant accès aux APIs peuvent faire ces requêtes, il n'y a pas de contrainte sur l'utilisation de ce filtre (mais c'est soumis aux autorisations plus classique, par exemple si je ne peux voir que les utilisateurs d'une OU1 via le filtre ?service= je ne verrai que les utilisateurs de l'OU1 autorisés pour ce service).