Wie funktioniert SSO mit Active Directory, bei dem Benutzer transparent bei einer Intranet-Webanwendung angemeldet sind?

Mir wurde gesagt, dass es möglich ist, eine Webanwendung zu erstellen, für die kein Login erforderlich ist. Der Benutzer meldet sich bei Windows an, das sich über eine Active Directory-Suche (LDAP) authentifiziert. Dann sollten sie in der Lage sein, auf meine Webapp zuzugreifen und niemals eine Anmeldeaufforderung zu sehen. Diese Kunden haben dies als Single Sign On bezeichnet (möglicherweise fälschlicherweise und ein Teil meiner Verwirrung).

Was ich jedoch in den Tomcat-Dokumenten unter Single Sign On gelesen habe, ist:

Das Einzelanmeldeventil wird verwendet, wenn Sie Benutzern die Möglichkeit geben möchten, sich bei einer der Webanwendungen anzumelden, die Ihrem virtuellen Host zugeordnet sind , und deren Identität dann von allen anderen Webanwendungen auf demselben virtuellen Host erkannt werden soll.

Das ist mir völlig klar. Der Benutzer muss sich einmal anmelden und kann auf jede Webanwendung auf einer Instanz von Tomcat zugreifen. Ich muss sie jedoch irgendwie anmelden lassen, ohne jemals Anmeldeinformationen für meinen Tomcat-Server bereitzustellen.

Damit dies funktioniert, stelle ich mir vor:

• Der Benutzer fordert eine Seite an
• Der Server sieht kein Sitzungstoken und fordert den Client zur Eingabe einiger Anmeldeinformationen auf.
• Der Client-Browser stellt ohne Benutzereingriff einige Anmeldeinformationen für den Server bereit.
• Unter Verwendung der vom Client-Browser bereitgestellten Anmeldeinformationen wird dann eine Suche in einem LDAP durchgeführt.

Ich habe einige Beispiele gesehen, die clientseitige Zertifikate verwenden ... insbesondere das DoD-PKI-System, das für mich sinnvoll ist, da Sie in diesen Fällen Tomcat so konfigurieren, dass clientseitige Zertifikate angefordert werden , sich jedoch nur in Windows anmelden würde funktionieren und welche Informationen würde der Browser an den Server weitergeben usw. Wird hierfür NTLM verwendet?

Erstens - und falls andere Benutzer diese Seite besuchen - gibt es nur bestimmte Authentifizierungsmethoden, mit denen Sie ein sofortiges SSO durchführen können. Dies sind NTLM und Kerberos . Mit LDAP hingegen erhalten Sie niemals ein sofortiges SSO.

NTLM ist eigentlich NTLMv1 und NTLMv2. Diese sind sehr unterschiedlich und NTLMv1 wird aufgrund schwerwiegender Sicherheitsprobleme nicht mehr empfohlen. Sie sollten Java-Authentifizierungslösungen meiden, die nicht korrekt identifizieren, ob sie NTLMv1 oder NTLMv2 unterstützen, da sie in ihrer Dokumentation nur das Wort "NTLM" verwenden. Wahrscheinlich kennen sich die Entwickler dieser Sicherheitslösung nicht aus. Dies ist umso mehr ein Grund, nach einem Fluchtweg zu suchen.

Entgegen der traditionellen Meinung sind sowohl NTLMv1 als auch NTLMv2 vollständig von Microsoft dokumentiert, aber Sie werden immer noch Lösungen finden, die behaupten, das Protokoll rückgängig gemacht zu haben. Es ist richtig, dass dies erforderlich war, bevor Microsoft die Protokolle dokumentierte, von denen ich glaube, dass sie um 2006 oder 2007 herum erstellt wurden. NTLMv1 ist sowieso ein Nein-Nein. An NTLMv2 per se ist nichts auszusetzen, aber Microsoft hat NTLM (in irgendeiner Form) in allen seinen Produkten zugunsten der Kerberos-Authentifizierung eingestellt. NTLMv1 ist lange tot und NTLMv2 wird nur noch von Microsoft verwendet, wenn kein Domänencontroller verfügbar ist. Fazit: NTLM (in irgendeiner Form) ist nicht wirklich der richtige Weg. Wir sollten Microsoft tatsächlich dafür begrüßen, dass es hier einen auf Standards basierenden Ansatz verfolgt.

So bleiben Sie bei Kerberos. Microsoft hat ein Protokoll zum Aushandeln und Transportieren von Authentifizierungsinformationen über HTTP erstellt. Dies ist in Microsoft-Produkten als " Integrierte Windows-Authentifizierung " bekannt, wurde jedoch als offizieller Standard unter dem Namen SPNEGO festgelegt . Dies ist, wonach Sie suchen sollten. SPNEGO unterstützt sowohl NTLMv2 als auch Kerberos als zugrunde liegenden Authentifizierungsmechanismus. Aus den oben genannten Gründen sollten Sie jedoch Kerberos anstelle von NTLMv2 als Ziel verwenden.

Ich habe erfolgreich mehrere Tomcat-Anwendungen (unter Linux / Solaris) mit Active Directory unter Verwendung des SPNEGO-Projekts bei SourceForge integriert . Ich habe festgestellt, dass dies der einfachste Ansatz ist. Auf diese Weise erhalten Sie ein sofortiges SSO, ähnlich wie es beispielsweise ein Sharepoint-Server tut. Dies ist höchstwahrscheinlich das, was Ihre Benutzer erwarten, wenn sie von "SSO" sprechen. Die Kerberos-Konfiguration richtig einzustellen, Schlüssel zu generieren und Dummy-Konten in Active Directory einzurichten, kann mühsam sein, aber sobald Sie es richtig eingestellt haben, funktioniert es wie ein Zauber.

Das einzige, was mir am SPNEGO-Projekt bei SourceForge nicht gefällt, ist, dass ich nicht verstehe, wie oft es die Authentifizierung durchführt. Mein böser Verdacht ist, dass dies nicht für jede Sitzung, sondern für jeden Seitenaufruf der Fall ist. Vielleicht irre ich mich dabei. Auf jeden Fall: Dies unterstreicht eine andere Sache, die bei SSO-Lösungen zu beachten ist: Sie möchten keine Lösung implementieren, die Ihren Identitätsanbieter (z. B. Active Directory) mit unnötigen Anforderungen "spamt".

In einer Windows Active Directory-Umgebung bedeutet Single Sign On, dass der Besuch einer internen Webseite Ihre Windows-Anmeldeberechtigungen enthält und der Webserver darauf reagieren kann. Es ist etwas, wofür NTLM verwendet wird, aber neuere Implementierungen verwenden stattdessen Kerberos.

Wenn Sie eine Sharepoint Server-Website öffnen, wissen Sie, wer Sie sind, ohne dass Sie einen Login-Benutzernamen und ein Passwort benötigen. Dies funktioniert jedoch nur für interne Websites im selben Netzwerk. Ich halte es für wenig sinnvoll, wenn Sie auf einer öffentlichen Website arbeiten. (Ich kann nicht sagen, ob Sie "virtueller Host" wie in einem Apache vhost oder wie in einem ausgelagerten gehosteten Server meinen).

In diesem Microsoft-Dokument wird beschrieben, wie die Kerberos-Authentifizierung auf einem Webserver mit IIS / ASP.Net funktioniert: http://msdn.microsoft.com/en-us/library/ff647076.aspx

Es sieht möglich aus, mit Apache / Tomcat / Java zu tun. Hier ist eine PDF-Datei, die eine Implementierung der britischen Universität beschreibt: http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf und ein Codeplex-Projekt dafür: http://tomcatspnego.codeplex.com/ und Openfire haben einige Dokumentation zum allgemeinen Arbeiten mit Java / Kerberos hier ( http://community.igniterealtime.org/docs/DOC-1060 ).

Klingt so, als würden Sie beschreiben, was Microsoft als integrierte Windows-Authentifizierung bezeichnet.

Es sieht so aus, als ob Tomcat die Windows-Authentifizierung unterstützt, basierend auf diesem Artikel .

Für den Anfang können Sie nicht vermeiden, sich anzumelden. Wenn Sie Benutzer identifizieren möchten, müssen Sie sie anmelden. Vergessen Sie NTLM, Kerberos kommt zur Hilfe - es kann alles auf völlig transparente Weise erledigen.

Das SingleSignOnValve ist nicht das, wonach Sie suchen. Wenn Sie Tomcat 7 verwenden, können Sie den SpnegoAuthenticator sofort verwenden, aber auf 6 müssen Sie diesen verwenden .