Chapter 4. Security
4.3 WS-Security
4.3.6 Exceptional added value
The DataPower Security Gateway appliance has some powerful intrinsic abilities relevant for XML security processing. In XML threats protection, the DataPower Security Gateway appliance offers some exceptional advantages by comparison to typical solutions. Two are described bellow.
Client System (browser,
rich client) Firewa
ll Fi re w a ll Existing Application Authentication
Services IT Security Services
Identity Services
Security Policy Infrastructure
Identity and Access Business Security Services
Policy Distribution &
Transformation Monitoring &Reporting Policy Administration Policy Decision
WS-Security acceleration
IBM performance labs have demonstrated a significant performance gain when using DataPower to handle some or all WS-Security processing in a message flow. This is the result of the hardware optimization used in both cryptographic and XML processing. For clients who wish to use WS-Security and have performance concerns, DataPower provides an ideal solution. The DataPower appliance can consume Web services using WS-Security at network speeds and then pass the messages on to the service provider without all of the WS-Security overhead. The same is true for the responses (when request/response is in use) where Web services responses can have WS-Security information added. Figure 4-15 shows this.
Figure 4-15 Functional acceleration with DataPower XI50/XS40
This proxying approach is very useful when identity propagation is used to bridge between multiple security contexts. For example, if the back-end Web service is hosted on WAS, DataPower can be used to extract the identity from a client credential, such as a SAML assertion, and presented to the WAS Web Service as an easily understandable LTPA token. There are many other examples of how DataPower can be used to extract, authenticate, and propagate identities. One must keep in mind that defining the correct security solution for any environment is an optimization exercise between protection level, performance, and
maintainability. In complex distributed environments, expect the optimal security solution to be a mix of network-level, message-level, and data-level protection.
This leads us to our next recommendation. For an application server based system using WS-Security where performance is a concern, consider using DataPower to handle this processing while establishing trust to the back-end service (for example, mutually authenticated SSL between DataPower and the application server).
WS-Security flexibility
When using DataPower to provide WS-Security as a proxy, we gain flexibility along three key dimensions. First, DataPower today (and in the near future) simply supports more of the WS-Security standards than our typical application server-based products. Secondly, DataPower fundamentally includes an XSL processing engine, so it is quite feasible to process Web services messages that are not quite in a format that an application server can understand. DataPower can alter those messages or more flexibly interpret them as needed. Thirdly, by offloading the WS-Security processing to DataPower, we eliminate the need to configure and reconfigure the back-end server (any application server) to understand different WS-Security messages. It is all transparent to the back end.
With regard to the first point, DataPower and other IBM products (such as WAS) will continue to be enhanced to support newer portions of the WS-Security standards, but at least for the near term, DataPower has features that are not found in other IBM products.
This leads us to these recommendations:
For clients who wish to use WS-Security but find that their application server is unable to support the standard of interest, they should evaluate DataPower to see whether it does support this standard or can be altered to support it.
Clients expecting to frequently change the WS-Security formats expected or those with problematic messages (for example, nonstandard in some minor way) should evaluate DataPower as a solution to provide the needed flexibility.
Closely related to the concept of flexibility is the concept of credential transformation. Since Web services requests often transition security domains, the credentials that arrive inbound to a boundary server often require transformation before being understood by the recipient or prior to sending on within the network. This transformation can occur along two dimensions: the technology and the naming. By technology we mean changing a credential from one type to another. For example, the sender might use digital signatures to provide identity
information, while the internal systems expect username tokens.
The second transformation is simpler but no less important. The name that represents a subject may change. For example, your
identity
to IBM might be your IBM serial number, but your identity to your bank could be your bank account number or social security number. Identity transformation addresses both issues. Traditionally, with IBM there have been two ways of approaching this problem: Custom developed ad hoc code.
Leverage a product like Tivoli Federated Identity Manager (TFIM).
Now DataPower provides a more robust means of providing credential transformation with Web services processing. DataPower can perform a fairly large class of credential
transformations (both technology and naming) using built-in function as well as custom XSLT transforms. DataPower can also call out to products like TFIM to perform that translation. The obvious question is when to apply which technology. The answer is fairly straightforward.
More information
Because Web services security is a quickly evolving field, it is essential for developers and designers to regularly check for recent updates.