Single-Sign-On ist in Windows Domänen ein gern gesehen Feature und wie hier bereits vorgestellt via SPNEGO auch für Java Webanwendungen realisierbar. Ohne zusätzliche Konfiguration funktioniert SPNEGO nur dann, wenn sowohl der Browser als auch die Webanwendung innerhalb der gleichen Domäne arbeiten. Dies ist immer dann kritisch, wenn in großen Installation aus Last- und/oder Managementgründen mehrere Windows Domänen parallel betrieben werden. Dieser Artikel stellt die Hintergründe vor, um SPNEGO auch Domänenübergreifend einzusetzen, so dass Browser und Server in unterschiedlichen Domänen arbeiten können

Als erstes ist es notwendig zu verstehen, wie das Verhältnis zwischen unterschiedlichen Domänen definiert ist. Eine Domäne, die einer Identifikation vertraut, welche in einer anderen Domäne durchgeführt wurde, wird als “Trust” bezeichnet. Wichtig ist zu verstehen, dass es zwei Arten gibt, wie dieser Trust zustande kommen kann:

1. Direct Trust
   Ein direkter Trust ist explizit durch die jeweiligen Domain Admin definiert. Ein typisches Anwendungsbeispiel wäre von COMPANY1.COM zu COMPANY2.COM
2. Indirect Trust / Domain Forrest Trust
   Alternativ kann ein Trust automatisch, d.h. ohne zusätzlichen Eingriff des Domain Admins, indirekt durch einen Domain Forrest entstehen. Ein Beispiel hierzu wäre:
   • COMPANY.COM als Forrest Root
     • REALM003.COMPANY.COM als Kind-Domäne
     • REALM007.COMPANY.COM als Kind-Domäne

Wenn der Browser in REALM003 ist und der Server in REALM007 ist, entsteht zunächst ein Problem, da weder REALM003 direkt zu REALM007 ein Trust Verhältniss hat, noch umgekehrt.
Indirekt vertraut aber REALM007 dem Forrest Root COMPANY.COM und dieser wiederrum REALM003.

Das im letzten Beispiel angeführte indirekte Trust Verhältniss muss nun der SPNEGO Implementierung auf dem Server bekannt gegeben werden. Hierzu dient die Kerberos-Konfigurationsdatei krb5.ini. Eine Beispieldatei, passend zu oberen Szenario ist im folgenden angeführt:

[libdefaults]
ticket_lifetime = 600
default_tgt_enctypes = aes256-cts aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes256-cts aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
forwardable = true
default_realm = REALM007.COMPANY.COM

[realms]
COMPANY.COM = {
 kdc = xyz.company.com:88
 default_domain = company.com
}
REALM007.COMPANY.COM = {
 kdc = xyz.realm007.company.com:88
 default_domain = realm007.company.com
}
REALM003.COMPANY.COM = {
 kdc = xyz.realm003.company.com:88
 default_domain = realm003.company.com
}

Wenn nun die SPNEGO Serverimplementierung ein Kerberos Ticket von dem fremden REALM003 bekommt, kann Sie sich über den Forrest-Root zum zuständigen KDC für REALM003 durchfragen.

Es bleibt allerdings noch eine Ausnahme, falls der Forrest nicht streng hierarchisch aufgebaut ist. Dies kann ebenfalls in der krb5.ini Datei abgebildet werden, allerdings muss dann zusätzlich mit [capaths] Elementen gearbeitet werden.

Hierzu gibt es einen sehr hilfreichen Artikel bei Redhat, wo das Thema auch nochmals ausführlich erklärt wird.

Nachdem eine Kerberos keytab Datei erstellt wurde (siehe Beschriebung im vorherigen Posting), stellt sich die Frage, wie diese möglichst einfach getestet werden kann. Hierzu bringt das Standard JDK bereits alles nötige mit.

Im Standard JDK ist auf allen Plattformen ein kinit-Utility enthalten. Für Diagnose Zwecke besteht nun der entscheidende Trick darin, an diesem Utility die Kerberos-Debug Option zu aktivieren. Hier ein Beispiel:

SET KINIT=c:\Program Files\Java\jdk1.6.0_20\bin\kinit
SET KEYTAB=d:\webapps\app1\WEB-INF\serverhostname.keytab
SET SPN=HTTP/app1.intranet.company.com@REALM002.COMPANY.COM
SET KRB5INI=d:\webapps\app1\WEB-INF\krb5.ini
"%KINIT%" -k -t "%KEYTAB%" %SPN% -J-Dsun.security.krb5.debug=true "-J-Djava.security.krb5.conf=%KRB5INI%"

Das Utility versucht ein TGT (Ticket Granting Ticket) vom KDC (Key Distribution Cewnter in Form des Windows Active Directory) anzufordern. Dies entspricht genau dem Vorgang, den eine SPNEGO Implementierung beim Start des Tomcat durchführt.

Durch die aktivierte Debug Option lassen sich Fehler einfacher aufspüren und da das Utility autark von der eigentlichen Web-Anwendung läuft, scheidet diese schon mal als Fehlerquelle aus.

Sobald das Utility erfolgreich ein Ticket bezogen hat, erscheint als letzte Zeile die Meldung:

New ticket is stored in cache file C:\Documents and Settings\myuser\krb5cc_myuser

Seit der Erstellung der JGSS Dokumentation für Kerberos in Java haben sich mit Windows Server 2008 hilfreiche Vereinfachungen ergeben. Diese werden hier kurz vorgestellt.

Die Konfiguration von JGSS für Kerberos ist hinreichend dokumentiert. Beispiele hierzu sind:

• Java SE Security Overview
• Tutorial: Signle-Sign-On Using Kerberos in Java
• Krb5LoginModule

Diese laufen alle auf die Erstellung einer Keytab Datei durch den Windows Domänen Administrator hinaus. Seit Windows 2003 hat sich hier eine wichtige Verbesserung ergeben, nämlich der optionale Parameter “/mapOp set”. Beispiel:

ktpass
   /out serverhostname.keytab
   /mapuser realm002\username
   /princ HTTP/app1.intranet.company.com@REALM002.COMPANY.COM
   /crypto RC4-HMAC-NT
   /pass XXXXXXXX
   /ptype KRB5_NT_PRINCIPAL
   /mapOp set

Der Parameter “/mapOp set” überschreibt gegebenenfalls existierende SPN Mappings automatisch, was vorher manuell und fehleranfällig durch einen seperaten “setspn -D” Aufruf erledigt werden musste. Hierdurch wird immer ein richtiges SPN-Mapping sicher gestellt, was die weitere Inbetriebnahme erleichtert da es eine Fehlerquelle eliminiert.

Natürlich ist dies nur ab dem zweiten ktpass-Versuch relevant. Die Erfahrung zeigt aber, dass meist mehr wie ein ktpass Lauf notwendig ist, bevor wirklich alle Parameter stimmen.