+

Search Tips   |   Advanced Search

 

Web services security with WebSphere appserver V6



Architectures

Transport security architectures:

Web Services Security (WS-Security) architectures:

Publish/Subscribe architecture

Tivoli® architectures:

DataPower® XS40 architecture


IPSec VPN

Configurations with IPSec are also called Virtual Private Networks or VPNs.

An IPSec router in the client infrastructure encrypts traffic bound for the service infrastructure. An IPSec router in the service infrastructure decrypts the IP packets and forwards them to the machine hosting the service for processing. All traffic from the client infrastructure, or network, to the service infrastructure, or network, and from the service side to the client side is encrypted. This encryption is applied to all IP packets and is not enabled or disabled on a per application or per service invocation basis.

Note that IPSec connections can be established using software on the client machine rather than using a dedicated IPSec router, but using dedicated equipment scales better.

IPSec provides confidentiality and integrity. An HTTP Basic authentication header provides identification and authentication.

Note that WebSphere does not provide IPSec technology.


Transport security with HTTP server acting as SSL endpoint


Common configuration for Web services. The client application...

...establishes an SSL session with the server hosting the service and then invokes the service over the SSL channel. No application data is transmitted until the secure SSL channel is established, a process during which the server machine is authenticated.

SSL supports hardware acceleration and is interoperable between different vendors and is thus a safe choice for high throughput situations in which the security architecture can tolerate the following...

Note that the SSL endpoint could be the Web services gateway rather than the HTTP server in front of an appserver instance hosting the service. In this case, the gateway could perform some content-based routing or logging functionality.

An HTTP Basic authentication header is used to propagate the identity of the caller to the provider. We could have chosen client-side SSL certificates, which would have been a viable solution in cases where the client and service are under the administrative control of a single entity, or where there are few enough clients to make managing the client certificates reasonable.

Using HTTP Basic authentication allows the credential to propagate from HTTP client to HTTP endpoint (appserver). With client-side SSL certificates, the identity would be propagated only to the first SSL endpoint. We would need to use another technology to propagate it downstream. This is because the identity of the client is made known to the server during the SSL handshake and the client performs this process with only the first SSL endpoint in the chain.


Transport security with Web Services Gateway acting as SSL endpoint

The Web services gateway architecture is similar to the previous one that had the HTTP server as the SSL endpoint and offers the following advantages...

The SSL connection is terminated further from the service than was the case with the HTTP server as SSL endpoint.

The identity of the caller is propagated as in the previous architecture and the same considerations apply.


WS-Security

WS-security architecture provides end-to-end security and possibly non-repudiation if the service persists the inbound message before removing security.

SSL is used to provide an additional level of security across the untrusted network, ensuring that the server-side is identified and a secure channel established before any application data is exchanged.

With WS-security, the application data is sent before the identity of the destination is confirmed, which could subject it to offline attack. However, the level of protection provided by the length of keys typically used with WS-Security (256-bit symmetric or 1024-bit asymmetric) is very high, which makes the threat of offline attack minimal.

In the above diagram...

There are two issues here:

We can use some form of third-party, like a trust service or Web services gateway, to address the key/token issue We can use identity federation for the identity issue.


Gateway on server side acting in role assigned to WS-Security header

For architectures where a gateway on the server side acts in a role assigned to the WS-Security header, clients invoking any number of services exposed through this gateway need only be configured to trust keys or tokens from this single gateway, rather than keys and tokens from each service. The gateway needs to be configured to trust keys and tokens from each client.

This architecture partially addresses the token trust scalability issue of the simple architecture using Web services security above. It does not address the account maintenance scalability issue.

Where this architecture differs from the Gateway as SSL endpoint architecture is in allowing flexibility, as follows:

On the downside, outside of the DataPower device discussed in a later section, WS-Security is still an order of magnitude slower and more resource-intensive than SSL and, therefore, may not be appropriate for all scenarios.


Gateway on server side not acting in role assigned to WS-Security header

The architectures in which a gateway on the server side is not acting in role assigned to the WS-Security header provides something of a combination of the features of the gateway as SSL endpoint architecture and the simple WS-Security architecture. It provides the following:

Unlike the gateway as an SSL endpoint architectire, but like the simple WS-Security one, this architecture requires that token trust relationships be established between each communicating client and service pair. It therefore suffers the same scalability issues as the simple architecture using Web services security.


Gateway, middle tier, and back-end on server side

The architecture using gateway, middle tier and back-end on the server side adds an invocation of a downstream service as part of the implementation of the service invoked by the client. This is a typical situation. All of the considerations and possibilities discussed in the previous architectures apply between the middle tier service and the downstream service.

Current best practice is to propagate the incoming identity principal to the downstream service. This allows the downstream service to manage its own auditing and account information. If only the identity of the middle tier service is propagated to the downstream service, the downstream service does not have proper control over audit and authorization of access to the service.


Gateway on client side and service side

This architecture using gateway on the client side and the service side offers client and service implementers the flexibility of choosing internal protocols that are different from the external protocol used between the gateways. This architecture has the benefit of only requiring a trust relationship between gateways, rather than individual relationships between each client and service. However, this comes at the expense of changing the bounds of the relationship to be between gateways rather than between individual clients and services. Individual client/user principals can be propagated between client and service if appropriate transports are used.

For example, the client could authenticate to the gateway using mutual SSL. The client gateway propagates the client principal using identity assertion to the service gateway. The service gateway propagates the client principal to the service provider. This will only work if the client principal exists in the service platform user registry. Thus, we have done something to alleviate the token trust scalability issue. However, we haven't addressed the account maintenance scalability issue. If we want to remove the requirement that the client principal must exist in the service platform user registry, an identity mapping could take place in the client gateway to propagate an identity that represented the client and existed in the service user registry. One of the following sections describes an architecture that leverages Tivoli Federated Identity Manger to perform this mapping.

In this architecture, the client also benefits from the features provided by the gateway, such as a well-defined place to insert mediations, protocol translations and security protocol translations.


Publish/Subscribe


Confidentiality is somewhat tricky in the publish/subscribe architecture because we can't simply use the PKI techniques that we can use in a one-to-one interaction between a client and service provider. Typically for one-to-one interactions we use the service public key to encrypt information (and provide confidentiality). Because we now have multiple service providers, the question is: whose public key are you going to encrypt with?

One solution is to use some previously agreed upon secret key (symmetric key cryptography like DES or AES) for encryption.

Another would be to share a PKI private key among the service providers. This second approach is interesting because private keys in PKI are usually used to identify a single principal, not any principal acting in a role, which is a more accurate description of the situation when multiple principals share a key.

If all clients and service providers can be made to join the same Kerberos realm, then, when appserver supports it, Kerberos protocols could provide the encryption keys in this scenario. Because the sender's private key is used for signing (integrity and non-repudiation), we don't have to change the way we use PKI for that component of the security.

There are other message exchange patterns that suffer from this problem. Basically, anytime a single message is bound for multiple endpoints, this problem occurs. One solution is to redefine the business problem such that the first endpoint is the only real endpoint from the client's perspective and any others are implementation details of the service. The service is then free to use whatever security it chooses to use downstream to the services it invokes. This interpretation would, for example, allow for SSL to be used from the client to the publish/subscribe hub, and the separate SSL connections to be used from the publish/subscribe hub to the subscribers.


Tivoli Access Manager

Tivoli Access Manager comprises a number of components, one of which is a security proxy server called WebSEAL, which:

In this architecture, we leverage WebSEAL's ability to perform SPNEGO authentication on incoming Web connections. This may be a popular configuration for .Net clients invoking Web services. The security token used with SPNEGO in this case is a Kerberos token provided by Active Directory. Other clients are also possible, such as Mozilla on Linux. Java-based Kerberos Key Distribution Centers (KDC's) may become more available in the future, which would facilitate the spread of Kerberos and may enable more clients to make use of Kerberos tokens.

Passing the Kerberos tokens in an HTTP header is only one way to use them. Another way that may become popular is to pass them in a WS-Security header. To use them with WS-Security headers, we need to look at Tivoli Federated Identity Manager. Note that in the Tivoli Access Manager architecture, the client and service provider must be members of the same Kerberos realm or of Kerberos realms that have a trust relationship.


Tivoli Federated Identity Manager

Tivoli Federated Identity Manager...

In this architecture, Tivoli Federated Identity Manger is installed into a Web services gateway node and is used to validate incoming tokens and to map incoming identities from the client user realm to the service user realm. The mapping is configurable and can, for example, map a group of incoming users to a single service-side user. Other Identify Manager functionality beyond that provided by appserver includes consuming SAML and Kerberos token types and mapping incoming token types to different token types for propagation to the service provider.

An instance of Identity Manager can be installed on the client side to provide token creation and mapping and outbound dentity mapping, too.

In this architecture, we address the token trust scalability issue by concentrating the adminstration of trust in the Identify Manager trust service. We also mitigate the account maintenance scalability issue by leveraging the Identity Manager credential mapping function. Distributed single sign-on protocols also play a part here, enabling the expensive part of account management to be concentrated at one point.


DataPower

DataPower XS40 Security device provides...

Comprehensive security All XML and TLS security functions in one device
Performance Purpose-built to secure without degradation
XML-based agility Future-proof for changing standards, policies, partners
Appliance-based Drop-in device secures multiple applications at once
Easy integration Interoperates with and augments existing security systems
XML transformation Includes XPath/XSLT acceleration features

This is the same as the gateway on server side acting in role assigned to the WS-Security header architecture but with the XS40 substituted for the Web Services Gateway. This architecture allows us to scale the solution because the XS40 can process Web services security with very little overhead. As with the gateway architecture that this is based on, although it partially addresses the token trust scaling issue, it does not address the account maintenance scaling issue.


More articles in this series



Resources

Learn

Get products and technologies

Discuss