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.
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.
- 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.
- 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.
- 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.
- 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.
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.
- Principal-Name
- Definierter Name (DN)
- Zertifikatkette
- Anonyme Identität
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.
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.
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.
Die Zusicherung der Identität ist nur bei Verwendung
des Protokolls Common Secure Interoperability Version 2 (CSIv2) verfügbar.