Gestion des Jetons (token) de connexion

L'objetif de cette fonctionnalité est d'éviter à un utilisateur d'avoir à s'identifier s'il s'est déjà identifié en amont.

Le mécanisme permet une connexion au serveur web en utilisant simplement un identifiant (ie : pas de mot de passe) et met en jeu trois « acteurs » : le navigateur de l'utilisateur, le serveur web amont servant la page contenant le lien d'accès au présent serveur WEB.

Ce système est utilisé, de manière transparente, dans la solution SSO avec IIS.

Processus

1 - Un navigateur demande une page au serveur amont

2 - Lors du calcul de la page, le serveur amont envoie une URL d'obtention de token en y incluant l'ID de l'utilisateur (qui est supposé être connu du serveur). L'URL est constituée de la manière suivante :

http://10.1.1.167/GetToken.txt?ID=DOC

3 - Si l'application dispose de cette ressource et si le paramètre W_CT (Connexion par Token) vaut 1, elle calculera un jeton :

!4D=insert;http_token(http_getparam("ID"));3!

Et renverra dans la page de résultat le jeton qui comporte, de manière codée, l'ID de l'utilisateur ainsi que les date et heure de création.

 

Exemple : 470027476317477542470029470025433751430702

4- Dans la page calculée par le serveur amont, on place un iframe avec appel à une page vide sur ce serveur Web.

Exemple :

​

<iframe src='http://www.MaBase.fr/blank.htm?ID_token=470027476317477542470029470025433751430702' width="100%" height="1" frameborder="no" allowtransparency="true"></iframe>

5- Le navigateur reçoit cette page et aussitôt demande la page au serveur.

6- L'application voit le paramètre ID_Token dans l'URL : il extrait l'ID du jeton et vérifie que le délai d'utilisation du jeton (60 secondes par défaut mais réglable grâce à la fiche paramètre W_TT) n'est pas dépassé. Si tout est OK, Kenrtika envoie la page demandée avec un cooky.

7- Le navigateur peut ensuite accèder au site (par tout lien de son choix) : il est déjà identifié et son contexte a été créé.

Variante 1

Au lieu de mettre un iframe, on propose le lien d'accès avec le token.

Exemple :

http://10.1.1.167/Main.htm?ID_Token=470027475318478536470029470025433751430702

Si cette méthode semble plus simple, elle présente deux inconvénients :

Si le token n'est pas utilisé rapidement, il est perdu : on aura donc tendance à augmenter sa durée de vie. L'utilisateur voit en clair le fait qu'un token est envoyé. Ce n'est donc pas suffisament transparent pour l'utilisateur et introduit donc une possibilité (bien que minime) de détournement par un utilisateur aguerri.

Variante 2

Si le serveur n'est pas en mesure de calculer l'URL incluant le token, on peut envisager d'utiliser des pages avec des redirections successives. Cependant, le système est encore moins sécurisé car l'utilisateur verrait alors la construction de la première URL (qui comporterait obligatoirement le moyen d'identification de l'utilisateur).

Complément

Si le serveur amont n'est pas en mesure de fournir l'identifiant exact, il doit au minimum transmettre un moyen de l'identifier de manière sûre. L'appel à la fonction : http_token(http_getparam("ID")) prend en paramètre un identifiant. Celui peut être soit transmis directement dans l'URL soit résulter d'un calcul préalable.

Le système peut être encore plus sécurisé soit en adoptant une convention de cryptage commune entre le serveur amont et le serveur WEB, soit en calculant une clé complémentaire.

Précaution : le mode d'obtention d'un jeton pour un serveur amont ne doit jamais être divulgué au « grand public ». En effet, tout informaticien de bon niveau serait en mesure de reproduire son fonctionnement et donc de s'identifier à la place de quelqu'un d'autre.