Unterstützung des Authentifizierungsverfahrens Kerberos (KRB5) für die Sicherheit
Das Authentifizierungsverfahren Kerberos ermöglicht die Interoperabilität mit anderen Anwendungen (wie z. B. .NET, DB2 und anderen), die die Kerberos-Authentifizierung unterstützen. Das Verfahren unterstützt interoperable SSO-End-to-End-Lösungen (Single Sign-on) und bewahrt die ursprüngliche Anforderer-ID.
- Was ist Kerberos?
- Vorteile von Kerberos als Authentifizierungsverfahren
- Kerberos-Authentifizierung in einer Umgebung mit einem einzigen Kerberos-Realm
- Kerberos-Authentifizierung in einer Umgebung mit mehreren oder anerkannten Kerberos-Realms
- Vor der Konfiguration von Kerberos als Authentifizierungsverfahren für WebSphere Application Server zu berücksichtigende Aspekte
- Unterstützungsinformationen für Kerberos-Authentifizierung
- Kerberos als Authentifizierungsverfahren für WebSphere Application Server konfigurieren
- Kerberos als Authentifizierungsverfahren für einen reinen Java-Client konfigurieren
Was ist Kerberos?
Kerberos hat den Prüfungen der Zeit widerstanden und befindet sich jetzt bei Version 5.0. Kerberos wird auf zahlreichen Plattformen unterstützt (z. B. Windows, Linux, Solaris, AIX und z/OS). Dies ist zum Teil darauf zurückzuführen, dass der Kerberos-Quellcode vom Massachusetts Institute of Technology (MIT), von dem er ursprünglich entwickelt wurde, kostenlos zum Download zur Verfügung gestellt wird.
Kerberos setzt sich aus drei Teilen zusammen: einem Client, einem Server und einer ankannten dritten Partei, dem so genannten Kerberos Key Distribution Center (KDC). Das KDC stellt die Authentifizierungs- und Ticket-Granting-Services bereit.
Das KDC verwaltet eine Datenbank bzw. Repository mit Benutzeraccounts für alle Sicherheitsprincipals in seinem Realm. Viele Kerberos-Distributionen verwenden dateibasierte Repositorys für die Kerberos-Principal- und -Richtliniendatenbank, andere verwenden LDAP (Lightweight Directory Access Protocol) als Repository.
Kerberos unterstützt keine Gruppen (d. h. iKeys-Gruppen oder Gruppen von Benutzern oder Principals). Das verwaltet einen Langzeitschlüssel für jeden Principal in seiner Accountdatenbank. Dieser Langzeitschlüssel wird aus dem Kennwort des Principals abgeleitet. Nur das KDC und der Benutzer, den der Principal darstellt, sollten den Langzeitschlüssel bzw. das Kennwort kennen.
Vorteile von Kerberos als Authentifizierungsverfahren
Im Folgenden sind einige Vorteile des Einsatzes von Kerberos als Authentifizierungsverfahren für WebSphere Application Server beschrieben:
- Das Kerberos-Protokoll ist ein Standard. Es ermöglicht die Interoperabilität mit anderen Anwendungen (wie z. B..NET, DB2 und anderen), die die Kerberos-Authentifizierung unterstützen. Das Verfahren unterstützt interoperable SSO-End-to-End-Lösungen (Single Sign-on) und bewahrt die ursprüngliche Anforderer-ID.
- Wenn Sie die Kerberos-Authentifizierung verwenden, verlässt das Benutzerkennwort die Benutzermaschine nie im Klartext. Der Benutzer authentifiziert sich und ruft ein Kerberos-Ticket-Granting-Ticket (TGT) von einem KDC über einen nicht umkehrbaren Hash-Wert des Benutzerkennworts ab. Außerdem ruft der Benutzer über das TGT ein Kerberos-Serviceticket vom KDC ab. Das Kerberos-Serviceticket stellt die Clientidentität dar, die zur Authentifizierung an WebSphere Application Server gesendet wird.
- Ein Java-Client kann am Kerberos-SSO teilnehmen, indem er den Kerberos-Cache für Berechtigungsnachweise verwendet, um sich bei WebSphere Application Server zu authentifizieren.
- J2EE-, Web-Service-, .NET- und Web-Browser-Clients, die das HTTP-Protokoll verwenden, können das
SPNEGO-Token (Simple and Protected GSS-API Negotiation Mechanism) verwenden, um sich bei
WebSphere Application Server zu authentifizieren und über die
SPNEGO-Webauthentifizierung am SSO teilzunehmen. Die Unterstützung für SPNEGO als Webauthentifizierungsservice
ist in diesem Release von WebSphere Application Server neu.
Weitere Informationen finden Sie im Artikel Single Sign-On für HTTP-Anforderungen mit SPNEGO-Webauthentifizierung.
- WebSphere Application Server kann die Authentifizierungsverfahren Kerberos und LTPA (Lightweight Third-Party Authentication) gleichzeitig unterstützen.
- Die Kommunikation zwischen Servern über Kerberos-Authentifizierung wird unterstützt.
Kerberos-Authentifizierung in einer Umgebung mit einem einzigen Kerberos-Realm
WebSphere Application Server unterstützt die Kerberos-Authentifizierung in einer Umgebung mit einem einzigen Kerberos-Realm, wie in der folgenden Abbildung gezeigt:

Wenn WebSphere Application Server ein Kerberos- oder SPNEGO-Token zur Authentifizierung empfängt, verwendet er den Kerberos-Service-Principal (SPN), um einen Sicherheitskontext mit einem Anforderer einzurichten. Wenn ein Sicherheitskontext eingerichtet ist, extrahiert das Kerberos-Anmeldemodul von WebSphere einen Clientberechtigungsnachweis für die GSS-Delegierung, erstellt auf der Basis des Kerberos-Berechtigungsnachweises ein Kerberos-Authentifizierungstoken und kopiert diese zusammen mit anderen Token in das Clientsubjekt.
Wenn der Server einen Downstream-Server (nachgeschalteten Server) oder Back-End-Ressourcen verwenden muss, verwendet er den Client-Berechtigungsnachweis für GSS-Delegierung. Wenn ein Downstream-Server die Kerberos-Authentifizierung nicht unterstützt, verwendet er anstelle des Kerberos-Tokens das LTPA-Token. Ist in der Anforderung des Clients kein Berechtigungsnachweis für GSS-Delegierung enthalten, verwendet der Server das LTPA-Token für den Downstream-Server. Kerberos-Authentifizierungstoken und -Principal werden an den Downstream-Server über das Weitergabefeature für Sicherheitsattribute weitergegeben.
Wenn WebSphere Application Server und das KDC nicht dieselbe Benutzerregistry verwenden, kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, um den Kerberos-Principal-Namen dem WebSphere-Benutzernamen zuordnen zu können.
Kerberos-Authentifizierung in einer Umgebung mit mehreren oder anerkannten Kerberos-Realms
WebSphere Application Server unterstützt die Kerberos-Authentifizierung auch in einer Umgebung mit mehreren oder anerkannten Kerberos-Realms, wie in der folgenden Abbildung gezeigt wird:

Wenn WebSphere Application Server ein Kerberos- oder SPNEGO-Token zur Authentifizierung empfängt, verwendet er den Kerberos-Service-Principal (SPN), um einen Sicherheitskontext mit einem Anforderer einzurichten. Wenn ein Sicherheitskontext eingerichtet ist, extrahiert das Kerberos-Anmeldemodul von WebSphere immer einen Clientberechtigungsnachweis für die GSS-Delegierung und ein Kerberos-Ticket und kopiert diese zusammen mit anderen Token in das Clientsubjekt.
Wenn der Server einen Downstream-Server (nachgeschalteten Server) oder Back-End-Ressourcen verwenden muss, verwendet er den Client-Berechtigungsnachweis für GSS-Delegierung. Wenn ein Downstream-Server die Kerberos-Authentifizierung nicht unterstützt, verwendet er anstelle des Kerberos-Tokens das LTPA-Token. Ist in der Anforderung des Clients kein Berechtigungsnachweis für GSS-Delegierung enthalten, verwendet der Server das LTPA-Token für den Downstream-Server. Kerberos-Authentifizierungstoken und -Principal werden an den Downstream-Server über das Weitergabefeature für Sicherheitsattribute weitergegeben.
Wenn WebSphere Application Server und das KDC nicht dieselbe Benutzerregistry verwenden, kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, um den Kerberos-Principal-Namen dem WebSphere-Benutzernamen zuordnen zu können.
In diesem Release von WebSphere Application Server unterstützen die neuen Sicherheitsdomänen Kerberos nur auf Zellenebene. Alle WebSphere Application Server müssen von demselben Kerberos-Realm verwendet werden. Die Clients und Back-End-Ressourcen (wie z. B. DB2, .NET-Server und andere), die die Kerberos-Authentifizierung unterstützen, können jedoch einen eigenen Kerberos-Realm haben. Es werden nur die Peer-to-Peer- und die transitive Authentifizierung zwischen anerkannten Realms unterstützt. Die folgenden Schritte müssen für anerkannte Kerberos-Realms ausgeführt werden:
- Die Konfiguration der anerkannten Kerberos-Realms muss in jedem Kerberos-KDCs durchgeführt werden. Weitere Informationen zum Konfigurieren eines anerkannten Kerberos-Realms finden Sie in Ihrem Kerberos-Handbuch für Administratoren und Benutzer.
- Der anerkannte Realm muss in der Kerberos-Konfigurationsdatei aufgelistet werden.
- Sie können anerkannte Kerberos-Realms über die Administrationskonsole hinzufügen, indem Sie auf klicken.
In der folgenden Abbildung wird ein Java- und Verwaltungsclient gezeigt, der einen Kerberos-Cache für Berechtigungsnachweise für die Authentifizierung bei WebSphere Application Server über ein Kerberos-Token in einem anerkannten Kerberos-Realm verwendet:

- Der Client verwendet den Kerberos-Cache für Berechtigungsnachweise, sofern ein solcher vorhanden ist.
- Der Client fort ein realmübergreifendes Ticket (TGS_REQ) für Realm A vom KDC von Realm B über den Kerberos-Cache für Berechtigungsnachweise an.
- Der Client verwendet ein realmübergreifendes Ticket, um ein Kerberos-Serviceticket für server1 (TGS_REQ) vom KDC von Realm A anzufordern.
- Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an server1 gesendet.
- Der Server ruft Krb5LoginModuleWrapper auf, um den Sicherheitskontext mit dem Client über den Kerberos-Service-Principal-Namen (SPN) und die Schlüssel des Servers aus der Datei krb5.keytab einzurichten. Wenn der Server den Sicherheitskontext mit dem Client erfolgreich einrichtet, extrahiert er immer den Berechtigungsnachweis für GSS-Delegierung und die Tickets des Clients und kopiert sie in das Clientsubjekt.
- Optional kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, wenn das KDC und WebSphere Application Server nicht dieselbe Benutzerregistry verwenden.
- Der Benutzer wird über die WAS-Benutzerregistry validiert.
- Die Ergebnisse (Erfolg oder Fehler) werden an den Client zurückgegeben.
In der folgenden Abbildung wird ein Java- und Verwaltungsclient gezeigt, der einen Kerberos-Principal-Namen und das zugehörige Kennwort für die Authentifizierung bei WebSphere Application Server mit einem Kerberos-Token verwendet:

- Der Client ruft das Kerberos-Granting-Ticket (TGT) vom KDC ab.
- Der Client ruft über das TGT ein Kerberos-Serviceticket für server1 (TGS_REQ) ab.
- Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an server1 gesendet.
- Der Server ruft Krb5LoginModuleWrapper auf, um den Sicherheitskontext mit dem Client über den Kerberos-Service-Principal-Namen (SPN) und die Schlüssel des Servers aus der Datei krb5.keytab einzurichten. Wenn der Server den Sicherheitskontext mit dem Client erfolgreich einrichtet, extrahiert er immer den Berechtigungsnachweis für GSS-Delegierung und die Tickets des Clients und kopiert sie in das Clientsubjekt.
- Optional kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, wenn das KDC und WebSphere Application Server nicht dieselbe Benutzerregistry verwenden.
- Der Benutzer wird über die WAS-Benutzerregistry validiert.
- Die Ergebnisse werden an den Client zurückgegeben.
In der folgenden Abbildung wird die Kommunikation zwischen Servern gezeigt:

Wenn ein WebSphere Application Server gestartet wird, verwendet er die Server-ID und das zugehörige Kennwort für die Anmeldung beim KDC und ruft dann das TGT ab. Anschließend verwendet er das TGT, um ein Serviceticket für die Kommunikation mit einem anderen Server anzufordern. Wenn ein WebSphere Application Server die interne Server-ID anstelle von Server-ID und Kennwort verwendet, erfolgt die Kommunikation zwischen den Servern über ein LTPA-Token. In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:
- WebSphere Application Server 1 ruft eine Methode "foo()" in einer Enterprise JavaBeans (EJB) auf, die in WebSphere Application Server 2 ausgeführt wird.
- Server1 ruft über das TGT für Server1 ein Kerberos-Serviceticket für Server2 (TGS_REQ) ab.
- Identisch mit Schritt 2.
- Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an Server2 gesendet.
- Server2 ruft die Methode "acceptSecContext()" auf, um über den Kerberos-Service-Principal-Namen (SPN) und die Schlüssel von server2aus der Datei krb5.keytab einen Sicherheitskontext mit server1 einzurichten. Wenn server2 den Sicherheitskontext mit server1 erfolgreich einrichtet, extrahiert er immer den Berechtigungsnachweis für GSS-Delegierung und die Tickets von server1 und kopiert sie in das Subjekt.
- Die Server-ID wird über die WebSphere-Benutzerregistry validiert.

Vor der Konfiguration von Kerberos als Authentifizierungsverfahren für WebSphere Application Server zu berücksichtigende Aspekte
WebSphere Application Server unterstützt jetzt SPNEGO-Token im HTTP-Header, Kerberos-Token, LTPA-Token und BasicAuth (GSSUP) für die Authentifizierung.
- Die Option Delegierung der Kerberos-Berechtigungsnachweise aktivieren muss ausgewählt sein. Weitere Informationen zu dieser Option finden Sie im Artikel Kerberos über die Administrationskonsole als Authentifizierungsverfahren konfigurieren.
- Ein Client muss ein Ticket-Granting-Ticket (TGT) mit adresslosen und erneuerbaren Attributen zur Weiterleitung abrufen, damit ein Zielserver einen Kerberos-Berechtigungsnachweis für Clientdelegierung extrahieren und an den nachgeschalteten Server senden kann.
- Ein Client-TGT mit einer Adresse kann nicht für nachgeschaltete Server, den DRS-Cache und Clusterumgebungen verwendet werden.
- Prüfen Sie, ob Ihre Kerberos-KDC-Plattform, um sicherzustellen, dass sie Kerberos-Berechtigungsnachweise für Clientdelegierung unterstützt.
- Für eine Anwendung mit langer Laufzeit muss ein Client ein TGT mit einem Flag für Verlängerung anfordern, sodass der Zielserver den Kerberos-Berechtigungsnachweis für Delegierung verlängern kann.
- Bei einer Anwendung mit langer Laufzeit sollten Sie sicherstellen, dass das Kerberos-Ticket mindestens so lange gültig ist, wie die Anwendung aktiv ist. Wenn der Anwendungsprozess eine Transaktion ausführt, die fünf Minuten in Anspruch nimmt, muss das Kerberos-Ticket mindestens fünf Minuten lang gültig sein.
- Die Kerberos-Authentifizierung und die SPNEGO-Webauthentifizierung werden für domänenübergreifende Active Directory-Vertrauensstellungen Trusts in derselben Gesamtstruktur unterstützt.
- Damit ein Verwaltungsagent das Kerberos-Authentifizierungsverfahren
verwenden kann, muss er einen LTPA-Schlüssel mit einem Verwaltungssubsystemprofil austauschen.
Die folgende angepasste Sicherheitseigenschaft muss auf true gesetzt werden: com.ibm.websphere.security.krb.longLivedTicket.
- Wenn Sie für die Downstream-Authentifizierung den Kerberos-Berechtigungsnachweis für Clientdelegierung verwenden möchten, vergewissern Sie sich, dass der Client ein Serviceticket anfordern kann, das eine Lebensdauer von mehr als 10 Minuten hat. Ist die Lebensdauer des Kerberos-Berechtigungsnachweises für Clientdelegierung kürzer als 10 Minuten, versucht der Server, den Berechtigungsnachweis zu erneuern.
- Eine vollständige End-to-End-Unterstützung mit Tivoli Access Manager ist mit den folgenden KDCs verfügbar:
- z/OS
- Microsoft (ein Realm oder mehrere Realms)
- AIX
- Linux
- Sie können jetzt Kerberos-Realms für WebSphere Application Server und den Thin Client konfigurieren und aktivieren.
- Die Verwaltungsfunktion von WebSphere Application Server wird mit Kerberos durch Folgendes beschränkt:
- Das bevorzugte Authentifizierungsverfahren für flexible Verwaltungsaktivititäten ist (standardmäßig) das Authentifizierungsverfahren River Shamir Adleman (RSA).
- Der mit Kerberos für die Verwaltungsauthentifizierung konfigurierte Job-Manager unterstützt keine Kerberos-übergreifenden Realms. Die Realms müssen als registrierte Knoten in demselben Kerberos-Realm enthalten sein, oder die Verwaltungsauthentifizierung muss auf RSA gesetzt sein.
- Obwohl die Kerberos-Authentifizierung für Verwaltungsclients (wsadmin und Java-Clients) unterstützt wird, sollten Sie denselben KDC-Realm wie der verwaltete WebSphere Application Server verwenden. Andernfalls werden eine Benutzer-ID und ein Kennwort empfohlen.
- Die Kerberos- und LTPA-Konfiguration für heterogene Zellen wird nicht unterstützt, wenn einige Knoten Knoten der WebSphere Application Server Release 6.x oder früher sind.
Unterstützungsinformationen für Kerberos-Authentifizierung
- Anerkennung externer Domänen, die sich nicht in derselben Gesamtstruktur befinden
- Anerkennung von Domänen in derselben Gesamtstruktur
- Anerkennung von Kerberos-Realms
- Strukturübergreifende Anerkennung
- Anerkennung externer Gesamtstrukturen
Kerberos als Authentifizierungsverfahren für WebSphere Application Server konfigurieren
Kerberos als Authentifizierungsverfahren für einen reinen Java-Client konfigurieren
Endbenutzer können das Kerberos-Authentifizierungsverfahren optional für den reinen Java-Client konfigurieren. Weitere Informationen finden Sie im Artikel Java-Client für Kerberos-Authentifizierung konfigurieren.