Identität

In „ IBM® App Connect Enterprise “ ist eine Identität ein Sicherheitstoken, das eine Person eindeutig identifiziert oder eine Reihe von Aussagen enthält, die überprüft werden können.

Wenn ein SecurityPEP -Knoten oder ein unterstützter Input-Knoten mit einem Sicherheitsprofil konfiguriert ist, wird die extrahierte Identität im Integrationsknoten als acht Eigenschaften im Ordner "Eigenschaften" der Nachrichtenbaumstruktur gespeichert. Diese Eigenschaften definieren zwei Identitäten im Integrationsknoten: 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 den acht Identitätseigenschaften.

Die Eigenschaft Identity token type auf den Input-Knoten mit aktivierter Sicherheit kann auf den Wert Transportstandardgesetzt werden, wodurch der Tokentyp aus dem Standardidentitätsheader oder den Feldern des Transports erstellt wird. Für WebSphere® MQgibt Transportstandard den Identitätstyp Benutzernamean. Für HTTP ergibt sich bei Transportstandardwert der Identitätstyp Benutzername + Kennwort. Die Eigenschaft "Identity token type" auf dem SecurityPEP knoten kann auf "Aktuelles Token" gesetzt werden, wodurch die Identität in den Feldern des Ordners "Eigenschaften" verwendet werden kann, anstatt eine neue Identität aus der Nachricht zu extrahieren.

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 unter Weitergabe von Identität und Sicherheitstoken.

Tabelle 1. Unterstützung für verschiedene Arten von Sicherheitstoken - Extraktion der Token
Art des Tokens (Format)	Unterstützung der Tokenextraktion durch den Sicherheitsmanager des Integrationsknotens	Unterstützung durch externen Sicherheitsanbieter
Benutzername	Die Extraktion von Benutzernamenstoken wird von den folgenden Nachrichtenflussknoten unterstützt: HTTPInput MQInput 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. Der vom Integrationsknoten verwendete Literalzeichenfolgewert (mit dem Sie den Tokentyp in einem ESQL-oder Java™ -Programm angeben können) lautet `username`.	LDAP: Berechtigung WS-Trust V1.3 STS (einschließlich TFIM V6.2): Authentifizierung Zuordnung Berechtigung Hinweis: Um die Verwendung eines Benutzernamenstokens (anstelle eines Benutzernamens-und Kennworttokens) mit diesen Sicherheitsprovidern zu verhindern, sollten Sie die Eigenschaft Reject Empty Password des Sicherheitsprofils auf `TRUE`setzen. Der Sicherheitsmanager weist dann einen Benutzernamen während der Authentifizierung zurück, wenn der Benutzername ein leeres Kennworttoken hat, und der Benutzername wird nicht mit dem externen Sicherheitsprovider authentifiziert.
Benutzername und Kennwort oder Benutzername und RACF® PassTicket	Die Extraktion von Benutzernamenstoken für Benutzername und Kennwort wird von den folgenden Nachrichtenflussknoten unterstützt: HTTPInput MQInput SecurityPEP 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. Das Kennworttoken kann entweder ein Klartextkennwort oder ein RACF PassTicketenthalten. Wenn Sie einen WS-Trust verwenden V1.3 STS (wie TFIM V6.2), können Sie damit abbilden (ausgeben) oder validieren RACF PassTickets, durch Angabe des Tokentyps als `Benutzername und Passwort`. Diese Unterstützung ist mit Input-Knoten mit aktivierter Sicherheit und SecurityPEP -Knoten verfügbar. Der vom Integrationsknoten verwendete Literalzeichenfolgenwert (mit dem Sie den Tokentyp in einem ESQL- oder Java-Programm angeben können) lautet `usernameAndPassword`.	LDAP: Authentifizierung Berechtigung TFIM V6.1: Authentifizierung Zuordnung Berechtigung WS-Trust V1.3 STS (einschließlich TFIM V6.2): Authentifizierung Zuordnung Berechtigung IWA: Authentifizierung
SAML-Zusicherung	Die Extraktion von SAML-Tokens wird von den folgenden Nachrichtenflussknoten unterstützt: SecurityPEP MQInput HTTPInput 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. Der vom Integrationsknoten verwendete Literal-String (mit dem Sie den Token-Typ in einem ESQL- oder Java-Programm angeben können) lautet „ `SAML` “.	WS-Trust V1.3 STS (einschließlich TFIM V6.2): Authentifizierung Zuordnung Berechtigung
Kerberos GSS v5 AP_REQ	Kerberos -Tickets werden für die Verarbeitung durch den Sicherheitsmanager des Nachrichtenflusses vom SecurityPEP -Knoten 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 einem beliebigen Teil der Nachrichtenbaumstruktur auf einem Knoten SecurityPEP abgerufen, wenn die Tokenposition mit einem XPath-Ausdruck oder einem ESQL-Pfad angegeben wird. Der vom Integrationsknoten verwendete Literalzeichenfolgewert (mit dem Sie den Tokentyp in einem ESQL-oder Java-Programm angeben können) lautet `kerberosTicket`.	WS-Trust V1.3 STS (einschließlich TFIM V6.2): Authentifizierung Zuordnung Berechtigung
LTPA-V2-Token	Die Extraktion von LTPA-Tokens wird von den folgenden Knoten unterstützt: SecurityPEP SOAPInput Das Token wird aus einem beliebigen Teil der Nachrichtenbaumstruktur auf einem Knoten SecurityPEP abgerufen, wenn die Tokenposition mit einem XPath-Ausdruck oder einem ESQL-Pfad angegeben wird. Der vom Integrationsknoten verwendete Literalzeichenfolgewert (mit dem 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-Tokens wird von den folgenden Nachrichtenflussknoten unterstützt: SecurityPEP MQInput HTTPInput 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. Der vom Integrationsknoten verwendete Literalzeichenfolgewert (mit dem Sie den Tokentyp in einem ESQL-oder Java-Programm angeben können) ist `X.509`.	TFIM V6.1: Authentifizierung Zuordnung Berechtigung. WS-Trust V1.3 STS (einschließlich TFIM V6.2): Authentifizierung Zuordnung Berechtigung.
Universal WSSE-Token	Universelle WSSE-Tokens werden nur für die Extraktion durch den SecurityPEP -Knoten unterstützt. Das Token wird aus einem beliebigen Teil der Nachrichtenbaumstruktur auf einem Knoten SecurityPEP abgerufen, wenn die Tokenposition mit einem XPath-Ausdruck oder einem ESQL-Pfad angegeben wird. Die vom Integrationsknoten 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 Berechtigung.

Die Quellenidentität wird vom SecurityPEP -oder -Input-Knoten nur 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 die 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 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 Identitätszuordnungsroutine in ESQL oder Java erstellen, indem Sie den IdentitySource* Werte zum Erstellen benutzerdefinierter IdentityMapped* Werte.

SAML- und Universal WSSE-Tokens 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 :

-- Parse the mapped SAML2.0 token in the properties folder and set it in the message body
   CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(InputRoot.Properties.IdentityMappedToken, 
   InputProperties.Encoding, InputProperties.CodedCharSetId);

Um in den Eigenschaftsfeldern SAML- oder Universal WSSE-Tokens definieren zu können, müssen Sie beispielsweise mithilfe der ESQL-Funktion ASBITSTREAM den Bitstrom einer Baumstruktur abrufen.