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ät

In WebSphere Message Broker ist eine Identität ein Sicherheitstoken, das auf eindeutige Weise eine Einzelperson identifiziert oder eine Gruppe prüfbarer Zusicherungen bereitstellt.

Bei der Konfiguration eines SecurityPEP-Knotens oder eines unterstützten Empfangsknotens mit einem Sicherheitsprofil wird die extrahierte Identität im Broker in Form von acht Eigenschaften im Eigenschaftsordner innerhalb der Nachrichtenbaumstruktur gespeichert. Diese Eigenschaften definieren zwei Identitäten im Broker: Quellenidentität und zugeordnete Identität. Für beide Identitäten sind Werte vorhanden für die Eigenschaften Type, Token, Password und IssuedBy:

Diagramm mit Darstellung der acht Identitätseigenschaften

Die Eigenschaft Identitätstokentyp von Empfangsknoten mit aktivierter Sicherheit kann auf Transportstandard gesetzt werden; der Tokentyp wird dann aus dem Standardidentitätsheader bzw. den Standardidentitätsfeldern des Transports erstellt. Für WebSphere MQ ergibt sich bei Transportstandardwert der Identitätstyp Benutzername. Für HTTP ergibt sich bei Transportstandardwert der Identitätstyp Benutzername + Kennwort. Auf dem SecurityPEP-Knoten kann die Eigenschaft 'Identitätstokentyp' auf Aktuelles Token gesetzt werden; dadurch kann die Identität in den Feldern des Ordners 'Eigenschaften' verwendet werden, anstatt dass eine neue Identität aus der Nachricht extrahiert werden muss.

In der folgenden Tabelle ist aufgeführt, wie der Sicherheitsmanager für Nachrichtenflüsse und die externen Sicherheitsprovider die Extraktion verschiedener Sicherheitstokentypen unterstützen. Informationen zu den Tokentypen, die für die Weitergabe von Identitäten unterstützt werden, finden Sie im Abschnitt Weitergabe der Identitäts- und Sicherheitstoken.

Tabelle 1. Unterstützung für verschiedene Arten von Sicherheitstoken - Extraktion der Token
Art des Tokens (Format) Unterstützung für die Tokenextraktion durch Sicherheitsmanager des Brokers Unterstützung durch externen Sicherheitsanbieter
Benutzername Die Extraktion von Benutzernamenstoken wird von den folgenden Knoten unterstützt:
  • HTTPInput
  • MQInput
  • SCAInput
  • SCAAsyncResponse
  • SecurityPEP
  • SOAPInput
Das Token wird aus einem der folgenden Transportheader entnommen:
  • MQ
    • Aus MQMD-Benutzer-ID
  • HTTP
    • Aus dem HTTP-BasicAuth-Header, der nur einen Benutzernamensteil enthält
  • SOAP
    • Aus einem WS-Security-UsernameToken-Header. Im Richtliniensatz und in der Richtlinienbindung (dem SOAP-Knoten zugeordnet) muss ein Benutzernamensprofil definiert sein und 'wsse:UsernameToken' darf nur das Element wsse:Username enthalten.
    • Aus dem Kerberos-Subjekt in einem WS-Security-Header. Im Richtliniensatz und in der Richtlinienbindung (die einem SOAP-Knoten zugeordnet sind) muss ein Kerberos-Profil definiert sein.
    • Aus dem HTTP-BasicAuth-Header, der nur einen Benutzernamensteil enthält, wenn kein Richtliniensatz auf dem SOAP-Knoten definiert ist.
Das Token kann auch aus einem beliebigen Teil der Nachrichtenbaumstruktur entnommen werden, wenn die Tokenposition (auf dem Knoten) mit einem XPath-Ausdruck oder einem ESQL-Feldpfad angegeben wird.

Die die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java™-Programm angeben können) ist Benutzername.

LDAP: Autorisierung

Benutzername und Kennwort
oder
Benutzername und RACF-PassTicket

Die Extraktion von Benutzernamens- und Kennworttoken wird von den folgenden Knoten unterstützt:
  • HTTPInput
  • MQInput
  • SCAInput
  • SecurityPEP
  • SCAAsyncResponse
  • SOAPInput
Das Token wird aus einem der folgenden Transportheader entnommen:
  • HTTP
    • Aus dem HTTP-BasicAuth-Header, der einen Benutzernamens- und einen Kennwortteil enthält
  • SOAP
    • Aus einem WS-Security-UsernameToken-Header. Im Richtliniensatz und in der Richtlinienbindung (dem SOAP-Knoten zugeordnet) muss ein Benutzernamensprofil definiert sein und 'wsse:UsernameToken' muss die Elemente wsse:Username und wsse:Password enthalten.
    • Aus dem HTTP-BasicAuth-Header, der nur einen Benutzernamensteil enthält, wenn kein Richtliniensatz auf dem SOAP-Knoten definiert ist
Das Token kann auch aus einem beliebigen Teil der Nachrichtenbaumstruktur entnommen werden, wenn die Tokenposition (auf dem Knoten) mit einem XPath-Ausdruck oder einem ESQL-Pfad angegeben wird.

Bei dem Kennworttoken kann es sich entweder um ein Kennwort im Klartext oder um ein RACF-PassTicket handeln. Bei Verwendung eines WS-Trust V1.3 STS (z. B. TFIM V6.2) können Sie RACF-PassTickets zuordnen (ausgeben) oder auswerten, indem Sie den Tokentyp als Benutzername + Kennwort angeben. Dies wird unterstützt bei Empfangsknoten und SecurityPEP-Knoten, auf denen die Sicherheit aktiviert ist.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist usernameAndPassword (Benutzername + Kennwort).

LDAP:
  • Authentifizierung
  • Berechtigung
TFIM V6.1:
  • Authentifizierung
  • Zuordnung
  • Berechtigung
WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Berechtigung
SAML-Zusicherung Die Extraktion von SAML-Token wird von den folgenden Knoten unterstützt:
  • SecurityPEP
  • MQInput
  • HTTPInput
  • SCAInput
  • SCAAsyncResponse
  • SOAPInput
Das Token wird aus den folgenden Stellen entnommen:
  • SOAP
    • Aus einem WS-Security-Header. Im Richtliniensatz und in der Richtlinienbindung (dem SOAP-Knoten zugeordnet) muss ein SAML-Profil definiert sein.
  • Aus einem beliebigen Bereich der Nachrichtenbaumstruktur, wenn die Token-Adresse mit einem XPath-Ausdruck oder ESQL-Pfad angegeben wird.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist SAML.

WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Berechtigung
Kerberos GSS V5 AP_REQ Die Verarbeitung von Kerberos-Tickets wird vom Sicherheitsmanager für Nachrichtenflüsse des SecurityPEP-Knotens unterstützt. Folgende SOAP-Knoten unterstützen ein WS-Security-Kerberos-Tokenprofil, allerdings erfolgt die Kommunikation mit dem Kerberos-Key-Distribution-Center direkt und der Ordner "Eigenschaften" wird mit einem Benutzernamenstoken gefüllt, das das Kerberos-Subjekt darstellt:
  • SOAPInput

Das Token wird aus der Nachrichtenbaumstruktur in einem SecurityPEP-Knoten entnommen, wenn die Position des Tokens über einen XPath-Ausdruck oder einen ESQL-Pfad angegeben wurde.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist kerberosTicket.

WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Berechtigung
LTPA-V2-Token Die Extraktion von LTPA-Token wird von den folgenden Knoten unterstützt:
  • SecurityPEP
  • SOAPInput

Das Token wird aus der Nachrichtenbaumstruktur in einem SecurityPEP-Knoten entnommen, wenn die Position des Tokens über einen XPath-Ausdruck oder einen ESQL-Pfad angegeben wurde.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist LTPA.

WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Berechtigung
X.509-Zertifikat Die Extraktion von X.509-Token wird von den folgenden Knoten unterstützt:
  • SecurityPEP
  • MQInput
  • HTTPInput
  • SCAInput
  • SCAAsyncResponse
  • SOAPInput
Das Token wird aus den folgenden Stellen entnommen:
  • SOAP
    • Aus einem WS-Security-Header. Im Richtliniensatz und in der Richtlinienbindung (dem SOAP-Knoten zugeordnet) muss ein X.509-Profil definiert sein.
  • Aus einem beliebigen Bereich der Nachrichtenbaumstruktur, wenn die Token-Adresse mit einem XPath-Ausdruck oder ESQL-Pfad angegeben wird.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist X.509.

TFIM V6.1:
  • Authentifizierung
  • Zuordnung
  • Autorisierung.
WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Autorisierung.
Universal WSSE-Token Die Extraktion von Universal WSSE-Token wird nur vom SecurityPEP-Knoten unterstützt.

Das Token wird aus der Nachrichtenbaumstruktur in einem SecurityPEP-Knoten entnommen, wenn die Position des Tokens über einen XPath-Ausdruck oder einen ESQL-Pfad angegeben wurde.

Die vom Broker verwendete Literalzeichenfolge (mit der Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) ist UniversalWsse.

WS-Trust V1.3 STS (einschließlich TFIM V6.2):
  • Authentifizierung
  • Zuordnung
  • Autorisierung.

Die Quellenidentität wird vom SecurityPEP-Knoten oder Empfangsknoten nur dann festgelegt, wenn dem Knoten ein Sicherheitsprofil zugeordnet ist. Die Daten zum Ausfüllen dieser Felder werden normalerweise den Headern einer Nachricht entnommen, können aber auch im Hauptteil stehen (sofern der Knoten mit dem Verweis 'ESQL Path' oder 'XPath' für die verschiedenen Eigenschaften konfiguriert wurde). Falls mehrere Identitäten verfügbar sind (z. B. wenn Sie das Zusammenfassen von Nachrichten verwenden), wird die erste Identität verwendet. Die Token-Extraktion ist transportspezifisch und kann nur über Transportprotokolle erfolgen, die den Fluss von Identitäten unterstützen. Dies sind: WebSphere MQ, HTTP(S) und SOAP. Weitere Informationen hierzu finden Sie unter MQInput-Knoten und HTTPInput-Knoten.

Sie können die Werte der Eigenschaften ändern (beispielsweise über ESQL), die Werte der IdentitySource*-Eigenschaften sollten allerdings nicht überschrieben werden. Sie können beispielsweise eine benutzerdefinierte Routine für den Identitätsabgleich in ESQL oder Java erstellen, indem Sie mithilfe der IdentitySource*-Werte benutzerdefinierte IdentityMapped*-Werte erstellen.

SAML- und Universal WSSE-Token werden in der Eigenschaftenbaumstruktur im Feld 'IdentitySourceToken' bzw. 'IdentityMappedToken' als Zeichenbitstrom gespeichert. Damit auf diese Daten in einer Nachrichtenbaumstruktur zugegriffen werden kann, müssen sie in einen entsprechenden Parser wie XMLNSC geparst werden :
-- Zugeordnetes SAML2.0-Token in Eigenschaftsordner parsen und im Nachrichtenhauptteil setzen
   CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(InputRoot.Properties.IdentityMappedToken, 
   InputProperties.Encoding, InputProperties.CodedCharSetId);
Um in den Eigenschaftsfeldern SAML- oder Universal WSSE-Token definieren zu können, müssen Sie beispielsweise mithilfe der ESQL-Funktion ASBITSTREAM den Bitstrom einer Baumstruktur abrufen.
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 | ap04010_