Eingehende Kommunikation bezieht sich auf die Konfiguration, die festlegt, welche Art der Authentifizierung
für eingehende Anforderungen akzeptiert wird.
Diese Authentifizierung wird in der Internet Object Reference (IOR) empfohlen, die der Client aus dem Servernamen abruft.
Vorgehensweise
- Starten Sie die Administrationskonsole.
- Klicken Sie auf Sicherheit > Globale Sicherheit.
- Klicken Sie unter "RMI/IIOP-Sicherheit" auf Eingehende CSIv2-Kommunikation.
- Berücksichtigen Sie die folgenden Sicherheitsebenen:
- Zusicherung der Identität (Attributschicht).
Ist diese Option ausgewählt, akzeptiert der Server Identitätstoken
von übergeordneten Servern. Empfängt der Server ein Identitätstoken, stammt dieses von einem
Ursprungsclient und hat beispielsweise genau das Format, wie es der Ursprungsclient dem ersten
Server vorgelegt hat. Ein übergeordneter Server sendet die ID des Ursprungsclient. Die ID kann in Form eines Principal-Namens,
eines definierten Namens oder einer Zertifikatkette vorliegen. In einigen Fällen ist die Identität auch anonym. Es ist wichtig, dass
der übergeordnete Server, der das Identitätstoken sendet, vertrauenswürdig ist, da die ID auf diesem Server nicht authentifiziert
wird. Das Vertrauen zum übergeordneten Server wird entweder durch eine Authentifizierung mittels SSL-Clientzertifikat
oder durch eine Basisauthentifizierung hergestellt. Sie müssen eine der beiden Ebenen
für die Authentifizierung eingehender und abgehender Anforderungen auswählen, wenn Sie sich für die
Zusicherung der Identität entscheiden.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Die Server-ID wird zusammen mit den Identitätstoken im Clientauthentifizierungstoken
gesendet. Es wird geprüft, ob die Server-ID in der Liste der vertrauenswürdigen Server-IDs enthalten ist. Ist die Server-ID in der Liste enthalten, wird
sie authentifiziert. Wenn die Server-ID gültig ist, wird das Identitätstoken in einem Berechtigungsnachweis gespeichert und
für die Berechtigung der Anforderung verwendet.
![[z/OS]](../images/ngzos.gif)
Anmerkung: Wenn Ihre
konfigurierte Registry ein lokales Betriebssystem ist, wird das Vertrauen
stattdessen hergestellt indem geprüft wird, ob die Identität des vorgeschalteten (Upstream-)Servers
auf dem nachgeschalteten (Downstream-)Server mit der Berechtigung UPDATE für die Klasse
CBIND und das Profil CB.BIND.<optionales_SAF-Profilpräfix>.<Kurzname_des_Clusters> berechtigt ist.
Die ID des Upstream-Servers wird in einem SSL-Clientzertifikat gesendet.
Sollte SSL nicht verwendet
werden, wird die CBIND-Prüfung für die ID der gestarteten Task des Upstream-Servers durchgeführt.
Fehler vermeiden: Wenn die Zusicherung der Identität aktiviert ist, sollte außerdem die Nachrichtebene oder Transportebene
aktiviert sein. Für die Kommunikation zwischen Servern sollte neben der Aktivierung der Transportebene bzw. der Clientauthentifizierung
auch die Zusicherung der Identität oder die Nachrichtenebene aktiviert sein.
gotcha
Weitere Informationen finden Sie unter
Identitätszusicherung.
- Nachrichtebene:
Basisauthentifizierung (GSSUP):
Diese Art der Authentifizierung ist am weitesten
verbreitet. Die Benutzer-ID und das Kennwort oder das authentifizierte Token wird von einem reinen Client oder von
einem übergeordneten Server gesendet. Wenn der Server eine Benutzer-ID mit Kennwort empfängt, wird diese anhand der Benutzerregistry des Downstream-Servers
authentifiziert.
Lightweight
Third Party Authentication (LTPA):
In diesem Fall wird vom Upstream-Server ein LTPA-Token
gesendet. Bei Auswahl von LTPA müssen beide Server dieselben LTPA-Schlüssel verwenden.
Kerberos (KRB5):
Wenn Sie Kerberos auswählen möchten, muss Kerberos das aktive Authentifizierungsverfahren sein.
In diesem Fall wird vom Upstream-Server ein Kerberos-Token
gesendet.
Weitere Informationen finden Sie im Artikel zur
Authentifizierung auf Nachrichtenebene.
- SSL-Authentifizierung mit Clientzertifikat (Transportschicht).
Das
SSL-Clientzertifikat wird anstelle von Benutzer-ID und Kennwort für die Authentifizierung
verwendet. Wenn ein Server eine ID
an einen untergeordneten Server delegiert, stammt diese aus der Nachrichtenschicht (Clientauthentifizierungstoken) oder
aus der Attributschicht (Identitätstoken) und nicht aus der Transportschicht (Authentifizierung mit Clientzertifikat).
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Ein
Client hat ein SSL-Clientzertifikat, das in der Keystore-Datei der Clientkonfiguration gespeichert ist. Wenn auf diesem Server die
SSL-Clientauthentifizierung aktiviert ist, fordert er den Client auf, das Zertifikat zu senden, wenn die Verbindung
aufgebaut ist. Das Zertifikat ist immer am Socket verfügbar, wenn eine Anforderung an den
Server gesendet wird. Der Request Interceptor des Servers empfängt die Zertifikatkette vom Socket und ordnet sie einem Benutzer
in der Benutzerregistry zu. Diese Art der Authentifizierung ist optimal für die direkte Kommunikation zwischen einem Client und einem
Server. Bei der Authentifizierung gegenüber untergeordneten Systemen wird die Identität normalerweise über die Nachrichtenschicht oder
über die Zusicherung der Identität weitergeleitet.
Ein
Client hat ein SSL-Clientzertifikat, das in der Schlüsselringdatei der Clientkonfiguration gespeichert ist.
Wenn auf diesem Server die
SSL-Clientauthentifizierung aktiviert ist, fordert er den Client auf, das Zertifikat zu senden, wenn die Verbindung
aufgebaut ist. Das Zertifikat ist immer am Socket verfügbar, wenn eine Anforderung an den
Server gesendet wird. Der Request Interceptor des Servers empfängt die Zertifikatkette vom Socket und ordnet sie einem Benutzer
in der Benutzerregistry zu. Diese Art der Authentifizierung ist optimal für die direkte Kommunikation zwischen einem Client und einem
Server. Bei der Authentifizierung gegenüber untergeordneten Systemen wird die Identität normalerweise über die Nachrichtenschicht oder
über die Zusicherung der Identität weitergeleitet.
- Berücksichtigen Sie bei Ihrer Entscheidung, welche Arten von Authentifizierung zu akzeptieren sind, folgende Punkte:
- Konfigurieren Sie eine Liste vertrauenswürdiger Server. Wenn die Zusicherung der Identität für eingehende Anforderungen ausgewählt ist, fügen Sie
eine Liste mit den Serveradministrator-IDs ein, für die dieser Server die Übertragung von Identitätstoken unterstützen kann. Verwenden Sie in der Liste
das Pipe-Zeichen (|) als Trennzeichen. Für die Abwärtskompatibilität können Sie weiterhin Kommas als Trennzeichen in der Liste verwenden. Wenn
die Server-ID jedoch ein definierter Name (DN) ist, müssen Sie in der Liste das Pipe-Zeichen (|)
verwenden, weil hier das Komma als Trennzeichen nicht funktioniert. Falls Sie allen Servern erlauben, ein Identitätstoken
zu senden, können Sie in diesem Feld einen Stern (*) eingeben. Eine solche Einstellung kommt einem vorausgesetzten
Vertrauensverhältnis
gleich. Verwenden Sie in diesem Fall die SSL-Authentifizierung mit Clientzertifikat, um das Vertrauen zwischen Servern
herzustellen.
Unterstützte Konfigurationen: Dieser Schritt ist anwendbar, wenn Sie
eine LDAP- (Lightweight Directory Access Protocol) oder eine angepasste Benutzerregistry verwenden.
Er ist jedoch nicht anwendbar, wenn Sie die Benutzerregistry des lokalen Betriebssystems oder
eine SAF-Benutzerregistry (System Authorization Facility) verwenden.
sptcfg
- Konfigurieren Sie die Sitzungsverwaltung. Sie können die Stateful- oder die Stateless-Sicherheit auswählen.
Der Durchsatz ist optimal, wenn Sie
Stateful-Sitzungen ausgewählt haben. In diesem Fall wird die erste Methodenanforderung zwischen
einem Client und dem Server authentifiziert. Alle folgenden Anforderungen
verwenden die Sitzungsinformationen einschließlich des Berechtigungsnachweises erneut (bis das Berechtigungsnachweistoken abgelaufen ist). Ein Client sendet für
alle nachfolgenden Anforderungen eine Kontext-ID. Die Kontext-ID wird der Verbindung
zugeordnet, wodurch die Verbindung eine eindeutige Kennung erhält.
Ergebnisse
Wenn Sie die Felder dieser Anzeige ausgefüllt haben, sind die meisten Informationen konfiguriert, auf
deren Grundlage ein Client entscheidet, was an diesen Server gesendet werden soll. Die Konfiguration für abgehende Verbindungen eines Client oder Servers
bestimmt im Zusammenhang mit der Konfiguration für eingehende Verbindungen dieses Servers
die Art der angewendeten Sicherheit. Wenn Sie wissen, was Clients senden, ist die Konfiguration einfach. Falls die Clients jedoch voneinander
unabhängig sind und unterschiedliche Sicherheitsanforderungen haben, müssen Ihre Server verschiedene Authentifizierungsschichten
in Betracht ziehen.
Für einen Java EE-Anwendungsserver (Java Platform, Enterprise Edition) wird normalerweise die Authentifizierung über Zusicherung der Identität oder
über die Nachrichtenschicht verwendet. Der Grund dafür ist, dass die Identität des Ursprungsclient
a ein untergeordnetes System delegiert werden soll. Ein Clientzertifikat kann nicht so einfach über eine SSL-Verbindung
delegiert werden. Für eine zusätzliche Serversicherheit können Sie die Transportschicht aktivieren.
Der durch das Clientzertifikat beim SSL-Handshake entstehende zusätzliche Aufwand kann im Rahmen des Gesamtaufwands für den Aufbau
der SSL-Verbindung vernachlässigt werden.
Nächste Schritte
Sobald Sie wissen, welche Art von Authentifizierungsdaten dieser Server empfangen wird, können Sie
die Option für die Sicherheit abgehender Verbindungen festlegen. Weitere Informationen finden Sie im Artikel
Abgehende Authentifizierung gemäß
Common Secure Interoperability Version 2 konfigurieren.