Discussion :

[tchize_]

Bonjour,

je n'y connais rien en SSO ou en kerberos mais, à priori, ce serait la meilleure alternative pour éviter de stocker des mot de passe en clair dans ma session http afin de se connecter au nom de l'utilisateur courant à des services tiers.

J'ai donc un portail en cours de mise en place. Celui-ci authentifie les utilisateurs (protocole https, method basic), et on veux préserver cette partie.
Ce portail dois se connecter à différents webservice au nom de cet utilisateur pour présenter une aggrégation de différentes sources de données. Actuellement, tous ces service utilisent aussi https/basic. Ce qui nous oblige à stocker dans la webapplication, lors du login de l'utilisateur, son mot de passe. C'est moche et si un méchant pirate accède à ces sessions, on a des mots de passe dans la nature.

D'après ce que j'ai compris, voir le shéma en annexe, je peux demander lors du login, à ma première application, d'obtenir un ticket sur une serveur type kerberos, et forwarder ce ticket aux différentes applications qui se trouvent en dessous. Est-ce vraiment viable comme solution ou ce genre de solution nécessite-t-il absolument que ce soit le browser qui discute avec kerberos (auquel cas je l'ai dans l'os).

Question subsidiaire: est-ce "facile" de mettre en place un kerberos sur un ldap existant?

Merci à tous

[Balbuzard]

Bonjour!

Alors ton schéma n'est pas tout à fait exact dans le cas d'un SSO. Justement le principe est de procéder une unique fois à l'authentification, et cela se fait du client final (l'internaute) directement avec le serveur kerberos. Le client envoie son principal (nom qu'il prétend être) kerberos renvoie un mot de passe de session maitre chiffré avec la clef symétrique du client (tout est symétrique). Si le client est celui qu'il prétend être, alors il est en mesure de déchiffrer la clef de session maitre.

Dans un deuxième temps, il va vouloir se connecter au service (ici HTTP). Alors il envoie une requêtre au serveur kerberos, le chiffrement se fait avec la clef de session maitre déchiffrée à l'étape précédente. Le serveur lui communique la clef de session service chiffrée avec la clef de session maitre (donc le client et le serveur sont seuls à pouvoir déchiffrer) ainsi que la clef de service chiffrée avec la clef du serveur HTTP. (Le serveur HTTP est un client kerberos comme un autre qui s'est déjà authentifié auprès du serveur kerberos).

Enfin, le client se connecte au serveur HTTP. Il connait la clef de session de service, et fournit au serveur HTTP la clef de session de service chiffrée avec la clef de service, obtenue depuis le serveur kerberos, qu'il ne connait pas, mais que le serveur HTTP connait. L'information de la clef de session de service est alors partagée par le serveur HTTP et le client, l'échange peut commencer.

Seule la première partie est à l'initiative du client, le reste lui est transparent (SSO).

Je ne sais pas exactement si le navigateur communique avec le serveur kerberos (ce serait dans tous les cas dans la deuxième phase, et il n'y a pas échange de mot de passe, mais de clef). Mais d'une manière ou d'une autre, le client oui (dans la première et dans la deuxième). Éventuellement, mais je ne sais absolument pas comment je m'y prendrais, avec un proxy qui récupère le mot de passe (donc sur le portail) et qui lui fait du kerberos. Mais du coup on a le mot de passe dans le navigateur du client. Ça ne me parait pas une bonne idée. Vaut mieux que le client discute directement avec kerberos.

Enfin, non, ça ne me parait pas trivial c'est assez tendu, même s'il existe des tutoriaux assez bien fait, la doc se trouve facilement. Ce qui sera le plus dur dans ton cas, c'est justement que ton cas est peut-être déjà complexe. J'ai trouvé des choses assez sympa dans le linux magazine "kerberos, le SSO universel" N°143. Après, la méthode me semble solide niveau sécurité, s'intègre bien avec un ldap, et est multiplateforme (peut importe que les clients soient windows ou linux). La configuration apache sur un service web pour faire du kerberos est simple. Mais il faudra vraiment faire des maquettes avant de se lancer :O

Voilà, hésite pas à me faire part de l'avancement de ton projet

[tchize_]

Merci de ta réponse

Pour expliquer clairement, j'ai l'architecture suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
        Client http 
            |
   (authentification) --> LDAP
            |
            v
     serveur http
       /   |   \
      /    |    \
   (authentification) --> LDAP
    /      |      \
   v       v       v
 différent service tiers http

J'ai le contrle sur le server http et les service http, pas sur le LDAP ni sur la configuration de client (qui peux d'ailleurs très bien être un utilisateur sur son PC personnel à domicile)

Le serveur http étant une couche de présentation, il collecte des informations au nom de l'utilisateur courant auprès des différent service http. Il faut donc qu'il transfère à ces services les credentials de l'utilisateur courant. Je veux éviter le transfert du user / pass, car pour ce faire, je devrais les stocker en clair, et c'est vraiment pas une bonne idée.

J'avais donc pensé sans connaitre kerberos que mon serveur http aurait pu lorsque l'utilisateur crée un session, demander un ticket avec le user / pass et oublier le user / pass pour ne conserver que le ticket et transférer ce ticket aux services à la demande.

Mais vu la complexité de la chose et surtout que malheureusement ça nécessite tout un bordel dans le LDAP, c'est une voie sans issue. La solution adoptée pour le moment: lorsque l'utilisateur s'authentifie, on s'authentifie immédiatement auprès des différents service en transférant le login/pass, et on conserve les différents cookies de session obtenu. Ca marche tant que les différents service ne redémarrent pas, malheureusement.

Je suis toujours ouvert à toute proposition ne nécessitant ni de stocker les mots de passe, ni de faire une révolution dans l'entreprise. Bref 3/4 jours de travail grand maximum.