Silverpeas » Silverpeas Core

• dans le back office ?
• dans les annuaires ?

Aurore Allibe a écrit (#note-5):

Il s'agit de ces écrans ?

Est-ce qu'on a intégré également la possibilité de passer l'utilisateur avec l'option "Données sensibles activées" dans le formulaire de création / modification (ici appelé formulaire-admin-user.png)

Oui c'est bien ces écrans. Pour ta question, je pense qu'il faut rester cohérent avec d'autres statut, comme le statut "bloqué".

Il s'agit de ces écrans ?

Il s'agit du second écran (lecture-admin-user.png)

Est-ce qu'on a intégré également la possibilité de passer l'utilisateur avec l'option "Données sensibles activées" dans le formulaire de création / modification (ici appelé formulaire-admin-user.png)

Non. Seulement dans la fiche de l'utilisateur une fois celui-ci créé. En fait, seuls les domaines LDAP sont concernés pour l'instant par la feature. Ces derniers sont donc créés et mis à jours via la synchronisation avec le service d'annuaire distant et non par la page de création d'un utilisateur.

A noter que, dans les annuaires, les données sensibles des utilisateurs ne sont présentées qu'aux administrateurs de la plate-forme et gestionnaires du domaine.

J'ai créer aussi des PR pour la branche master-jackrabbit :
https://github.com/Silverpeas/Silverpeas-Core/pull/1310
https://github.com/Silverpeas/Silverpeas-Components/pull/846

Et bien sans avoir lu vos points de vues, je serais partisan d'afficher la fonctionnalité pour que les administrateurs se questionnent sur cette possibilité.
Après on peut ajouter une info bulles pour expliquer de quoi il relève

Je suis assez surpris que nos réflexions ne soient pas prises en compte.

Donc, il faut afficher dans toutes les circonstances de paramétrage technique les informations de sensibilité dans l'administration qui sont inutiles mais qui peuvent faire se poser des questions aux administrateurs de toutes les instances Silverpeas. Il en va de même pour la fonctionnalité qui permet de lister tous les utilisateurs ayant des données sensibles (accessible depuis le menu QVVF de la liste des utilisateurs).
Que devrait indiquer l'infobulle concrètement ? (Du coup, je ne passe pas de temps à proposer quelque chose)
En faut-il une pour l'action dans le menu QVVF ?

Aussi, dans ce choix et l'éventualité que des administrateurs posent leurs questions à Silverpeas, il y a un potentiel souci de cohérence quant à la gestion de l'e-mail de l'utilisateur d'un domaine LDAP. Il n'est pas rare que l'e-mail d'un compte utilisateur soit également l'identifiant de ce dernier. De fait, il n'est par nature pas une donnée sensible puisque chaque utilisateur a une idée de comment il est structuré dans leur domaine. A cause de contraintes techniques, cependant, il a été fait le choix en accord avec l'entité à l'origine de la demande (en ne prenant donc pas en compte la situation de toutes les autres) que dès lors qu'une donnée est indiquée comme sensible dans le fichier de propriétés (autre que l'e-mail), alors l'e-mail l'est aussi.

Yohann Chastagnier a écrit (#note-14):

Je suis assez surpris que nos réflexions ne soient pas prises en compte.

Donc, il faut afficher dans toutes les circonstances de paramétrage technique les informations de sensibilité dans l'administration qui sont inutiles mais qui peuvent faire se poser des questions aux administrateurs de toutes les instances Silverpeas. Il en va de même pour la fonctionnalité qui permet de lister tous les utilisateurs ayant des données sensibles (accessible depuis le menu QVVF de la liste des utilisateurs).
Que devrait indiquer l'infobulle concrètement ? (Du coup, je ne passe pas de temps à proposer quelque chose)
En faut-il une pour l'action dans le menu QVVF ?

Aussi, dans ce choix et l'éventualité que des administrateurs posent leurs questions à Silverpeas, il y a un potentiel souci de cohérence quant à la gestion de l'e-mail de l'utilisateur d'un domaine LDAP. Il n'est pas rare que l'e-mail d'un compte utilisateur soit également l'identifiant de ce dernier. De fait, il n'est par nature pas une donnée sensible puisque chaque utilisateur a une idée de comment il est structuré dans leur domaine. A cause de contraintes techniques, cependant, il a été fait le choix en accord avec l'entité à l'origine de la demande (en ne prenant donc pas en compte la situation de toutes les autres) que dès lors qu'une donnée est indiquée comme sensible dans le fichier de propriétés (autre que l'e-mail), alors l'e-mail l'est aussi.

Je dis simplement que je suis du même avis que Miguel de manière impartial.
L'infobulle sur la colonne pourrait contenir : "Les informations sensibles ne seront pas affichés dans les annuaires".
Pas d'infobulle dans le menu QVF.

Pour l'email c'est en effet discutable. Si on rend sa sensibilité paramétrable qu'est est l'impacte sur le développement ?

Aurore Allibe a écrit (#note-15):

On part sur une présentation comme ça?
L'intégration de l'icône doit inclure un title pour le survol : <img alt="donnée sensible" src="/silverpeas/util/icons/info-sensible.png" title="donnée sensible" />

Pour les fiches des utilisateurs pour lesquels données sensibles n'est pas activé, il ne faut pas que le symbole apparaisse.

Très bien

Sebastien Vuillet a écrit (#note-16):

Pour l'email c'est en effet discutable. Si on rend sa sensibilité paramétrable qu'est est l'impacte sur le développement ?

Oui. Ce n'est pas pour rien que je t'ai demandé si, pour le client, l'adresse email est de-facto une donnée potentiellement sensible.

Aurore Allibe a écrit (#note-18):

Peut être comme ça ? c'est plus clair ?

En effet, c'est mieux

Sebastien Vuillet a écrit (#note-20):

Aurore Allibe a écrit (#note-18):

Peut être comme ça ? c'est plus clair ?

En effet, c'est mieux

Miguel Moquillon a écrit (#note-19):

Sebastien Vuillet a écrit (#note-16):

Pour l'email c'est en effet discutable. Si on rend sa sensibilité paramétrable qu'est est l'impacte sur le développement ?

Oui. Ce n'est pas pour rien que je t'ai demandé si, pour le client, l'adresse email est de-facto une donnée potentiellement sensible.

Et du coup ? Si on permet le masquage/non masquage de cette données, c'est quoi l'impacte en terme de développement ?

Aurore Allibe a écrit (#note-18):

Peut être comme ça ? c'est plus clair ?

Pour le premier écran, je trouve que le picto est trop accolé sur les intitulés de champs dans le panneau de droite.
Je le verrais comme celui des données sensibles. Mais ce n'est que mon impression et mon avis.

Pour le texte explicatif des pictos, en lieu est place de "Données potentiellement sensibles", je mettrais plutôt "Donnée pouvant être sensible" (au singulier parce que le picto est attachée à chaque donnée concernée). En effet, le "potentiellement" ajoute dans ma tête une alarme de type "attention ces données ont fuitées à l'extérieur". Qu'en est-il pour vous ?.

Et le texte "Données sensibles activées", je le remplacerai bien par quelque chose comme "La sensibilité de la donnée est activée". Le mot "sensibilité" est utilisée dans le texte initial comme qualificatif et le sens général signifie plus que la donnée même, qualifiée de sensible, a été activée.

Sebastien Vuillet a écrit (#note-21):

Et du coup ? Si on permet le masquage/non masquage de cette données, c'est quoi l'impacte en terme de développement ?

Seb, on en a déjà discuté au début et tu avais donné ton accord. On va peut être éviter de revenir là dessus. Je ne sais plus trop ce qui compliquait (le fait que c'est une propriété à part des autres). Pas envie d'y revenir dessus. Surtout pour 1 seul client. S'il y a une demande en ce sens, ce sera l'occasion d'une nouvelle commande.

Miguel Moquillon a écrit (#note-23):

Sebastien Vuillet a écrit (#note-21):

Et du coup ? Si on permet le masquage/non masquage de cette données, c'est quoi l'impacte en terme de développement ?

Seb, on en a déjà discuté au début et tu avais donné ton accord. On va peut être éviter de revenir là dessus. Je ne sais plus trop ce qui compliquait (le fait que c'est une propriété à part des autres). Pas envie d'y revenir dessus. Surtout pour 1 seul client. S'il y a une demande en ce sens, ce sera l'occasion d'une nouvelle commande.

Bon alors on acte ce fonctionnement et on fera évoluer cette fonctionnalité si cela est nécessaire ultérieurement.

Précisions :
L'information de l'e-mail est une donnée qui est considérée comme pouvant être sensible quel que soit le paramétrage d'un domaine LDAP via son fichier de propriétés.
Par conséquent, ce n'est plus la combinaison entre le paramétrage d'un domaine et l'information de sensibilité d'un utilisateur qui permet d'indiquer si les informations sensibles peuvent être affichées ou pas. Seule l'information de sensibilité d'un utilisateur le permet.

Concernant la fonctionnalité, en dehors du filtrage des utilisateurs selon leur état, dans la page du domaine des utilisateurs, voici les points adressés.

Objectif¶

L'objectif de la fonctionnalité, à l'heure du RGPD et des politiques de protection des données utilisateurs, est de pouvoir cacher des informations sur un utilisateur de Silverpeas. Autrement dit de rendre celles-ci confidentielles. Cet utilisateur peut être un VIP comme indiqué dans l'intitulé de ce ticket ou un simple utilisateur qui requière la confidentialité de certaines de ses informations (par exemple pour éviter des harcèlements)

Le client, derrière cette fonctionnalité, souhaite utilisé celle-ci pour des VIP. Mais, évidemment, comme dans toute fonctionnalité intégrée dans le produit, nous nous devons prendre du recul sur les fonctionnalités demandées et l'ouvrir pour des cas plus généraux, lorsque c'est pertinent.

Portée¶

• seul les domaines d'utilisateurs hébergées par un annuaire LDAP (Active Directory, OpenLDAP, ...) sont concernés
• pas de mécanisme de désactivation ou d'activation de la fonctionnalité ; la fonctionnalité est toujours active
• l'adresse email est automatiquement marquée comme potentiellement sensible

Fonctionnement¶

1. définir dans le descripteur du domaine des utilisateurs de type LDAP les propriétés de l'utilisateur qui peuvent être sensibles
2. dans la fiche de l'utilisateur, dans le Back Office de Silverpeas, activer la confidentialité des données qui ont été marquées précédemment comme potentiellement sensible, en sus de l'adresse email.

Une donnée de l'utilisateur, dans sa fiche, dans le Back Office, est identifiée comme pouvant être sensible par un picto d'un point d'exclamation. Une donnée marquée comme sensible n'est pas encore sensible. Il faut, pour cela, activer la sensibilité des données de l'utilisateur. Une fois activée, les données sensibles, autrement dit confidentielles, qui ne doivent pas être, par conséquent, divulguées, sont identifiées dans la fiche de l'utilisateur, dans le Back Office, par le picto d'un cadenas.

Conséquence¶

• les données sensibles ne sont pas indexées avec les informations de l'utilisateur : il ne pourra pas être retrouvé par une recherche sur l'une d'elles
• la fiche de l'utilisateur, que ce soit dans l'annuaire générale ou dans l'annuaire des experts, ne contiendra aucune des données sensibles
• le profil de l'utilisateur ne contiendra aucune des données sensibles
• seul les administrateurs de la plate-forme, les gestionnaires du domaine de l'utilisateur, et l'utilisateur même pourront voir les informations sensibles.

Toutefois, même si l'adresse email est une donnée sensible et est cachée, l'utilisateur pourra être notifiée ou contactée via Silverpeas par un autre utilisateur. Le mécanisme d'envoi de la notification ou du message est assuré par Silverpeas ; si ces derniers doivent être communiqués par email à l'utilisateur, ils le seront. (Ceci ne nécessite pas la connaissance de l'adresse email par l'autre utilisateur.)

Je n'ai pas encore réalisé tous mes tests.

Dans un premier temps, comme il restait des travaux au niveau de l'administration de Silverpeas, je me suis focalisé sur l'affichage des informations sensibles dans les différentes fonctionnalités de Silverpeas.

Un point sur l'indexation des utilisateurs avait été identifié et remonté au travers d'autres échanges. Il a été pris en compte et va être prochainement vérifié.

J'ai identifié 2 autres anomalies au niveau de l'application Newsletter.
Les pré-requis pour les reproduire sont les suivants :

• la sensibilité des données est activée pour tous les utilisateurs de la plateforme (pas d’ambiguïté)

  UPDATE st_user
  SET sensitivedata = true;
  

• avoir une instance de ce composant avec des managers et des abonnées internes
• sélectionner Envoi par mail au niveau du paramètre d'instance Abonnés internes
• des newsletter en cours d'édition
• réaliser tous les cas de test avec un compte utilisateur n'ayant pas accès à l'administration de Silverpeas

Sous Microsoft SQL Server niveau de compatibilité SQL Server 2017, le script de migration de la table ST_User ne passe pas :

 10:03:30.2771805 [migrate]   Upgrade of the module busCore from version 044 to version 045
 10:03:30.3397258 [migrate]   Upgrade of the module busCore to version 045: [FAILURE]
 10:03:30.3397258 [migrate] Migration(s) of module busCore: [FAILURE]
 10:03:30.3397258 [migrate] Nom de colonne non valide : 'sensitiveData'.
java.sql.BatchUpdateException: Nom de colonne non valide : 'sensitiveData'.
    at net.sourceforge.jtds.jdbc.JtdsStatement.executeBatch(JtdsStatement.java:1069)

J'ai corrigé le soucis. C'est un problème de gestion transactionnel dans MS-SQL server. Le script SQL de migration est exécuté dans une seule transaction sans commit intermédiaire et sans cache (ce qui fait qu'une modification par une instruction n'est pas vue par la suivante). Il a été donc nécessaire d'éclater le script en deux, chacun étant exécuté l'un à la suite de l'autre, avec un commit entre les deux.