Discussion :

[antoine57]

Bonjour,

Dans le cadre du boulot, je suis à la recherche d'une architecture qui permettrait à l'utilisateur de passer du http à https et inversement de façon transparente.

J'avais déjà bossé avec Spring auparavant mais je n'ai pas étudié la partie Spring Security.

J'ai réalisé un petit projet qui m'a permis de voir que le passage du http au https était facilement configurable à l'intérieur d'un même site.

Cependant, la partie https serait là pour sécuriser une partie du site, et l'utilisateur devrait pouvoir naviguer entre la partie non sécurisée et sécurisée.

J'ai pensé à un cookie qui me permettrait de stocker le SessionId : lorsque le user se logge dans la partie sécurisée (https) le cookie est initialisé avec le session id crypté. Quand il repasse en partie non sécurisée, le session id est perdu mais il serait alors possible de demander au serveur de me redonner la session sécurisée lorsque le user repasse en https.

Malheuresement, une des contraintes du projet est de ne pas utiliser de cookies

Je me tourne donc vers la communauté pour une idée d'une architecture.

A bientot,

A

[patouche]

Heu....

Ta contrainte est de ne pas utilisé de cookiees ?? Pas du tout ? Rien ? Vraiment ??

Si oui, ce que tu peux faire, c'est utiliser un CAS (en mode TGC). Comme ça tu délègues à une appli tierce la création de ton cookie et c'est le cas qui t'authentifie. C'est surement ce que je ferais à ta place... Demande si tu peux faire ça. Après, savoir à quoi tu connectes ton cas, c'est un autre problème.

Après, sur les techniques de SSO, le OAuth (connection google / twitter / facebook / ...) ne fonctionnera probablement pas car ta session est locale à ton application (il me semble). Sinon, tu as peut-être une session sur ton domaine parent. Un peu comme google ou finalement gmail.google.com / drive.google.com / ... utilise la session .google.com. C'est peut-être une solution...

Sinon, dans le genre de solution pourri, tu peux faire transiter le session id dans l'url ou se baser sur le user agent. C'est surtout pire que mieux ...

Redemande pour la session car c'est bizarre. Le http est stateless. Tu vas pas réinventer le protocole pour ton besoin...

sinon, http / https, normalement, il partage les même cookies car ils sont sur le même domaine donc probablement par défaut la même session.

Bon courage.

[ruscov]

Je ne comprend pas bien pourquoi tu devrais utiliser des cookies pour ton https. En tous cas dans la doc, je n'en vois pas mention : http://docs.spring.io/spring-securit...quires-channel
Autre remarque, la documentation prévient aussi :

Note that in order to be truly secure, an application should not use HTTP at all or switch between HTTP and HTTPS. It should start in HTTPS (with the user entering an HTTPS URL) and use a secure connection throughout to avoid any possibility of man-in-the-middle attacks.

Donc quand tu dis que tu veux passer de l'un à l'autre, ça semble êter une mauvaise pratique.

[patouche]

@ruscov : dans le web, la session se traduit normalement par un cookie coté client. Comment veux tu faire autrement ?

S'ils n'en font pas mention dans spring, c'est juste parce que cela n'a rien à voir avec spring... Du point de vue du client, ce n'est pas de spring dont il est question mais du protocole http.

Après, tu as tout à fait raison, pour éviter un man in the middle, il te faut bien un https certifié afin d'être certain de l'identité du serveur avec qui tu dialogues.

La phrase que tu cites est tout à fait exact. C'est une mauvaise pratique qu'il est préférable d'éviter. Cependant, c'est totalement possible (et très fréquent aussi)... C'est basé sur l'idée que je citais dans le précédent message : pour un host données, les cookies du http et https sont partagé. Après, quite à avoir un https correct, autant l'utilisé :-).