Eingehende CSIv2-Kommunikation konfigurieren

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

  1. Starten Sie die Administrationskonsole.
  2. Klicken Sie auf Sicherheit > Globale Sicherheit.
  3. Klicken Sie unter "RMI/IIOP-Sicherheit" auf Eingehende CSIv2-Kommunikation.
  4. 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][IBM i]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]
      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 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][IBM i]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.

      [z/OS]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.

  5. Berücksichtigen Sie bei Ihrer Entscheidung, welche Arten von Authentifizierung zu akzeptieren sind, folgende Punkte:
    • Ein Server kann mehrere Schichten parallel empfangen. Eine Ausführungspriorität entscheidet darüber, welche Schicht verwendet wird. Die Schicht mit Zusicherung der Identität hat die höchste Priorität. Die zweithöchste Priorität hat die Nachrichtenschicht und die Transportschicht ist die Schicht mit der niedrigsten Priorität. Die Authentifizierung mit SSL-Clientzertifikaten wird verwendet, wenn keine andere Schicht verfügbar ist. Stehen die Nachrichten- und Transportschicht zur Verfügung, wird die zu autorisierende Identität aus der Nachrichtenschicht verwendet. Die Schicht mit Zusicherung der Identität hat Vorrangstellung, sofern sie verfügbar ist.
    • Empfängt der Server Anforderungen von einem Client, von einem Server oder von beiden? Wenn der Server immer Anforderungen von einem Client empfängt, ist die Zusicherung der Identität nicht notwendig. Sie können in diesem Fall die Nachrichtenschicht oder die Transportschicht oder beide Schichten wählen. Außerdem können Sie entscheiden, ob die Authentifizierung erforderlich ist oder unterstützt werden soll. Wenn Sie eine Schicht als erforderlich auswählen möchten, muss der sendende Client diese Schicht bereitstellen, da andernfalls die Anforderung zurückgewiesen wird. Soll die Schicht nur unterstützt werden, kann sie bereitgestellt werden, muss es jedoch nicht.
    • Welche Art von Client-ID wird bereitgestellt? Wenn die Client-ID in Clientzertifikaten enthalten ist und die Zertifikatkette an den untergeordneten Server gesendet werden soll, wo sie den Benutzerregistrys zugeordnet wird, ist die Zusicherung der Identität die richtige Wahl. Bei der Zusicherung der Identität bleibt das vom Ursprungsclient verwendete Format erhalten. Wenn sich der Ursprungsclient mit Benutzer-ID und Kennwort authentifiziert hat, wird eine Principal-ID gesendet. Wurde für die Authentifizierung ein Zertifikat verwendet, wird die Zertifikatkette gesendet.

      [AIX Solaris HP-UX Linux Windows][IBM i]Wenn der Client mit einem Token authentifiziert wird und der LDAP-Server die Benutzerregistry ist, wird in manchen Fällen ein definierter Name (DN) gesendet.

  6. 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 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
  7. 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.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



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