Gestion des cookies par K-Sup
La version 7.0 de K-Sup introduit une nouvelle fonctionnalité sur les cookies.
Les cookies, notamment le cookie de session, sont générés par le serveur d'application (tomcat) afin de faire un lien entre un utilisateur et le serveur applicatif.
Les cookies sont ajoutés dans les entêtes de réponse par le serveur d'application via un composant nommé CookieProcessor".
Par défaut, le CookieProcessor de tomcat retourne un cookie sans domaine ni attribut samesite.
Le navigateur remplit alors les blancs avec des valeurs par défaut.
- Le cookie est associé au site courant (et seulement au site courant, sans les sous-domaine)
- Le coolie est limité au site courant et ses sous-domaine (aka "LAX")
Afin de simplifier la connexion des utilisateurs et de permettre un SSO compatible avec les règles CORS (Cross-Origin Resource Sharing),
un CookieProcessor modifié est injecté par le K-Sup au démarrage de la webapp.
Une notion de filtre a été ajoutée afin de n'appliquer ce CookieProcessor spécialisé que sur certains cookies.
Par défaut, seul le cookie nommé KSUP-SSO-UUID est pris en charge.
Il est possible d'ajouter d'autres cookies en valorisant la propriété cookie.processor.filter avec la liste des cookies concernés sous forme d'une chaine séralisée avec "," comme séparateur (NAME1,NAME2,...)
cookie.processor.filter=KSUP-SSO-UUID
Le nouveau CookieProcessor apporte les fonctionnalités suivantes :
- L'attribut SameSite est forcé à None sur tous les cookies pris en charge
L'attribut "SameSite=None" autorise le navigateur à envoyer le cookie vers le domaine du cookie, y compris si l'appel est réalisé depuis un site d'un autre domaine. Depuis le site www.acme.com, si un script réalise un appel XmlHttpRequest vers le site www.acme.fr, le cookie sera envoyé avec la requête. Le SSO K-Sup est basé sur ce fonctionnement. - Le drapeau "Secure" est forcé sur tous les cookies pris en charge
Le drapeau "Secure" doit obligatoirement être positionné dans l'entête de réponse Set-Cookie si l'attribut "SameSite" est valorisé à "None".
Pour être accepté par le navigateur, le cookie devra donc transiter via un canal sécurisé (HTTPS) ou être interrogé sur le site localhost. - Le drapeau "HttpOnly" est forcé sur tous les cookies pris en charge
Cette fonctionnalité n'est pas obligatoire, mais elle améliore la sécurité en empêchant la lecture en javascript des cookies.
A noter, une particularité des navigateurs permet d'ignorer le drapeau "Secure" des cookie si le domaine courant est "localhost" ou "xxxxx.localhost". Il est donc possible, sous certaines conditions sur les domaines de conserver le fonctionnement standard du CookieProcessor (true + None) dans un environnement local