WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Identitätsabgleich

Beim Identitätsabgleich handelt es sich um die Konvertierung eines Sicherheitstokens aus dem einen Format in ein anderes Format bzw. die Einbindung einer Identität aus einem Realm in eine entsprechende Identität in einem anderen Realm.

Diagramm zur Darstellung des Identitätsabgleichs

WebSphere Message Broker bietet Unterstützung für den Identitätsabgleich (auch als Verknüpfung von Identitäten bezeichnet) sowie für die Ausgabe und den Austausch von Token. Beim Identitätsabgleich wird eine Identität in einem Realm mit einer anderen Identität in einem anderen Realm abgeglichen. So könnte beispielsweise User001 aus dem Realm 'eSellers' mit eSellerUser01 im Realm 'eShipping' abgeglichen werden. Die Ausgabe und der Austausch von Token umfassen den Abgleich eines Tokens eines bestimmten Typs mit einem Token eines anderen Typs. So könnte beispielsweise ein über MQ eingehender Token 'Benutzername und Kennwort' von einem Client mit einer äquivalenten SAML-Zusicherung abgeglichen werden, die an einen Web-Service-Aufruf weitergegeben werden soll. Alternativ dazu könnte auch eine SAML 1.1-Zusicherung von einer Clientanwendung gegen eine äquivalente SAML 2.0-Zusicherung für einen aktualisierten Back-End-Server ausgetauscht werden.

Zuordnung unter Verwendung eines WS-Trust-Providers

Der WebSphere Message Broker-Sicherheitsmanager unterstützt die Zuordnung von Operationen Security Token Server (STS), die auf WS-Trust V1.3 basieren, wie beispielsweise IBM® Tivoli Federated Identity Manager (TFIM) V6.2. Die Zuordnung erfolgt für SecurityPEP-Knoten und Empfangsknoten, denen ein Sicherheitsprofil zugeordnet ist, welches eine Abgleichoperation umfasst, die mit einem WS-Trust V1.3 STS konfiguriert ist.

WS-Trust V1.3 (TFIM V6.2) kann ebenfalls für die Authentifizierung und Autorisierung im Profil ausgewählt sein. Wenn dem Sicherheitsprofil jedoch mehr als nur eine Sicherheitsoperation zugeordnet ist, wird dem STS nur eine WS-Trust-Anforderung ausgestellt. Folglich muss der STS für die Ausführung aller erforderlichen Operationen konfiguriert sein. Wird beispielsweise ein TFIM-V6.2-Server angegeben, muss die TFIM-Modulkette, die aufgerufen wird, die entsprechenden Auswertungs-, Autorisierungs- und Ausstellungsmodule enthalten. Wenn jede Operation über einen separaten WS-Trust-Aufruf ausgeführt werden muss, müssen Sie eine Reihe von SecurityPEP-Knoten verwenden, von denen jeder einem anderen Sicherheitsprofil zugeordnet ist, das für nur eine Sicherheitsoperation konfiguriert ist (Authentifizierung, Autorisierung oder Zuordnung).

Wenn das Sicherheitsprofil nur die Zuordnung mit WS-Trust v1.3 STS festlegt, wird die Anforderung mit dem Anforderungstyp Issue (Ausstellen) gesendet; bei einer gemischten Gruppe von Sicherheitsoperationen hingegen wird der Anforderungstyp Validate (Auswerten) gesendet. Ist die Zuordnung enthalten, muss der STS in seiner Antwort ein Token liefern, selbst wenn es sich dabei um das ursprüngliche Token handelt; andernfalls tritt ein Fehler auf.

Damit die Kompatibilität mit früheren Versionen von WebSphere Message Broker gewährleistet ist, wird auch TFIM V6.1 unterstützt.

Im Broker werden Identitätsabgleiche im Empfangsknoten oder SecurityPEP-Knoten nach der Authentifizierung, aber vor der Autorisierung durchgeführt. Die Quellenidentität wird zur Verarbeitung an eine Identitätszuordnungsfunktion übergeben. Sind sowohl Zuordnung als auch Autorisierung konfiguriert, nutzt die Autorisierungsoperation das zugeordnete Ausgabetoken anstelle des Quellentokens. Dies bedeutet, dass die Autorisierung für die verknüpfte Identität erfolgt.

Zuordnungen werden nicht in Sendeknoten durchgeführt, selbst wenn der Knoten mit einem Sicherheitsprofil konfiguriert wurde.

WebSphere Message Broker unterstützt die Zuordnung zwischen allen Sicherheitstokenarten, die vom konfigurierten Sicherheitsprovider unterstützt werden. Im Abschnitt Identität finden Sie weitere Informationen zur bereitgestellten Unterstützung.

Bei der Zuordnung von einem X.509-Zertifikat kann TFIM das Zertifikat zwar prüfen, nicht aber die Identität des ursprünglichen Absenders verifizieren. Bei Bedarf kann diese Integritätsprüfung jedoch vom SOAPInput-Knoten durchgeführt werden. Der Abschnitt WS Security-Mechanismus enthält weitere Informationen hierzu.

Weitere Informationen zur Verwendung von TFIM V 6.2 zur Zuordnung finden Sie unter Authentifizierung, Zuordnung und Autorisierung mit TFIM V6.2 und TAM.

Informationen zur Verwendung von TFIM V6.1 finden Sie unter Authentifizierung, Zuordnung und Autorisierung mit TFIM V6.1 und TAM.

Benutzerdefinierte Zuordnung

Bei der Entwicklung eines Nachrichtenflusses können Sie eine benutzerdefinierte Tokenzuordnung für die Identitätsweitergabe implementieren. Sie können beispielsweise mithilfe eines Rechenknotens (ein Compute-, JavaCompute- oder PHPCompute-Knoten) hinter dem Empfangsknoten eine benutzerdefinierte Tokenzuordnung implementieren. Im Rechenknoten können die Quellenidentitätswerte aus dem Eigenschaftsordner ausgelesen und verarbeitet werden. Anschließend werden die neuen Identitätswerte in die Felder für die zugeordnete Identität geschrieben. Ist in der Nachricht keine Identität enthalten, können Sie trotzdem mithilfe eines Rechenknoten einige Identitätsberechtigungsnachweise in die Felder für zugeordnete Identitätswerte einfügen. Von den nachfolgenden Knoten werden dann die Felder für zugeordnete Identitätswerte anstatt der Felder mit den Quellenidentitätswerten verwendet. Alle im Empfangsknoten konfigurierten Sicherheitsoperationen werden unter Verwendung der Quellenidentitätswerte ausgeführt, bevor Sie mithilfe des Rechenknotens eine neue Identität in den Feldern für zugeordnete Identitätswerte erstellen können. Nachdem vom Rechenknoten eine neue zugeordnete Identität erstellt wurde, können Sie jedoch einen SecurityPEP-Knoten einfügen.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:21:53


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ap04030_