Comment fonctionne le SSO avec Active Directory, qui permet aux utilisateurs de se connecter de manière transparente à une application web intranet ?

Tout d'abord, et au cas où d'autres utilisateurs visiteraient cette page, seules certaines méthodes d'authentification permettent de réaliser un SSO sans invite. Ces méthodes sont les suivantes NTLM y Kerberos . LDAP - en revanche - ne vous permettra jamais d'effectuer un SSO sans invite.

NTLM est en fait NTLMv1 et NTLMv2. Ceux-ci sont très différents et NTLMv1 est obsolète en raison de graves problèmes de sécurité. Vous devriez éviter les solutions d'authentification Java qui n'identifient pas correctement si elles supportent NTLMv1 ou NTLMv2 parce qu'elles n'utilisent que le mot "NTLM" dans leur documentation. Il y a de fortes chances que les développeurs de cette solution de sécurité ne le sachent pas eux-mêmes, ce qui est une raison de plus pour chercher la sortie de secours.

Contrairement à la croyance traditionnelle, les protocoles NTLMv1 et NTLMv2 sont entièrement documentés par Microsoft, mais vous trouverez toujours des solutions qui prétendent avoir fait de l'ingénierie inverse. Il est vrai que cela était nécessaire avant que Microsoft ne documente les protocoles, je crois vers 2006 ou 2007. Quoi qu'il en soit, NTLMv1 est à proscrire. Il n'y a rien de mal à NTLMv2 en soi, mais Microsoft a progressivement abandonné NTLM (sous quelque forme que ce soit) dans tous ses produits en faveur de l'authentification Kerberos. NTLMv1 est mort depuis longtemps et NTLMv2 n'est plus utilisé par Microsoft que dans les cas où aucun contrôleur de domaine n'est disponible. En résumé : NTLM (sous quelque forme que ce soit) n'est pas vraiment la voie à suivre. Nous devrions en fait saluer Microsoft pour avoir adopté une approche basée sur les normes.

Il ne reste plus que Kerberos. Microsoft a créé un protocole pour négocier et transporter des informations d'authentification sur HTTP. Dans les produits Microsoft, ce protocole est connu sous le nom de " Authentification Windows intégrée "mais elle a été érigée en norme officielle sous le nom de SPNEGO . C'est ce que vous devez rechercher. SPNEGO supporte à la fois NTLMv2 et Kerberos comme mécanisme d'authentification sous-jacent, mais pour les raisons mentionnées ci-dessus, vous devriez choisir Kerberos plutôt que NTLMv2.

J'ai réussi à intégrer plusieurs applications Tomcat (fonctionnant sous Linux/Solaris) à Active Directory à l'aide de l'option Projet SPNEGO à SourceForge . J'ai trouvé que c'était l'approche la plus simple. Cela vous donne un SSO sans invite similaire à ce que fait, par exemple, un serveur Sharepoint. C'est très probablement ce à quoi vos utilisateurs s'attendent lorsqu'ils parlent de "SSO". La configuration correcte de Kerberos, la génération de clés et la mise en place de comptes "factices" dans Active Directory peuvent s'avérer fastidieuses, mais une fois qu'elles ont été mises en place, elles fonctionnent comme un charme.

La seule chose que je n'aime pas dans le Projet SPNEGO à SourceForge est que je ne comprends pas à quelle fréquence il effectue l'authentification. Je soupçonne qu'il le fait à chaque consultation de page plutôt qu'une fois par session. Je me trompe peut-être. Quoi qu'il en soit, cela met en évidence un autre élément à prendre en compte dans les solutions SSO : vous ne voulez pas mettre en œuvre une solution qui "spolie" votre fournisseur d'identité (disons Active Directory) avec des demandes inutiles.