Informationen zum Beispielcode 'Security Policy Enforcement Point (PEP)'

Der Beispielcode 'Security Policy Enforcement Point (PEP)' zeigt, wie Sie den Durchsetzungspunkt für Sicherheitsrichtlinien (Security Policy Enforcement Point (PEP)) als Richtliniendurchsetzungspunkt in einem Nachrichtenfluss verwenden können.

In diesem Beispielcode verwendet der Security Policy Enforcement Point (PEP) die Identitätsinformationen aus der Nachricht zur Aktivierung der Sicherheitsoperationen. Zum Beispiel verwendet er die Daten zur Authentifizierung, Berechtigung und Zuordnung mithilfe eines Sicherheitsproviders WS-Trust Version 1.3 wie beispielsweise TFIM Version 6.2. Da die Sicherheitsimplementierung auf einem externen zentralen Sicherheitsprovider wie TFIM Version 6.2 basiert, bietet dieser Beispielcode einen zusätzlichen Nachrichtenfluss, der einige grundlegende Sicherheitsoperationen emuliert.

Es werden außerdem Anweisungen bereitgestellt, in denen die Konfiguration von TFIM V6.2 als externer zentraler Sicherheitsprovider für den Beispielcode detailliert beschrieben wird; siehe Beispielcode 'Security Policy Enforcement Point (PEP)' erweitern.

In diesem Beispielcode wird die Ausführung der folgenden Tasks gezeigt:

Dabei werden die folgenden Szenarios ausgeführt:

Einzelheiten zu den Konzepten zur Nachrichtenfluss-Sicherheit finden Sie in der IBM Integration Bus-Dokumentation unter Sicherheit in Nachrichtenflüssen.

Die Nachrichtenflüsse

Das folgende Diagramm zeigt den Hauptnachrichtenfluss SecurityPEPNodeSampleFlow.msgflow des Beispielcodes 'Security Policy Enforcement Point (PEP)' im Integrationsprojekt 'SecurityPEPNodeSampleApplicationProject'. Dieser Nachrichtenfluss besteht aus einem HTTPInput-Knoten und zwei SecurityPEP-Knoten, die Sicherheitsoperationen aufrufen. Außerdem wird ein HTTPRequest-Knoten zum Aufrufen des Web-Service verwendet, der durch SAML 2.0 gesichert ist.

Screenshot des Nachrichtenflusses des SecurityPEP-Knotens.

Der HTTPInput-Knoten HTTP_ID extrahiert die Identität, die mit der Eingabenachricht übergeben wurde. Der Standort des Benutzernamens und des Kennworts, die die Identität in der Nachricht bilden, sind dem HTTPInput-Knoten durch die konfigurierten Sicherheitseigenschaften bekannt. Der HTTPInput-Knoten der Brokerarchivdatei SecurityPEPNodeSample.bar wird mit dem Sicherheitsprofil PEPSAMPLE_HTTP_UPA1_EMUL konfiguriert. Die Werte für authentication und authenticationConfig im Sicherheitsprofil werden zum Aufrufen der STS-Emulation festgelegt, um die Identität zu authentifizieren. Sollte die Authentifizierung des Tokens für die Identität des Benutzernamens und Kennworts an diesem Knoten fehlschlagen, wird die Ausnahmeliste an das Fehlerterminal übertragen. Ist die Authentifizierung erfolgreich, wird die Nachricht an den nächsten Knoten 'GetAuthenticationType' übertragen.

Der Rechenknoten 'GetAuthenticationType' ruft das Feld DemonstrateTokenType aus dem Inhalt der Eingabenachricht ab und leitet sie entsprechend weiter. Das Feld DemonstrateTokenType kann den Wert UP oder SAML annehmen. Falls es keinen dieser Werte annimmt, wird eine Benutzerausnahmebedingung ausgelöst.

Der SecurityPEP-Knoten PEP_UP_A1A2 extrahiert die Identität des Benutzernamens und Kennworts aus der Eingabenachricht und zeigt so, dass der Standort der Identität in der Nachricht dem SecurityPEP-Knoten durch die konfigurierten Sicherheitseigenschaften bekannt ist. Der PEP-Knoten der Brokerarchivdatei SecurityPEPNodeSample.bar wird mit dem Sicherheitsprofil von PEPSAMPLE_PEP_UPA1A2_EMUL konfiguriert. Die Werte für authentication, authenticationConfig, authorization und authenticationConfig im Sicherheitsprofil werden zum Aufrufen der STS-Emulation festgelegt, um die Identität zu authentifizieren und zu autorisieren. Wenn die Authentifizierung und Autorisierung des UP-Tokens erfolgreich ist, wird die Nachricht an den Rechenknoten übertragen; dort wird der Status der Sicherheitsoperation im Nachrichtenhauptteil aktualisiert und anschließend eine Antwort zurückgesendet.

Der SecurityPEP-Knoten PEP_MAP_UP->SAML2.0 verwendet die mit der Eingabenachricht übertragene Identität erneut und trägt sie in die Sicherheitsfelder der Eigenschaftenbaumstruktur ein. Wenn für die konfigurierten Sicherheitseigenschaften Current token (Aktuelles Token) festgelegt wurde, verwendet der SecurityPEP-Knoten die aktuelle Identität. Der PEP-Knoten der Brokerarchivdatei SecurityPEPNodeSample.bar wird mit dem Sicherheitsprofil von PEPSAMPLE_PEP_MAPUP2SAML2.0_EMUL konfiguriert. Die Werte für mapping und mappingConfig des Sicherheitsprofils werden zum Aufrufen der STS-Emulation festgelegt, die eine Tokenvermittlung des Benutzernamens und Kennworts an den SAML 2.0-Inhalt durchführt. Der zugeordnete SAML-Knoten wird dann in den Nachrichtenhauptteil eingereiht, damit er über den HTTPRequest-Knoten "HTTP Request-SAMLA1" an einen Service weitergeleitet werden kann, der für das Aufrufen des Nachrichtenflusses SecurityPEPNodeReportFlow.msgflow konfiguriert ist.

Der vom HTTPRequest-Knoten im Nachrichtenfluss SecurityPEPNodeSampleFlow.msgflow aufgerufene HTTP-Service ist in der folgenden Abbildung zum SecurityPEPNodeReportFlow.msgflow gezeigt:

Screenshot des Webservice-Flusses, der über SAML2.0 aufgerufen wurde.

Dieser Nachrichtenfluss beinhaltet einen SecurityPEP-Knoten, der den SAML2.0-Inhalt im Nachrichtenhauptteil der Eingabenachricht extrahiert und den Sicherheitsprovider aufruft, um den SAML2.0-Inhalt zu überprüfen. Der PEP-Knoten der BAR-Datei SecurityPEPNodeSample.bar wird mit dem Sicherheitsprofil von PEPSAMPLE_HTTP_SAMLA1_EMUL konfiguriert. Die Werte für authentication und authenticationConfig des Sicherheitsprofils werden zum Aufrufen der STS-Emulation festgelegt, um den SAML-Inhalt zu prüfen. Wenn die Überprüfung des SAML2.0-Inhalts erfolgreich ist, wird die Nachricht an den Rechenknoten übertragen; dort wird der Status der Sicherheitsoperation im Nachrichtenhauptteil aktualisiert und anschließend eine Antwort zurückgesendet.

Der Beispielcode emuliert mithilfe des Nachrichtenflusses SecurityPEPNodeSampleSTSEmulatorFlow.msgflow die Sicherheitsoperationen, die von einem externen Provider ausgeführt werden; siehe folgendes Diagramm:

Screenshot des Nachrichtenflusses, der die Operation des Sicherheitsproviders emuliert

Dieser Nachrichtenfluss enthält den HTTPInput-Knoten "HTTP WS Request", der die WS-Trust-Anforderung des IBM Integration-Sicherheitsmanagers empfängt, wenn die HTTPInput- und SecurityPEP-Knoten im Nachrichtenfluss SecurityPEPNodeSampleFlow.msgflow eine Sicherheitsoperation aufrufen. Der Nachrichtenfluss beinhaltet zahlreiche Rechenknoten, die das Ergebnis eines Sicherheitsproviders emulieren und eine WS-Trust-Antwort vorbereiten.

Hinweis: Die Emulation verwendet festgelegte Daten, die bei jeder Ausführung dieselbe WS-Trust-Antwort erzeugen. Im Falle des SAML-Tokens werden die Daten nicht dynamisch geändert. Beispiel: IssueInstant="2010-04-14T07:10:53Z", NotBefore="2010-04-14T07:00:53Z" und NotOnOrAfter="2010-04-15T07:10:53Z". Diese Daten sowie der Gültigkeitszeitraum des SAML-Inhalts werden durch die Emulation nicht überprüft.

Nachrichten

Zur Ausführung des Beispielcodes 'Security Policy Enforcement Point (PEP)' stehen drei Eingabenachrichten zur Verfügung.

Zurück zum Beginn des Beispielcodes