Discussion : impersonnifier un utilisateur lamba quand on est SUPERUSER

[François Van Der Biest]

Bonjour tous,

On me demande d'estimer financièrement la fonctionnalité qui permettrait à un admin console, ayant donc le rôle SUPERUSER, de "passer pour un autre utilisateur de la plateforme".

Ceci afin de valider son accès (ou son non-accès) à des données.

Au-delà de l'aspect légal (pas certain que ce soit très "RGPD-friendly"), et technique (comment on fait ?) et UX (est-ce qu'on veut que l'admin puisse se connecter en tant que X depuis l'écran d'accueil, ou doit-il passer par la console en tant que SUPERUSER ?), est-ce que cette fonctionnalité vous semble pertinente / intéressante / souhaitable pour geOrchestra ?

Merci de vos retours !

F.

PS: j'aurais pu lancer une GIP mais le financement n'étant pas encore assuré ...

[Jean Pommier]

Le 16/09/2024 à 16:40, Jean Pommier a écrit :

Hello

En effet, ça ne me semble pas dans l'esprit RGPD.

En revanche, ça me fait penser à une fonctionnalité que j'aime bien dans kubernetes, `auth can-i qqchose`, par exemple, pour répondre à la question est-ce que j'ai le droit de lister les pods d'un namespace, `kubectl auth can-i get pods`.

Ca me semblerait un option assez sympa : pouvoir tester par exemple si on peut voir une métadonnée ou pas. Y accéder via un service WFS, OGC-API etc. Mais sans réellement réaliser l'opération (donc on n'impersonnifie pas).

Par contre, pour l'implémentation, ça me semble complexe car je pense qu'il faudrait que chaque soft (GN, GS, etc) implémente la fonctionnalité.

Bonne journée

Jean

Jean Pommier -- pi-Geosolutions

Ingénieur, consultant indépendant

Tél. : (+33) 6 09 23 21 36
E-mail : j...@pi-geosolutions.fr
Web : www.pi-geosolutions.fr
linkedin : jean-pommier

--
--
projet: http://www.georchestra.org/

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra-dev".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra-d...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/georchestra-dev/CA%2BGZgzRC2p2QOb%2BYZ%2BYOP%3DRPznH5DeoM8b6L%2BNPLL3pcxkOBDQ%40mail.gmail.com.

[Jean Pommier]

Hello

En effet, ça ne me semble pas dans l'esprit RGPD.

En revanche, ça me fait penser à une fonctionnalité que j'aime bien dans kubernetes, `auth can-i qqchose`, par exemple, pour répondre à la question est-ce que j'ai le droit de lister les pods d'un namespace, `kubectl auth can-i get pods`.

Ca me semblerait un option assez sympa : pouvoir tester par exemple si on peut voir une métadonnée ou pas. Y accéder via un service WFS, OGC-API etc. Mais sans réellement réaliser l'opération (donc on n'impersonnifie pas).

Par contre, pour l'implémentation, ça me semble complexe car je pense qu'il faudrait que chaque soft (GN, GS, etc) implémente la fonctionnalité.

Bonne journée

Jean

---

Jean Pommier -- pi-Geosolutions

Ingénieur, consultant indépendant

Tél. : (+33) 6 09 23 21 36
E-mail : j...@pi-geosolutions.fr
Web : www.pi-geosolutions.fr
linkedin : jean-pommier

---

Le 16/09/2024 à 16:20, François Van Der Biest a écrit :

[Guillaume RYCKELYNCK (DataGrandEst)]

Bonjour,

Ce genre de fonctionnalité me gêne un peu. J'ai l'impression que l'on est limite dans l'usurpation d'identité. En tout cas, pas très RGPD et honnête (voire moral)...

Je m'interroge sur l'utilité sachant que le SUPERUSER peut s'attribuer tous les droits donc faire toute modification à la place d'un utilisateur... où est le blocage dans la situation actuelle ? 

Est-ce qu'il ne manque pas des éléments de contexte ou un use case ?
A minima si on s'aventure dans cette direction, il faut prévoir alors de façon automatique une inscription dans les logs + un envoi d'information à l'utilisateur concerné, non ?

Guillaume

[Landry Breuil]

Helo,

Hors les aspects 'moraux', je pense que ce genre de choses est surtout
pour débugguer un problème concret.. ie 'dans cadastrapp j'ai pas telle
info', ou 'je peux pas accéder a telle carte dans mapstore', ou 'je
trouve pas cette MD dans le catalogue' (elle n'est pas publique).

si on a accès a la plateforme et aux logs, on peut 'facilement' débug ce
genre de cas (si on sait quoi chercher et ou) mais c'est généralement
fastidieux. Et sinon en général le premier réflexe de l'utilisateur
lambda sera d'envoyer ses l/p pour qu'on se connecte avec son compte
(sans commentaire...)

nextcloud a une telle fonctionnalité
(https://github.com/nextcloud/impersonate) mais la dernière fois que
j'ai testé, ça ne fonctionnait pas bien avec cas/ldap.

le proto de dashboard d'admin/consistency que je suis en train de faire
(https://github.com/landryb/dashboard/) pourrait proposer le genre de
choses que mentionne jean en tapant sur les diverses API des briques, ie:
- pour chaque ressource (carte/couche/MD), si elle n'est pas publique,
rappeler 'qui y a accès' et 'avec quel niveau d'accès',
- et de manière orthogonale, pour un utilisateur donné, lister ce a quoi
il a accès (qui ne soit pas public).

Landry

On 16/09/2024 17:36, 'Guillaume RYCKELYNCK (DataGrandEst)' via

> *Jean Pommier -- pi-Geosolutions*
>
> Ingénieur, consultant indépendant
>
> Tél. : (+33) 6 09 23 21 36 <tel:+33%206%2009%2023%2021%2036>
> E-mail : j...@pi-geosolutions.fr
> Web : www.pi-geosolutions.fr <http://www.pi-geosolutions.fr>
> linkedin : jean-pommier <https://www.linkedin.com/in/jean-pommier/>

>
> ---
>
>> Le 16/09/2024 à 16:20, François Van Der Biest a écrit :
>>> Bonjour tous,
>>>
>>> On me demande d'estimer financièrement la fonctionnalité qui
>>> permettrait à un admin console, ayant donc le rôle SUPERUSER, de
>>> "passer pour un autre utilisateur de la plateforme".
>>> Ceci afin de valider son accès (ou son non-accès) à des données.
>>>
>>> Au-delà de l'aspect légal (pas certain que ce soit très "RGPD-
>>> friendly"), et technique (comment on fait ?) et UX (est-ce qu'on
>>> veut que l'admin puisse se connecter en tant que X depuis l'écran
>>> d'accueil, ou doit-il passer par la console en tant que
>>> SUPERUSER ?), est-ce que cette fonctionnalité vous semble
>>> pertinente / intéressante / souhaitable pour geOrchestra ?
>>>
>>> Merci de vos retours !
>>> F.
>>>
>>> PS: j'aurais pu lancer une GIP mais le financement n'étant pas
>>> encore assuré ...
>>> --
>>> --

>>> projet: http://www.georchestra.org/ <http://www.georchestra.org/>

>>>
>>> ---
>>> Vous recevez ce message, car vous êtes abonné au groupe
>>> Google Groupes "georchestra-dev".
>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails
>>> le concernant, envoyez un e-mail à l'adresse georchestra-
>>> d...@googlegroups.com.
>>> Cette discussion peut être lue sur le Web à l'adresse https://
>>> groups.google.com/d/msgid/georchestra-dev/

>>> CA%2BGZgzRC2p2QOb%2BYZ%2BYOP%3DRPznH5DeoM8b6L%2BNPLL3pcxkOBDQ%40mail.gmail.com <https://groups.google.com/d/msgid/georchestra-dev/CA%2BGZgzRC2p2QOb%2BYZ%2BYOP%3DRPznH5DeoM8b6L%2BNPLL3pcxkOBDQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> --
> projet: http://www.georchestra.org/ <http://www.georchestra.org/>

>
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "georchestra-dev".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse georchestra-

> dev+uns...@googlegroups.com <mailto:georchestra-
> dev+uns...@googlegroups.com>.

> Cette discussion peut être lue sur le Web à l'adresse https://

> groups.google.com/d/msgid/georchestra-dev/5a414d6c-7172-4ff0-b503-
> d383c7a39912n%40googlegroups.com <https://groups.google.com/d/msgid/
> georchestra-dev/5a414d6c-7172-4ff0-b503-
> d383c7a39912n%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Landry Breuil
Responsable Informatique
04 44 05 12 42

----------------------------------------------------------------------------
Centre Régional Auvergne-Rhône-Alpes de l'Information Géographique
Hôtel de région
59 Boulevard Léon Jouhaux - CS 90706
63050 Clermont-Ferrand Cedex 2

https://www.craig.fr <https://www.craig.fr> - @GipCraig

----------------------------------------------------------------------------
> Support utilisateurs (tous les jours ouvrés de 8H30 à 12H30) : 09 72
62 25 31

[Fabrice Phung]

Le 16/09/2024 à 17:36, 'Guillaume RYCKELYNCK (DataGrandEst)' via
georchestra-dev a écrit :

> Bonjour,
> Ce genre de fonctionnalité me gêne un peu. J'ai l'impression que l'on
> est limite dans l'usurpation d'identité. En tout cas, pas très RGPD et
> honnête (voire moral)...
> Je m'interroge sur l'utilité sachant que le SUPERUSER peut s'attribuer
> tous les droits donc faire toute modification à la place d'un
> utilisateur... où est le blocage dans la situation actuelle ?
> Est-ce qu'il ne manque pas des éléments de contexte ou un use case ?
> A minima si on s'aventure dans cette direction, il faut prévoir alors
> de façon automatique une inscription dans les logs + un envoi
> d'information à l'utilisateur concerné, non ?

Bonjour

+1 avec guillaume

Je vois tout à fait  l'utilité de cette fonctionnalité. Elle est
comparable à la prise de contrôle à distance en téléassistance. Pour
qu'elle soit réalisée avec confiance, on avertit l'utilisateur et on
demande son consentement. Idéalement il sait ce qui est fait en son nom,
mais je pense que c'est très difficile à réaliser automatiquement.
Manuellement c'est faisable : compte-rendu, vidéo d'écran...

> --
> --
> projet: http://www.georchestra.org/
>
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "georchestra-dev".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> georchestra-d...@googlegroups.com.
> Cette discussion peut être lue sur le Web à l'adresse

> https://groups.google.com/d/msgid/georchestra-dev/5a414d6c-7172-4ff0-b503-d383c7a39912n%40googlegroups.com
> <https://groups.google.com/d/msgid/georchestra-dev/5a414d6c-7172-4ff0-b503-d383c7a39912n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Alain Benard]

Bonjour à tous,

je rejoins fph sur la nécessité d'informer la personne 'clonée' (log, mail ...) et sur une meilleure définition du use case. Par mon expérience d'admin je vois un intérêt à ce type de fonctionnalité dans un contexte où un usager vous informe qu'il n'accède pas correctement à une ressource alors que vous pensez avoir donner les bons droits - l'admin ayant généralement accès à tout ne peut se mettre dans le contexte pour tester sauf à se déplacer chez l'usager (pas toujours possible).  Je pense qu'il est important de vérifier le besoin car dans le cas que j'exprime il ne s'agit pas de se faire passer 'pour' mais de se mettre dans un contexte 'identique à'. Il faudrait distinguer le cas où une simple liste des mêmes rôles  (ou groupes) suffit , du cas où il faudrait avoir aussi la même information de login. Si on admet être dans un cas d'assistance on pourrait envisager de faire générer un lien de validation par l'usager cloné qu'il fournirait lui-même à l'admin notamment dans le cas où on veut aussi utiliser son login; pour l'autre cas (mêmes rôles) ça ne me semble pas utile car l'admin peut très bien créer un nouveau compte avec les mêmes groupes et c'est juste pour faciliter ce contexte que la fonctionnalité serait bienvenue.

Bonne journée.