Im Beispiel enthaltene XML-Firewalls

Die folgenden XML-Firewalls sind im Beispiel definiert.

XML-Firewall StoreAddLTPA

Die Funktion der XML-Firewall StoreAddLTPA besteht darin, ein Front-End mit einem Port auszustatten, den Benutzer nur mit der Basisauthentifizierung (zum Beispiel ohne LTPA (Lightweight Third Party Authentication) oder Ähnliches) aufrufen können. Die Regel zur Anforderungsverarbeitung führt folgende Aktionen aus:
  1. Sie identifiziert durch Basisauthentifizierung.
  2. Sie authentifiziert durch eine sehr einfache LDAP-Suche (Lookup).
  3. Sie fügt ein LTPA-Token im Rahmen der Nachverarbeitung hinzu.
  4. Sie leitet die Anforderung an die StoreWSP-Sicherheitsrichtlinie mit der jetzt angehängten LTPA-Information weiter.

XML-Firewall StoreMockService

Der Service 'StoreMockService' ist ein Beispielservice, der eine XML-Firewall als Implementierung verwendet. Die Operationen 'findInventory', 'purchase' und 'return' werden alle unterstützt. Die Antwortwerte sind statisch. Dieser Beispielservice wird erstellt, wenn es nicht möglich ist, einen WebSphere Application Server in das Muster einzubeziehen. Die drei Anforderungsregeln der Richtlinie ermitteln die Anforderungsoperation durch eine Abgleichsaktion und abhängig von einer gefundenen Übereinstimmung und antworten mit einer statischen SOAP-Antwort. Statische SOAP-Antworten werden auf der Basis der Anforderungsoperation und nicht durch eine vollständige Serviceimplementierung bereitgestellt.

XML-Firewall StoreMockServiceAlternate

Der Service 'StoreMockServiceAlternate' ist ein Beispielservice, der eine XML-Firewall als Implementierung verwendet. Die Operationen 'findInventory', 'purchase' und 'return' werden alle unterstützt. Der Service dient zur Demonstration, wie die Routing-Richtlinie durchgesetzt wird.

Firewall StoreXACMLFW

In diesem Szenario wird eine Überarbeitung (Redaktion) auf der Basis des Ergebnisses eines XACML-basierten Zulassungs-/Verweigerungsmechanismus (Permit/Deny) ausgeführt. In DataPower gibt es keine Möglichkeit, eine einzelne AAA-Aktion im Antwortablauf aufzurufen. Ein separates Gateway wird für den XACML-Richtlinienentscheidungspunkt (PDP) erstellt. Dieser PDP wurde in der Anforderungsregel der Firewall 'StoreXACMLFW' in eine AAA-Aktion eingebunden.

StoreXACMLFW ist ein XML-Firewall-Gateway in DataPower. Diese Implementierung wird verwendet, weil sie eine einfache Methode ist, die Funktionalität bereitzustellen. Die Firewall 'StoreXML' verwendet dieselbe WSDL-Schnittstelle wie der Tivoli Runtime Security Services-Server. Das StoreWSP-Gateway erstellt das Anforderungsobjekt und sendet es, durch SSL geschützt, an das StoreXMLFW-Gateway.

Die Anforderungsregel der StoreXML-Firewall führt die folgenden Operationen aus:

  1. Sie führt AAA mit den SSL-Informationen für die Authentifizierung aus.
  2. Sie führt die Autorisierung mit einem boxinternen XACML-PDP aus. Die Richtlinie, die vom PDP verwendet wird, wurde ursprünglich in IBM® Tivoli Security Policy Manager verfasst, kann jedoch mit einem Standardeditor erneut erstellt werden. Das Schema ist in der XACML-Spezifikation definiert.
  3. Es ist keine Transformation der Anforderung für diese Autorisierungsverarbeitung erforderlich.
  4. Wenn die XACML-Anforderung gültig ist, führt die Anforderungsverarbeitungsregel einen Abruf einer Zulassungsantwort ('Permit') aus und gibt diese an den Client zurück. Andernfalls wird eine Ausnahmebedingung ausgelöst, die von der Ausnahmebehandlungsregel verarbeitet wird, und es wird eine Verweigerungsantwort ('Deny') an den Client zurückgegeben.
Anmerkung: Diese Verarbeitung mit der Antwort 'Zulassung/Verweigerung/Unbestimmt' ist lediglich ein Beispiel. In einen kundenspezifischen Ablauf könnten zusätzliche Fehlerinformationen einbezogen werden.

Konzept Konzept

Feedback


Timestamp icon Letzt aktualisiert: 16. Oktober 2012


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr.doc/topics/csoa2_sample_firewalls.htm