Authentification multiple d'un même utilisateur invalide les sessions précédentes

[bugeaud]

En cas d'authentification multiple avec un même utilisateur, la nouvelle session force l'invalidation des anciennes sessions utilisateurs.

Scénarios testés pour un même utilisateur

1. Authentification dans un même navigateur dans le mode normal puis en mode privé : KO
2. Authenfication dans un navigateur puis dans un autre navigateur sur la même machine : KO
3. Authentification dans un navigateur sur une machine puis sur un autre navigateur d'une autre machine : KO

[MedShake]

C'est voulu. Hérité de ce que je fais depuis toujours sur mes sites web. Je ne dis pas que c'est idéal cependant, mais c'est bien le comportement attendu. De mémoire une histoire de salage lors de l'identification avec l'IP (plus sur) et le user agent, je crois. L'idée, c'est d'empêcher que l'application soit active pour un même user sur X machines avec des utilisateurs qui sèmeraient des sessions à droite à gauche. En gros je préfère l'idée de l'identification longue sur un seul poste (le plus classique en situation de travail), que l'identification courte qui nécessite de reloguer toutes les 4h.

[bugeaud]

Ne pas permettre à un même utilisateur de se connecter par exemple sur son PC et son mobile en simultané (par exemple) ne me semble pas être un fonctionnement habituel pour un service web.

Mon cas d'usage de test a été pour diagnostiquer des problèmes de comportement, on est ammené à utiliser plusieurs authentifications d'un même utilisateur (dans deux contextes user-agent). Le fait que celà écrase la session précédente rend la reproduction du problème et les tests vraiment lourd.

S'il y a salage & co pour utilisation de cookie par exemple celà ne doit poser aucun problème car chaque session a bien un contexte différent (session PHP coté serveur et stockage cookie &co coté user-agent)

En complément, je ne sais pas quel est la charge de session pour un utilisateur côté apache actuellement pour EHR (je regarderais ça à l'occasion), mais ce n'est plus généralement un problème avec les capacités de mémoires des serveurs actuels. Sauf à avoir des services avec plusieurs centaines de sessions simultanées / utilisateurs simultanés par instances.

[MedShake]

Ne pas permettre à un même utilisateur de se connecter par exemple sur son PC et son mobile en simultané (par exemple) ne me semble pas être un fonctionnement habituel pour un service web.

Je comprends bien. Mais nous sommes ici dans le cadre d'exploitation de données personnelles classées au plus haut niveau de risque. Un identifiant doit être strictement personnel et dans ce cadre, puisque Shiva ne s'est pas déclaré utilisateur de la solution, il me semble bien plus sécuritaire de faire sauter toutes les identifications sur les postes non utilisés où elles pourraient subsister. Quand des besoins particuliers de double identification sont apparus, par exemple pour phonecapture, nous les avons traités avec un cadre d'accès limité aux données au travers d'une porte d'entrée spécifiques.

D'ailleurs cette politique va dans le sens d'un accès par carte professionnelle ou la clef d'accès physique est unique et ne permet pas le log simultané sur divers périphériques.

[bugeaud]

D'ailleurs cette politique va dans le sens d'un accès par carte professionnelle ou la clef d'accès physique est unique et ne permet pas le log simultané sur divers périphériques.

Celà n'est pas tout à fait la situation actuelle. Je n'ai pas vu de telle limitation ni sur le portail fédérateur Pro Santé Connect, ni sur l'application eCPS à ce sujet. J'ai testé par exemple avec une eCPS et un accès au DMP pro sur deux périphériques différents et l'accès fonctionne sans problème. Et au vu des technologies utilisées celà est relativement logique.

Pour ce qui est de la CPS, le "blocage" vient simplement du fait que quand on retire la CPS d'un lecteur le middleware sur l'hôte pour carte est censé vidanger ses sessions (et remonter une fermeture des applications utilisatrices idéalement) pour une question de sécurité. Mais, il est souvent bien possible d'ouvrir plusieurs sessions valide via de la virtualisation de périphérique USB, une sur chaque VM a minima. Là on est dans une zone grise niveau middleware, et c'est plus ou moins fiable de mes constatations. Mais je n'ai pas encore testé cette possibilité avec le middleware de la CPS pour confirmer si celà se passe sans problème ou non. Mais je l'ai utilisé sur d'auttres applications d'authentification deux facteurs.

Pour le reste, ce qu'il est important d'avoir c'est des comptes unipersonnels dont l'identité est garantie pour assurer l'imputabilité. Si aprés le titulaire du compte veut contrevenir aux règles de confidentialité (ou règles d'utilisations de la carte) et donner les éléments facteurs d'authentification à un tiers, il prend ses responsabilités et ne pourra pas s'en prévaloir pour se dégager de ses obligations.

Par exemple, si certains professionels ont comme habitude de donner leur CPS + pin à leur secrétatiat ou à leur remplaçant, au lieu d'avoir demandé une carte CPE pour leurs secrétaires, d'affecter la CPS du remplaçant ou de vérifier que le remplaçant a une CPF s'il est non thésé. Mais c'est un problème qui est hors responsabilité Medshake EHR à mon sens.

[MedShake]

La doctrine a peut-être changé, mais il me semble bien, de tout ce que j'avais lu au sujet de la CPS dans les diverses docs officielles à l'époque, que la gestion de l'arrachage et ses conséquences (delog) était toujours signalées comme un impératif à respecter. Ouvrir pour moi la porte à une authentification multiple reviendrait à dupliquer la CPS. Comme tu le dis très bien, la bidouille est l'usage en milieu médical sur ce point ... mais faut-il y céder ?

Bref, ceci-dit, moi ce ne me pose pas de problème si quelqu'un souhaite intégrer une option quelque part qui permette l'authentification multiple du même utilisateur sur différents terminaux. Par défaut moi je metrais off et documenterais l'option comme le reste.