Anonymize SSO users webId

[mguihal]

Tension :

Le problème se pose sur Archipelago. Lorsqu'un utilisateur s'inscrit via SSO (par exemple via LesCommuns), seules les données suivantes sont transmises (email, prénom, nom). Lors du processus d'inscription, une ressource lui est créée (entité Person), avec un webId dont l'identifiant est généré à partir de l'email de l'utilisateur (potentiellement suffixée).

Plusieurs problèmes se posent avec cette approche :

• Un premier souci de sécurité : On peut ainsi inférer l'email de l'utilisateur à partir de son identifiant (en rajoutant des domaines génériques de type @gmail.com, @outlook.com, etc.)
• Un second souci de sécurité : Il se peut que l'utilisateur s'inscrive avec un email contenant des données personnelles, par exemple son nom de famille en entier, et qu'il veuille utiliser l'outil en masquant son identité complète.
• Un souci "esthétique" : L'email peut ne pas correspondre du tout avec la personne, par exemple des personnes peuvent s'inscrire avec des emails de type "[email protected]", auquel cas les identifiants générés seront contact, contact1, contact2, etc. perdant ainsi toute légitimité sémantique.

Solutions possibles :

• Je propose une première solution dans cette PR permettant de générer un uuid pour les SSO ne fournissant pas de username (comme LesCommuns par exemple). Cela permet de corriger le problème pour le cas d'utilisation que j'ai remarqué, mais peut-être pas pour tous.
• Une proposition plus ambitieuse, mais que je n'ai pas implémentée ici par manque de connaissance sur l'ensemble du projet Semapps et ses ramifications, serait de supprimer ces lignes : https://github.com/assemblee-virtuelle/semapps/blob/master/src/middleware/packages/auth/services/account.js#L29-L42 pour empêcher totalement la création d'un user (SSO ou non) si aucun username n'est donné (et de ne plus se fier sur son email)
• Si la modification proposée ici dans Semapps impliquerait trop de conséquences dans divers projets, il est aussi possible de faire la modification dans Archipelago seulement (en rajoutant un attribut username avec un uuid généré ici : https://github.com/assemblee-virtuelle/archipelago/blob/master/middleware/services/auth.service.js#L14-L18)

Qu'en pensez-vous ?

[mguihal]

Par ailleurs, même si c'est optionnel ici, cette modification n'étant pas rétroactive sur les utilisateurs déjà créés, je cherche activement des ressources ou de la documentation pour implémenter des scripts de migration de données dans Jena (à la manière de migrations SQL par exemple). Est-ce que l'un de vous aurait déjà expérimenté ça pour savoir quelles sont les bonnes pratiques ?

[simonLouvet]

Par ailleurs, même si c'est optionnel ici, cette modification n'étant pas rétroactive sur les utilisateurs déjà créés, je cherche activement des ressources ou de la documentation pour implémenter des scripts de migration de données dans Jena (à la manière de migrations SQL par exemple). Est-ce que l'un de vous aurait déjà expérimenté ça pour savoir quelles sont les bonnes pratiques ?

salut @mguihal . pour les migration nous utilisons des services moleculer comme https://semapps.org/docs/middleware/migration
ils sont déclenché au demarrage ou "à la main" dans les containers.

Il existe peut être des utils de migration semantique qui travaille en sparql mais je n'en connais pas. Pour des 'petite' migration je passe également par le bus sémantique en travaillant en ldp et ca permet d'aller vite sans ecrire de code.

[simonLouvet]

@mguihal est ce que cet issue est toujours necessaire avec les modificaiton que tu as fait sur nantes.transiscope.org? https://gitlab.com/transiscope-nantes/deploy-archipelago-nantes/-/merge_requests/9/diffs

[srosset81]

Pour info, si aucun slug n'est passé lors de la création d'une ressource, un UUID est automatiquement généré. Donc appeler la fonction uuid() pour l'username fonctionne, mais on pourrait faire plus simple en ne passant juste pas de slug. Les services auth et webid auraient besoin d'être refactoré pour donner plus de flexibilité.

Je suis d'accord que prendre la première partie de l'email n'est pas terrible. C'était une solution intermédiaire en attendant que le login Les Communs renvoie un username, mais j'ai l'impression que ça ne va jamais se faire.

Au final, la solution proposée dans cette PR me semble bien comme solution intermédiaire. Je vous laisse merger si c'est bon pour vous.