Gibt es eine Möglichkeit, in Java oder mit einem Befehlszeilenprogramm ein Kerberos-Ticket für einen Dienst über die native SSPI-API zu erhalten?

Question

Ich möchte Single Sign On mit Kerberos in Java implementieren und habe es erfolgreich geschafft, ein Ticket für den Dienst zu erstellen, indem ich das Ticket aus der Windows-Anmeldung verwendet habe. Leider kann ich dieses Ticket nur erstellen, wenn der Registry Key "allowtgtsessionkey" aktiviert ist. Sobald ich ihn deaktiviere, erhalte ich eine Ausnahme mit der Meldung "Identifier doesn't match expected value (906)". Der Registrierungsschlüssel ist dokumentiert unter http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html y http://support.microsoft.com/kb/308339 .

Leider habe ich keinen Zugriff auf die Registrierung auf den Computern, auf denen meine Anwendung verwendet wird, also suche ich nach einer Möglichkeit, dies zu tun, ohne sie zu ändern. Wenn ich Single Sign On über SPNEGO im Internet Explorer oder Mozilla Firefox durchführe, wird ein Service-Ticket in meinem Ticket-Cache erstellt, also muss es auf jeden Fall eine Möglichkeit geben, dies zu tun, ohne den Registrierungsschlüssel zu setzen. Hat jemand eine Idee, wie man das in Java machen kann?

Vielen Dank für Ihre Hilfe, memminger

Update: Ich gebe dieses Problem auf. Der Windows-Registrierungsschlüssel verhindert den Zugriff auf das Ticket (genauer gesagt: den Betreff) im Ticket-Cache. Java auf Windows verwendet seine eigene GSSAPI-Implementierung, und ich nehme an, dass diese Zugriff auf das Ticket benötigt, um ein Service-Ticket zu erstellen. Die SSPI-Windows-API hat jedoch vollen Zugriff auf den Ticket-Cache und kann somit Service-Tickets erstellen. Diese API wird von den Webbrowsern verwendet, aber nicht von Java (laut http://java.sun.com/developer/technicalArticles/J2SE/security/#3 ). Wenn ich SSPI in Firefox deaktiviere, nachdem ich einmal auf eine Webseite zugegriffen habe (so dass ein Service-Ticket erstellt wurde), kann ich immer noch auf die Seite zugreifen, so dass vielleicht ein Befehlszeilen-Utility ausreichen würde, das ein Service-Ticket unter Verwendung der SPPI-API erstellt.

Für uns bedeutet dies nun, dass wir entweder auf Single Sign On verzichten können (was für uns inakzeptabel ist) oder dass wir die Authentifizierung auf der Client-Seite unserer Anwendung durchführen (da wir nur den Benutzernamen auslesen, aber das Ticket nicht auf dem Server verifizieren können), was ein großes Sicherheitsrisiko darstellt. Ein weiteres Beispiel dafür, wie stärkere Sicherheitseinschränkungen zu größeren Sicherheitslücken führen, weil sie zu kompliziert in der Anwendung werden.

Answer 1

Verzeihen Sie mir, wenn ich Ihr Problem falsch verstehe, aber...

Der Sinn von SSO-Systemen besteht darin, dass sich der Client direkt beim (separaten) Authentifizierungsserver authentifiziert und von diesem ein Ticket erhält. Anschließend gibt er das Ticket an den/die Zielserver weiter, die er verwenden möchte, und jeder von ihnen überprüft, ob das Ticket beim Authentifizierungsserver gültig ist. Wird das Ticket validiert, kann der Server davon ausgehen, dass der Client es nur erhalten hat, indem er dem (vertrauenswürdigen) Kerberos-Server akzeptable Anmeldedaten vorgelegt hat.

Nirgendwo im Prozess sollte ein Server eine Authentifizierung vornehmen im Namen von den Kunden. In einem solchen System muss nur der Authentifizierungsserver die Anmeldedaten des Kunden kennen und validieren - kein anderer Server muss Zugang zu diesen Informationen haben. Auf diese Weise kann sich der Client mit nur einem einzigen Authentifizierungsaustausch bei vielen Servern authentifizieren, und die Anmeldedaten sind nicht dadurch gefährdet, dass sie auf mehreren Servern gespeichert oder für diese zugänglich sind.

Es klingt, als würde Ihre Implementierung genau so funktionieren, wie sie sollte - die Authentifizierung sollte auf der Client-Seite der Anwendung stattfinden, und das ist korrekt und stellt kein Sicherheitsrisiko dar.

Answer 2

Haben Sie versucht, sun.security.jgss.native in Java 6 einzustellen? Wäre SSPI nicht die "native" Schnittstelle für Windows?

Answer 3

Sie können auf die native SSPI-API über JNA . Siehe die WindowsAuthProviderImpl sur WAFFEL o WindowsNegotiateScheme aus der Apache HC-Bibliothek für ein Beispiel.

Answer 4

Native Unterstützung für Windows SSPI wurde in JDK 13 eingeführt und später auch in JDK 11 zurückportiert. Sie müssen mindestens Java 11.0.10 verwenden. Wenn die JDK-Unterstützung für SSPI verwendet wird, ist es nicht mehr nötig, mit dem allowtgtsessionkey Registrierungsschlüssel und auch keine Notwendigkeit, JNA oder Waffle zu verwenden.

Sie müssen Folgendes einstellen

-Dsun.security.jgss.native=true

damit es funktioniert.

Sie können erkennen, ob Ihre JDK-Version für Windows Unterstützung für SSPI bietet, wenn sie eine Datei namens sspi_bridge.dll im bin Verzeichnis.

Verweise:

JDK-6722928