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:
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.
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:
Das Token wird aus einem der folgenden Transportheader entnommen:
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 |
Die Extraktion von Benutzernamens- und Kennworttoken wird von den folgenden Knoten unterstützt:
Das Token wird aus einem der folgenden Transportheader entnommen:
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:
|
SAML-Zusicherung | Die Extraktion von SAML-Token wird von den folgenden Knoten unterstützt:
Das Token wird aus den folgenden Stellen entnommen:
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):
|
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:
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):
|
LTPA-V2-Token | Die Extraktion von LTPA-Token wird von den folgenden 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 LTPA. |
WS-Trust V1.3 STS (einschließlich TFIM V6.2):
|
X.509-Zertifikat | Die Extraktion von X.509-Token wird von den folgenden Knoten unterstützt:
Das Token wird aus den folgenden Stellen entnommen:
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:
|
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):
|
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.
-- 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.