Configurer le partage d’authentification avec les paramètres allowAuthentificationSharing et centralSphereList

Lorsque l’instance du logiciel BDF est configuré pour gérer des fichothèques multiples, celles-ci sont par défaut indépendantes les unes des autres. Si cette instance est propre à une seule organisation qui crée plusieurs fichothèques distinctes pour répondre à ses besoins, il est particulièrement intéressant de partager l’authentification afin d’éviter aux personnes utilisatrices de saisir à chaque fois leur mot de passe.

Le partage d’authentification ne fonctionne qu’au sein des fichothèques multiples d’une même instance. Il est sans rapport avec les protocoles de partage d’authentification ou de délégation d’autorisation comme OAuth.

Le partage d’authentification ouvre également la possibilité de faire des liens entre fiches de fichothèques différentes (voir Comment faire référence à des fiches d’un corpus d’une autre fichothèque ?).

Pour activer le partage d’authentification, il faut utiliser le paramètre d’initialisation allowAuthentificationSharing (voir Les paramètres d’initialisation du logiciel BDF dans le contexte Tomcat pour plus de détails sur les emplacements de configuration de ce type de paramètre.). Les trois valeurs possibles sont :

• strict : partage d’authentification en mode strict : seules les personnes appartenant à une sphère gérée de manière centralisées auront accès au partage d’authentification

• lax : partage d’authentification en mode laxiste : le partage d’authentification se fait par similitude des identifiants de connexion entre les fichothèques

• none : aucun partage d’authentification (mode par défaut)

Historiquement, le partage en mode laxiste a été le premier développé et pendant longtemps le seul disponible. Son principe est simple : si une personne se connecte à une fichothèque avec un identifiant de connexion donné et qu’une autre fichothèque possède une sphère de même nom qui contient le même identifiant de connexion, alors la personne a accès à la seconde sphère sans besoin de donner son mot passe.

Ce mode a pour mérite la simplicité mais il ouvre la faille de sécurité suivante : comme toute personne administratrice d’une sphère peut modifier l’identifiant de connexion d’un des membres de la sphère, elle peut changer l’identité d’une personne et lui donner accès à une autre fichothèque même si elle même n’y a pas accès non plus.

Autrement dit, tant que l’usage des fichothèques multiples est limitée à une poignée de personnes qui ont accès à tout, le mode laxiste ne pose pas de problème. Il est à éviter si le nombre de personnes augmentent, en particulier si les droits diffèrent d’une fichothèque à une autre et que certaines sont confidentielle.

Le mode strict repose sur l’indication des sphères qui seront gérées de manière centrale (avec le même identifiant que l’administration des fichothèques multiples). La création de nouvelles personnes, le changement de mot de passe ou d’identifiant de connexion seront effectuée dans l’interface d’administration centrale. Ces commandes resteront accessibles dans les sphères correspondantes des différentes fichothèques mais uniquement si la personne administratrice est connectée à la fois comme administratrice de la fichothèque et à l’administration centrale.

En mode strict, il est toujours possible de créer d’autres sphères dans les fichothèques mais elles ne pourront pas servir pour le partage d’authentification.

L’indication des sphères centrales se fait avec le paramètre centralSphereList qui doit avoir comme valeur les noms des sphères séparées par une espace. Les sphères centrales peuvent être définies indépendamment du mode de partage d’authentification choisi.

Dans l’exemple ci-dessous, les deux sphères centrales sont admin et fph.

<Context>
  ...
  <Parameter name="multiBdf" value="true"/>
  <Parameter name="allowAuthentificationSharing" value="strict"/>
  <Parameter name="centralSphereList" value="admin fph"/>
  ...
</Context>