Le cross domain authentification ou comment envoyer un cookie d'un domaine à l'autre

Pour maintenir une session le protocole du web (HTTP) ne prévoit pas vraiment de mécanisme. Il faut pour cela utiliser les cookies (RFC 2109). Mais un cookie par mesure de sécurité ne relève que d'un seul domaine. Le client (navigateur) ne doit accepter des cookies que pour le domaine de l'url consultée. Et il ne doit les présenter que sur le domaine en question.

Alors comment passer un cookie d'un domaine à l'autre ?. Cette opération peut etre 'légale' dans un but de propagation d'information (authentification ou autre) ou illégale afin de capturer les cookies.
Dans les deux cas la technique est un peu similaire.

Le serveur web sur le domaine appli.domainA qui veut récupérer le cookie déposé par appli.domainB (donc un domaine diffèrent) va dans une des pages de l'appli.domainA inserer un lien vers une ressource de appli.domainB. Pour que le processus soit invisible pour l'utilisateur on utilise souvent un lien vers une image de taille de 1 pixel. Le gestionnaire de l'appli.domainA doit évidemment avoir accès à la location sur domainB qui héberge cette image pour enregistrer les cookies.

L'autre méthode utilisée pour propager la session d'un domaine à un autre est le cross domain authentification: Le site domainA qui veut passer la valeur de son cookie à domainB va réaliser une redirection de domainA vers domainB en passant en paramètre la valeur de son cookie , comme par exemple :
get http://appli.domainB/service?cookiesurdomainA=valeur.

Cette technique pose plusieurs problèmes:

Quel est le nom du paramètre, de l'url du service , du mode d'encodage et sur quelle url rebrancher l'utilisateur.

Les protocoles Oauth , openID servent à normaliser tout ceci.

Temps d'inactivité.

Dans un système où un utilisateur travaille sur 5 domaines, on peut imaginer un dispositif de controle du timeout (temps d'inactivité ) de la session.
Chaque domaine dépose un cookie mis à jour à chaque sollicitation.
En ca de timeout détecté par un domain , il interroge successivement les autres domaines pour collecter l'état du compteur inactivité. En fonction du résultat collecté , le serveur valide ou invalide le timeout. L'url servant de support aux interrogations serait de la forme : get http://serveur.domainSuivant/timeout?cookiedomainA=30min&cookiedomainB=0 etc.
Il est plus facile de réaliser ce montage en définissant un domaine maitre et des domaines esclaves.

Le processus de connexion pourrait etre le suivant :



dans l'implementation du Lemonldap le CDA est construit sous la forme d'une redirection:

print CGI::redirect($controlslave."?op=$session_id&url=".$urlc);

Qui va donner : http://serveur.domaine?op=valeur_cookie&url=url_de_retour