Il est théoriquement possible depuis une instance d’une entité déverrouillée sur un serveur, local, de demander à ouvrir une nouvelle instance sur un autre serveur, distant. Cette authentification peut simplement être faite en rejouant le mot de passe de l’entité du serveur local. Il faut que le serveur distant connaisse l’entité et dispose de l’objet de la clé privée accessible avec le mot de passe. La nouvelle instance serait alors ouverte dans un nouvel onglet du navigateur.
Cela implique la transmission du mot de passe. Il faut impérativement passer par une connexion chiffrée (TLS) avec authentification (certificat) du serveur distant afin de protéger le transit du mot de passe.
Cela implique aussi que le serveur distant va connaître le mot de passe de l’entité, au moins le temps de la session. Il faut donc avoir autant confiance dans le serveur distant qu’en le serveur local.
Il est cependant possible aussi de transmettre le mot de passe d’une sous-entité vers le serveur distant. Ainsi on peut penser centraliser sur un serveur/périphérique local une entité maîtresse et ses sous-entité, et utiliser certaines sous-entités exclusivement sur des serveurs distants, y compris des serveurs de faible confiance.
Cela veut dire que l’on doit pouvoir associer une localisation avec une entité.
En fait, cela est très simple à réaliser. Il suffit de générer un lien HTTP vers le serveur distant avec en argument l’application, l’entité et le mot de passe… le tout dans un nouvel onglet.
Et en ajoutant dans le lien HTTP un mode et une vue il est même possible de chaîner l’authentification vers un troisième serveur. On a dans ce cas un niveau de relai d’authentification et un peu de dissimulation.
Ceci n’est pas implémenté. Suite au prochain épisode…
Une réflexion sur « Relais d’authentification »