 |
|
WS-DBC - Architecture and Deployment Examples
Two common deployment scenarios for the use of the Web
Services DBC as an XML firewall are the DMZ (De-Militarized Zone)
scenario and the B2B scenario explained below. While the DMZ
scenario focuses on the protection of the own network an
application servers alone, the B2B scenario additionally supports
secure federation of enterprise services with partner
companies.
|
|
|
DMZ Scenario.In the DMZ scenario, two firewalls
are used to create an outer screened subnet, or demilitarized zone
(DMZ). This subnet contains the Web Services DBC gateway component,
which protects SOAP receivers in the protected domain by analyzing
and potentially terminating SOAP traffic. This scenario is shown in
the figure below.
The
SOAP receiver can be a standalone application, or a container
environment such as a Web Server or a J2EE Application Server. The
exterior firewall (packet filter) is the connection point to the
public network. It restricts access to specific systems in the
screened subnet and allows only these systems to access the public
network. The packet filter blocks all other traffic from/to the
public network. The second, interior firewall (packet filter)
restricts access from the protected network to specific systems on
the screened subnet and allows only these to access the protected
network. It blocks all other traffic to the protected domain.
In the example shown here, also in the protected domain is the
Security Policy Server (The WS-DBC, together with arbitrarily many
other DBCs, can be controlled by a central Security Policy Server
with a single unified security policy if desired; otherwise the
security policy module that comes with the WS-DBC software is
typically installed at the same machine as the WS-DBC). If desired,
the Policy Server can talk to the gateway over a dedicated management
network using a separate network interface.
Federated Trust (B2B) Scenario.The second main
deployment scenario is used to integrate across enterprises, e.g., in
a manufacturer-supplier application such as supply chain management .
One of the key challenges here is how disparate IT infrastructures
can be federated without either enterprise having to creating a large
number of new accounts for each partner it is willing to cooperate
with. It is also highly undesirable to modify existing applications,
or distribute new credentials to clients. In this setting, a
sender-side WS-DBC can offer a huge cost-saving benefit by
- mapping between different credentials (e.g. roles), and
- hiding the heterogeneity of client and server SOAP
platforms.
This scenario is illustrated in the figure below.
The
sender-side WS-DBC can authenticate incoming SOAP messages relying on
the authentication mechanisms and credentials used in the sender-side
domain. It can map these to roles or user IDs recognized at the
receiver end. The sender-side WS-DBC would then transparently create,
sign, and insert standard SAML assertions that contain these mapped
credentials. Moreover, it can perform outgoing access control and
message content filtering to enforce security policies at the sender.
The receiver-side WS-DBC can establish trust in SOAP messages by
verifying the sending gateway's XML Digital Signature found in
message headers. Based on the authenticated identities or role
memberships, it can then perform access control, auditing, content
filtering, etc. Security-aware Web Services that are able to process
SAML may perform additional security checks, if desired.
 printable
version
|
