Zusicherung der Identität an den nachgeschalteten Server

Wenn ein Client sich an einem Server authentifiziert, wird der empfangene Berechtigungsnachweis festgelegt. Wenn die Berechtigungsengine den Berechtigungsnachweis prüft, um festzustellen, ob der Zugriff zulässig ist, definiert sie auch den Aufrufberechtigungsnachweis. Zusicherung der Identität ist der Aufrufberechtigungsnachweis, der dem nachgeschalteten Server (oder Downstream-Server) zugesichert wird.

Wenn ein Client sich an einem Server authentifiziert, wird der empfangene Berechtigungsnachweis festgelegt. Wenn die Berechtigungsengine den Berechtigungsnachweis prüft, um festzustellen, ob der Zugriff zulässig ist, legt sie auch den Aufrufberechtigungsnachweis fest. Wenn die EJB-Methode (JavaBeans) eine andere EJB-Methode auf anderen Servern aufruft, kann der Aufrufberechtigungsnachweis als Identität verwendet werden, unter der die nachfolgende Methode aufgerufen wird. Je nach RunAs-Modus für die Enterprise-Beans wird der Aufrufberechtigungsnachweis als ursprüngliche Clientidentität, als Serveridentität oder als angegebene andere Identität festgelegt. Unabhängig von der Identität, die beim Aktivieren der Identitätszusicherung festgelegt wird, wird der Aufrufberechtigungsnachweis dem nachgeschalteten Server zugesichert.

[AIX Solaris HP-UX Linux Windows][IBM i]Die Identität des Aufrufberechtigungsnachweises wird an den nachgeschalteten Server in einem Identitätstoken gesendet. Außerdem wird die ID des sendenden Servers einschließlich Kennwort oder Token im Clientauthentifizierungstoken gesendet, wenn die Basisauthentifizierung aktiviert ist. Die ID des sendenden Servers wird durch eine SSL-Authentifizierung mit Clientzertifikat gesendet, wenn die Authentifizierung mit Clientzertifikat aktiviert ist. Die Basisauthentifizierung hat Vorrang vor der Authentifizierung mit Clientzertifikat.

Der empfangende Server benötigt beide ID-Token, damit er die zugesicherte Identität akzeptieren kann. Der empfangende Server führt folgende Schritte durch, damit er die zugesicherte Identität akzeptieren kann:
  • Die Identität des sendenden Servers, die an den empfangenden Server gesendet wird, ist entweder ein GSSUP-Token (Benutzer-ID und Kennwort) oder ein SSL-Clientzertifikat. Unter z/OS, wird die ID der gestarteten MVS-Task anstelle des GSSUP-Tokens gesendet, wenn als aktive Benutzerregistry das lokale Betriebssystem verwendet wird und die SAF-Berechtigung aktiviert ist.
  • Je nach gesendeter Identität wird zwischen dem sendenden und dem empfangenden Server eine Vertrauensbeziehung hergestellt.
    1. Wenn ein GGSUP-Token gesendet wird, wird die Vertrauensbeziehung hergestellt, indem sichergestellt wird, dass die Identität des sendenden Servers in der Liste der vertrauenswürdigen Principals des empfangenden Servers enthalten ist.
    2. Wenn die ID der gestarteten MVS-Task gesendet wird, wird die Vertrauensbeziehung hergestellt, indem sichergestellt wird, dass diese ID die Berechtigung UPDATE für das Profil CB.BIND.<Servername> in der SAF-Datenbank hat.
    3. Wenn ein SSL-Clientzertifikat gesendet wird, wird dieses Clientzertifikat unter z/OS einer SAF-Benutzer-ID (Service Access Facility) zugeordnet. Die Vertrauensbeziehung wird dadurch hergestellt, indem sichergestellt wird, dass diese Benutzer-ID die Berechtigung UPDATE für das Profil CB.BIND.<Servername> hat.
  • Sobald festgestellt wurde, dass der sendende Server in der Liste der als vertrauenswürdig eingestuften Server aufgeführt ist, authentifiziert der Server den sendenden Server, um dessen Identität sicherzustellen.
  • Bei der Serverauthentifizierung werden Benutzer-ID und Kennwort des sendenden Servers mit den Daten des empfangenden Servers verglichen. Wenn die Berechtigungsnachweise des sendenden Servers authentifiziert und als vertrauenswürdig eingestuft sind, fährt der Server mit der Prüfung des Identitätstokens fort.
  • Der empfangende Server prüft, ob die zugesicherte Benutzer-ID in seiner definierten Benutzerregistry enthalten ist, um weitere Berechtigungsinformationen abzurufen (z. B. die Zugehörigkeit zu Gruppen). Daher muss die Benutzerregistry des empfangenden Servers alle zugesicherten Benutzer-IDs enthalten. Andernfalls ist keine Identitätszusicherung möglich. Auf einem Stateful-Server wird diese Aktion einmal für das Paar von sendendem und empfangendem Server ausgeführt, dessen Identitätstoken identisch sind. Nachfolgende Anforderungen werden über eine Sitzungs-ID durchgeführt.
    Anmerkung: Wenn der nachgeschaltete Server keine Benutzerregistry mit Zugriff auf die zugesicherten Benutzer-IDs im Repository enthält, sollten Sie die Identitätszusicherung nicht verwenden, weil die Berechtigungsprüfung in diesem Fall scheitert. Wird die Identitätszusicherung inaktiviert, sind Berechtigungsprüfungen im empfangenden Server nicht erforderlich.

[z/OS]Der Zielserver validiert die Berechtigung des sendenden Servers, um anhand des Clientzertifikats die Identität zuzusichern. Das Clientzertifikat wird mithilfe von RACDCERT-MAP-Filtern oder den in der SAF-Datenbank definierten RACMAP-Filtern einer SAF-Benutzer-ID (Service Access Facility) zugeordnet. Die SAF-Benutzer-ID muss Aktualisierungsberechtigung (UPDATE) für das Profil "CB.BIND.<optionSAFProfilePrefix>.Kurzname_des_Clusters" in der Klasse CBIND haben. Wenn kein Clientzertifikat gesendet wird, wird die CBIND-Prüfung anhand der ID der gestarteten Task des sendenden Servers durchgeführt.

Bei der Prüfung des Identitätstokens werden die folgenden vier Identitätsformate ausgewertet, die in einem solchen Token vorhanden sind:
  • Principal-Name
  • Definierter Name (DN)
  • Zertifikatkette
  • Anonyme Identität
Die Produktserver, die die Authentifizierungsdaten empfangen, unterstützen normalerweise alle vier Identitätstypen. Der sendende Server legt fest, welcher Typ ausgewählt wird. Dabei orientiert er sich am authentifizierten Ursprungs-Client. Der vorhandene Typ ist davon abhängig, wie der Client sich ursprünglich beim sendenden Server authentifiziert hat. Wenn der Client z. B. die SSL-Clientauthentifizierung verwendet, um sich am sendenden Server zu authentifizieren, enthält das Identitätstoken, das an den nachgeschalteten Server gesendet wird, die Zertifikatskette. Mit diesen Informationen ist der empfangende Server in der Lage, die Zertifikatkette selbst abzugleichen. Außerdem ist die Interoperabilität mit anderen Anbietern und Plattformen höher.

Wenn das Identitätsformat erfasst und syntaktisch analysiert wurde, wird die Identität einem Berechtigungsnachweis zugeordnet. Das Identitätstoken ITTPrincipal wird den Feldern für die Benutzer-IDs eins zu eins zugeordnet.

[AIX Solaris HP-UX Linux Windows][IBM i]Bei ITTDistinguishedName-Identitätstoken ist die Zuordnung von der Benutzerregistry abhängig. Bei LDAP (Lightweight Directory Access Protocol) legt der konfigurierte Suchfilter fest, wie die Zuordnung durchgeführt wird. Beim Authentifizierungsverfahren LocalOS wird das erste Attribut des definierten Namens (DN), der in der Regel mit dem allgemeinen Namen identisch ist, der Benutzer-ID der Registry zugeordnet.

[z/OS]ITTDistinguishedName-Identitätstoken und ITTCertChain-Identitätstoken werden auf dieselbe Weise zugeordnet. Beide Arten von Identitätstoken verwenden ein Zertifikat, das mit RACDCERT oder einer entsprechenden Zuordnungsfunktion einer SAF-Benutzer-ID zugeordnet wird. Die Zuordnung kann auf dem Subjektnamen oder Ausstellernamen basieren.

[AIX Solaris HP-UX Linux Windows][IBM i]Die Zusicherung der Identität ist nur bei Verwendung des Protokolls Common Secure Interoperability Version 2 (CSIv2) verfügbar.

Anmerkung: Bei der Verwendung der Identitätszusicherung mit KRB-Token an nachgeschaltete Server ist eine Einschränkung zu beachten. Wenn Sie die Identitätszusicherung mit aktiviertem Kerberos-Mechanismus verwenden, hat die Identitätszusicherung bei der Weiterleitung an nachgeschaltete Server kein Kerberos-Authentifizierungstoken (KRBAuthnToken). Sie verwendet stattdessen LTPA für die Authentifizierung.

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_csiv2ida
Dateiname:csec_csiv2ida.html