Comment fonctionne l'authentification unique avec Active Directory où les utilisateurs sont connectés de manière transparente à une application Web intranet?
On me dit qu'il est possible de créer une application Web qui ne nécessite pas de connexion. L'utilisateur se connecte à Windows, qui s'authentifie via une recherche Active Directory (LDAP). Ensuite, ils devraient pouvoir accéder à ma webapp et ne jamais voir d'invite de connexion. Ces clients ont appelé cela l'authentification unique (peut-être à tort et en partie dans ma confusion).
Mais, d'après ce que j'ai lu Single Sign On à partir des documents Tomcat, voici:
La valve de connexion unique est utilisée lorsque vous souhaitez donner aux utilisateurs la possibilité de se connecter à l'une des applications Web associées à votre hôte virtuel , et puis faire reconnaître leur identité par toutes les autres applications Web sur le même hôte virtuel.
C'est parfaitement clair pour moi. L'utilisateur doit se connecter une fois et peut accéder à chaque application Web sur une instance de Tomcat. Mais, ce que je dois faire, c'est de les laisser se connecter sans jamais fournir d'informations d'identification à mon serveur Tomcat.
Donc, pour que cela fonctionne, j'imagine:
- L'utilisateur fait une demande pour une page
- Le serveur ne voit aucun jeton de session, puis demande au client certaines informations d'identification.
- Le navigateur du client sans aucune intervention de l'utilisateur fournit certaines informations d'identification au serveur.
- Ensuite, en utilisant ces informations d'identification fournies par le navigateur des clients, il effectue une recherche dans un LDAP.
J'ai vu quelques exemples qui utilisent des certificats côté client ... en particulier le système DoD PKI qui a du sens pour moi parce que dans ces cas, vous configurez Tomcat pour demander des certificats côté client , mais vous connectez simplement à Windows Je ne vois pas comment cela fonctionnerait et quelles informations le navigateur transmettrait au serveur, etc. Est-ce pour cela que NTLM est utilisé?
Tout d'abord - et au cas où d'autres utilisateurs visiteraient cette page - il n'y a que certaines méthodes d'authentification qui vous permettent de faire une authentification unique rapide. Ce sont NTLM et - Kerberos. LDAP - d'autre part - ne vous donnera jamais d'authentification unique rapide.
NTLM est en fait NTLMv1 et NTLMv2. Ce 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 ne parviennent pas à identifier correctement si elles prennent en charge NTLMv1 ou NTLMv2 car elles utilisent uniquement le mot "NTLM" dans leur documentation. Il y a de fortes chances que le développeur de ladite solution de sécurité ne 't savent eux-mêmes ce qui est une raison de plus pour rechercher l'escalier de secours.
Contrairement à la croyance traditionnelle, NTLMv1 et NTLMv2 sont entièrement documentés par Microsoft, mais vous trouverez toujours des solutions qui prétendent avoir "rétroconçu" le protocole. 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 un non-non. Il n'y a rien de mal avec NTLMv2 en soi, mais Microsoft a supprimé progressivement NTLM (sous toutes ses formes) dans tous ses produits en faveur de l'authentification Kerberos. NTLMv1 est mort depuis longtemps et NTLMv2 n'est désormais utilisé par Microsoft que dans les cas où aucun contrôleur de domaine n'est disponible. Conclusion: 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 des normes ici.
Cela vous laisse avec Kerberos. Microsoft a créé un protocole pour négocier et transporter les informations d'authentification via HTTP. Ceci est connu dans les produits Microsoft comme " Authentification Windows intégrée " mais il a été cloué en tant que norme officielle sous le nom de SPNEGO . C'est ce que vous devriez rechercher. SPNEGO prend en charge NTLMv2 et Kerberos comme mécanisme d'authentification sous-jacent, mais pour les raisons ci-dessus, vous devriez cibler Kerberos plutôt que NTLMv2.
J'ai réussi à intégrer plusieurs applications Tomcat (fonctionnant sous Linux/Solaris) avec Active Directory en utilisant Projet SPNEGO chez SourceForge . J'ai trouvé que c'était l'approche la plus simple. Cela vous donne une authentification unique sans fil similaire à ce que fait par exemple un serveur Sharepoint. C'est probablement ce à quoi vos utilisateurs s'attendront lorsqu'ils parleront de "SSO". Obtenir la bonne configuration Kerberos, générer des clés et configurer des comptes "factices" dans Active Directory peut être un problème, mais une fois que vous avez bien fait, cela fonctionne comme un charme.
La seule chose que je n'aime pas dans le Projet SPNEGO chez SourceForge est que je ne comprends pas à quelle fréquence il effectue l'authentification. Mon méchant soupçon est qu'il le fait pour chaque page vue plutôt qu'une fois pour chaque session. Je me trompe peut-être là-dessus. Quoi qu'il en soit: cela met en évidence une autre chose à considérer dans les solutions SSO: vous ne voulez pas implémenter une solution qui "spams" votre fournisseur d'identité (par exemple Active Directory) avec des demandes inutiles.
Dans un environnement Windows Active Directory, l'authentification unique est utilisée pour signifier que la visite d'une page Web interne comporte vos autorisations de connexion Windows et que le serveur Web peut agir sur celles-ci. C'est quelque chose pour lequel NTLM est utilisé, mais les nouvelles implémentations utilisent Kerberos à la place.
Si vous ouvrez un site Web Sharepoint Server, il sait qui vous êtes sans avoir besoin d'un nom d'utilisateur et d'un mot de passe de connexion, mais cela ne fonctionne que pour les sites Web internes sur le même réseau, je ne pense pas qu'il soit très logique qu'il fonctionne sur un site Web public. (Je ne peux pas dire si vous voulez dire "hôte virtuel" comme dans un vhost Apache ou comme dans un serveur hébergé externalisé).
Voici un document Microsoft décrivant le fonctionnement de l'authentification Kerberos sur un serveur Web exécutant IIS/ASP.Net: http://msdn.Microsoft.com/en-us/library/ ff647076.aspx
Il semble possible de le faire avec Apache/Tomcat/Java. Voici un PDF décrivant une implémentation de cette université au Royaume-Uni: http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf et un projet Codeplex pour il: http://tomcatspnego.codeplex.com/ et Openfire ont une documentation à faire avec le fonctionnement général de Java/Kerberos ici ( http://community.igniterealtime.org/docs/DOC-106 ).
Pour commencer, vous ne pouvez pas éviter la connexion. Si vous souhaitez identifier les utilisateurs, vous devez les faire se connecter. Oubliez NTLM, Kerberos vient à la rescousse - il peut tout faire de manière totalement transparente.
Le SingleSignOnValve n'est pas ce que vous recherchez. Si vous utilisez Tomcat 7, vous pouvez utiliser SpnegoAuthenticator tout de suite mais sur 6, vous devez utiliser this .
Semble que vous décrivez ce que Microsoft appelle l'authentification Windows intégrée.
Il semble que Tomcat prend en charge l'authentification Windows, basée sur cet article .