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.

Anmerkung: Die Sicherheitsunterstützung für Kerberos als Authentifizierungsverfahren ist in WebSphere Application Server Version 7.0 neu hinzugekommen. Kerberos ist ein ausgereiftes, flexibles, offenes und sehr sicheres Netzauthentifizierungsprotokoll. Kerberos umfasst Funktionen für Authentifizierung, gegenseitige Authentifizierung, Integrität und Vertraulichkeit von Nachrichten sowie Delegierungsfeatures. Sie können Kerberos auf der Serverseite aktivieren. Die Unterstützung wird bereitgestellt, um dem Rich-Java™-Client die Verwendung des Kerberos-Tokens für die Authentifizierung in WebSphere Application Server zu ermöglichen.

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:

Abbildung 1. Kerberos-Authentifizierung in einer Umgebung mit einem einzigen Kerberos-RealmWebSphere Application Server unterstützt die Kerberos-Authentifizierung in einer Umgebung mit einem einzelnen Kerberos-Realm.

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:

Abbildung 2. Kerberos-Authentifizierung in einer Umgebung mit mehreren oder anerkannten Kerberos-RealmsWebSphere Application Server unterstützt auch die Kerberos-Authentifizierung in Umgebungen mit mehreren oder anerkannten Kerberos-Realms.

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 Globale Sicherheit > Abgehende CSIv2-Kommunikation > Anerkannte Authentifizierungsrealms - abgehend 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:

Abbildung 3. Verwendung des Kerberos-Caches für Berechtigungsnachweise für die Authentifizierung bei WebSphere Application Server über ein Kerberos-Token in einem anerkannten Kerberos-RealmVerwendung eines Kerberos-Cache für Berechtigungsnachweise für die Authentifizierung in WebSphere Application Server mit einem Kerberos-Token in einem anerkannten Kerberos-Realm
In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:
  1. Der Client verwendet den Kerberos-Cache für Berechtigungsnachweise, sofern ein solcher vorhanden ist.
  2. 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.
  3. Der Client verwendet ein realmübergreifendes Ticket, um ein Kerberos-Serviceticket für server1 (TGS_REQ) vom KDC von Realm A anzufordern.
  4. Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an server1 gesendet.
  5. 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.
  6. Optional kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, wenn das KDC und WebSphere Application Server nicht dieselbe Benutzerregistry verwenden.
  7. Der Benutzer wird über die WAS-Benutzerregistry validiert.
  8. 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:

Abbildung 4. Verwendung eines Kerberos-Principal-Namens und -Kennworts für die Authentifizierung in WebSphere Application Server mit einem Kerberos-TokenVerwendung eines Kerberos-Principal-Namens und -Kennworts für die Authentifizierung in WebSphere Application Server mit einem Kerberos-Token
In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:
  1. Der Client ruft das Kerberos-Granting-Ticket (TGT) vom KDC ab.
  2. Der Client ruft über das TGT ein Kerberos-Serviceticket für server1 (TGS_REQ) ab.
  3. Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an server1 gesendet.
  4. 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.
  5. Optional kann ein angepasstes JAAS-Anmeldemodul erforderlich sein, wenn das KDC und WebSphere Application Server nicht dieselbe Benutzerregistry verwenden.
  6. Der Benutzer wird über die WAS-Benutzerregistry validiert.
  7. Die Ergebnisse werden an den Client zurückgegeben.

In der folgenden Abbildung wird die Kommunikation zwischen Servern gezeigt:

Abbildung 5. Kommunikation zwischen ServernWenn 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.

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:

  1. WebSphere Application Server 1 ruft eine Methode "foo()" in einer Enterprise JavaBeans (EJB) auf, die in WebSphere Application Server 2 ausgeführt wird.
  2. Server1 ruft über das TGT für Server1 ein Kerberos-Serviceticket für Server2 (TGS_REQ) ab.
  3. Identisch mit Schritt 2.
  4. Das vom KDC zurückgegebene Kerberos-Token (TGS_REP) wird dem CSIv2-Nachrichtenauthentifizierungstoken hinzugefügt und zur Authentifizierung an Server2 gesendet.
  5. 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.
  6. Die Server-ID wird über die WebSphere-Benutzerregistry validiert.
Fehler vermeiden Fehler vermeiden: Wenn eine Java-Clientanwendung und der Anwendungsserver auf derselben Maschine installiert sind und verschiedene Namen für Kerberos-Realms verwenden, verwendet die Laufzeit den Standardrealmnamen aus der Kerberos-Konfigurationsdatei. Alternativ dazu können Sie den Realmnamen während des Anmeldeprozesses angeben. gotcha

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.

Für End-to-End-Kerberos- und End-to-End-SPNEGO-Kerberos-Lösungen müssen jedoch folgende Bedingungen erfüllt sein:
  • 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.

    [z/OS]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.
Anmerkung: Die Uhren der Client-, WAS- und KDC-Maschinen müssen synchronisiert bleiben. Die empfohlene Methode ist die Verwendung eines Zeitservers, um alle Systeme zu synchronisieren.
Für dieses Release von WebSphere Application Server müssen Sie Folgendes beachten:
  • 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

Die folgenden Szenarien werden unterstützt:
  • Anerkennung externer Domänen, die sich nicht in derselben Gesamtstruktur befinden
  • Anerkennung von Domänen in derselben Gesamtstruktur
  • Anerkennung von Kerberos-Realms
Die folgenden Szenarien werden nicht unterstützt:
  • Strukturübergreifende Anerkennung
  • Anerkennung externer Gesamtstrukturen

Kerberos als Authentifizierungsverfahren für WebSphere Application Server konfigurieren

Sie müssen die Schritte in der im Artikel Kerberos als Authentifizierungsverfahren für WebSphere Application Server konfigurieren aufgelisteten Reihenfolge ausführen, um Kerberos als Authentifizierungsverfahren für WebSphere Application Server zu konfigurieren.
Anmerkung: Die Konfiguration der Kerberos-Authentifizierung auf Serverseite muss vom Systemadministrator und auf Java-Clientseite von Benutzern vorgenommen werden. Die Kerberos-Chiffrierschlüsseldatei muss geschützt werden.

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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_kerb_auth_explain
Dateiname:csec_kerb_auth_explain.html