Figures 1 and 2 are examples of security architectures. The purpose of these diagrams is to convey the different points in the protocol stack at which intermediaries might exist between a client and a service. They're not representative of an actual infrastructure architecture. In any real infrastructure architecture, it would be very unlikely that intermediaries existed at all the levels shown in the diagrams. It is, however, likely that one and possibly more of the types of intermediaries shown here would exist in a given architecture.
Under each intermediary in these figures is a list of example implementations for that type of intermediary. The different technologies are split into different intermediaries because they're often implemented that way, but it's also possible for them to co-exist on the same node. So, for example, the IPSec connection could be initiated from a dedicated IPSec router, or in software on an HTTP server, or in software on an application node.
The black lines flowing between the stacks in the figures below represent flow of security context not information flow. Information always flows from application to application.
Figure 1. Security architecture (client perspective)
The HTTP server listed in the sample server side implementations has the WebSphere Application Server (hereafter called Application Server) plug-in installed, and is forwarding the HTTP requests to Application Server process them. If this was a truly standalone HTTP server, it would more appropriately be called the HTTP endpoint, but with the Application Server plug-in, for the purposes of this discussion Application Server is the real HTTP endpoint.
Figure 2. Security architecture (server perspective)
SOAP (and even to a degree HTTP) can have multiple endpoints associated with the message. These are identified by roles. The SOAP headers can be targeted at a particular SOAP endpoint, or role. If the SOAP processor is acting in the role indicated by the header, then it is the SOAP endpoint for that header. If the SOAP processor is acting in a different role, then it is not the SOAP endpoint for that header, and the header must be flowed downstream for further processing.
The Web services gateway is an example of a SOAP processor that will at times take the role of ultimate receiver (which means the service provider, in this discussion) and at times take on some other role. When the gateway translates the incoming message into a protocol that does not support SOAP security (such as RMI/IIOP) the gateway itself must process the Web services security headers in the message. This means that either the client must target the message to the role the gateway is acting in or the gateway must act as the ultimate receiver for the purpose of the security processing. In this case, the gateway is, in effect, the service provider and simply makes use of the downstream service as part of the implementation of the service it's exposing.
In the rest of the article, you'll learn about the following Web services security architectures that you can implement with Application Server Version 6, and the advantages and disadvantages of each:
Transport security architectures:
Web Services Security (WS-Security) architectures:
- Simple architecture using Web services security
- Gateway acting in role assigned to WS-security header
- Gateway not acting in role assigned to WS-security header
- Gateway, middle tier, and backend on service side
- Gateway on client side and on service side
Figure 3 shows an architecture using IPSec.
Figure 3. IPSec
The sample infrastructure architecture above uses the protocol stack notation. It is constructed by including selected intermediaries from both the client and service side views shown in Figures 1 and 2.
In this architecture, 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. This configuration is often called a Virtual Private Network or VPN. 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.
While IPSec is providing confidentiality and integrity to our service, the simple HTTP Basic authentication header is providing identification and authentication. This technology is supported by all significant client technologies.
Note that WebSphere does not provide IPSec technology.
Figure 4 shows an architecture using transport security with HTTP server acting as SSL endpoint.
Figure 4. Transport security with HTTP server acting as SSL endpoint
This architecture is how most production Web services are secured today. In this architecture, the client application (standalone Java™ application, .Net app, servlet, etc.) 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. Note that this technique is available to all client types that can establish SSL connections (in other words, virtually all client technologies). By contrast, WS-Security from Application Server is not currently available to standalone (Java 2 Standard Edition) Java applications, for example. SSL is a mature technology and has been optimized over the years. It supports hardware acceleration and is interoperable between different vendors. For these reasons this architecture is a good choice for high throughput situations in which the security architecture can tolerate the following:
- The security applied to the communication terminates at the SSL endpoint and not the actual service. The communication may be secured via a second SSL connection from the SSL endpoint to the service provider, but the message will be in the clear in the intermediary SSL endpoint application (HTTP server, say).
- No other intermediaries can be introduced between the client and the SSL endpoint on the service side. This affects options for content-based routing or logging on either the client or service side. Often the initial topology does not call for another intermediary, so this becomes a good choice. Requirements change over time and you may want to insert some sort of proxy or denial of service (DoS) prevention device or other intermediary at a later time. You could insert this device after the initial SSL endpoint, or it could become the initial SSL endpoint itself.
- There is no provision for non-repudiation as all application data that is exchanged has been encrypted using symmetric key technology.
Note that the SSL endpoint could be the Web services gateway rather than the HTTP server in front of an Application Server instance hosting the service. In this case, the gateway could perform some content-based routing or logging functionality. We'll examine this variation next.
We've once again chosen to use a HTTP Basic authentication header 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. Of course, username and password-based accounts have to be managed as well. We'll discuss the issue of managing these accounts more in the architectures that follow. Using HTTP Basic authentication also allows the credential to propagate from HTTP client to HTTP endpoint (Application Server). If we had used 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.
Figure 5 shows an architecture using transport security with Web Services Gateway acting as SSL endpoint.
Figure 5. Transport security with Web Services Gateway acting as SSL endpoint
This architecture is similar to the previous one that had the HTTP server as the SSL endpoint. This architecture may offer the following advantages over that one:
- There is now a well-defined place (gateway mediations) to add intermediate functionality like logging or content-based routing on the server side.
- The gateway can perform transport translation and send the message to the service using a different transport, such as SOAP/JMS, from the inbound one.
- The gateway can propagate the security context (identity of the inbound caller) to the service using a mechanism other than HTTP Basic authentication, for example, an IBM proprietary LTPA token, which may reduce the overhead of authentication at the service. The gateway can even use WS-Security to pass the context back to the service implementation, if the transport between the gateway and service provider supports SOAP and Web services security.
On the other hand, from a functionality standpoint, the SSL connection is now terminated further from the service than was the case with the HTTP server as SSL endpoint. Some customers may feel that the SSL connection should be terminated as close to the service as possible, and may even want to remove all intermediaries by having the Application Server terminate the SSL connection itself. This is certainly possible and, although less flexible, is perfectly valid.
The identity of the caller is propagated as in the previous architecture and the same considerations apply.
Figure 6 shows a WS-security architecture.
Figure 6. WS-Security
This architecture uses WS-Security to provide 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. By using SSL, we ensure that the server-side is identified and a secure channel established before any application data is exchanged. When using 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.
The example above is an entry-level WS-Security architecture. The relationship between the client and service provider appears to be one-to-one. The client is configured to trust the service keys or tokens and the service is configured to trust the client keys or tokens. This is fine for entry-level WS-Security, but will not scale sufficiently well when large numbers of clients and services are involved.
There are two issues here:
- One is the need for the client and server sides to trust each other's tokens and keys.
- The other is for the client principal to exist in the service user registry (and possibly vice versa).
We use some form of third-party ,like a trust service or Web services gateway, to address the key/token issue, and we can use identity federation for the identity issue. We'll talk about architectures using these techniques in following sections.
Figure 7 shows an architecture in which a gateway on the server side acts in a role assigned to the WS-Security header
Figure 7. Gateway on server side acting in role assigned to WS-Security header
This architecture is somewhat similar to the gateway as SSL endpoint architecture. Like that architecture, this one allows for all keys and tokens used to provide integrity and confidentiality to services exposed through the gateway to be managed at one point, the gateway. That means that 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. So while this architecture partially addresses the token trust scalability issue of the simple architecture using Web services security above, it does nothing to address the account maintenance scalability issue.
Where this architecture differs from the Gateway as SSL endpoint architecture is in allowing flexibility, as follows:
- Different token types can be used to propagate the client or user ID to the gateway such as UsernameToken, X.509 and LTPA tokens today with Kerberos tokens in the future.
- Other SSL endpoints can be added between the client and gateway if appropriate. An example would be some sort of reverse Web proxy in the server side infrastructure, perhaps providing some caching functionality.
- Non-repudiation is at least possible (though it would require custom code in the gateway) with this architecture.
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.
Figure 8 shows an architecture in which a gateway on the server side is not acting in role assigned to the WS-Security header.
Figure 8. Gateway on server side not acting in role assigned to WS-Security header
- A well-defined place (gateway mediations) to add intermediate functionality like logging or content-based routing on the server side (assuming that the content to be used for content-based routing decisions is not encrypted).
- The gateway can perform transport translation and send the message to the service using a different SOAP-based transport, such as SOAP/JMS.
- One of the mediations provided by the gateway can be to log the inbound message in its secured state, thus facilitating non-repudiation.
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 architecure using Web services security.
Figure 9 shows an architecture using gateway, middle tier and back-end on the server side:
Figure 9. Gateway, middle tier, and back-end on server sider
This architecture is the same as the server side gateway not acting in a security role architecture with the addition of 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, although they are not shown in Figure 9. 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.
Figure 10 shows an architecture using gateway on the client side and the service side.
Figure 10. Gateway on client side and service side
This architecture 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.
Figure 11 shows a publish/subscribe architecture:
Figure 11. Publish/Subscribe
Confidentiality is somewhat tricky in the publish/subscribe architecture because we can't simply use the public key infrastructre (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 Application Server 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.
Figure 12 shows a simple architecture using Tivoli Access Manager:
Figure 12. Tivoli Access Manager
Briefly, Tivoli Access Manager comprises a number of components, one of which is a security proxy server called WebSEAL, which:
- Runs either as a standalone server or as a plug-in to popular Web servers
- Adds SPNEGO (Kerberos) functionality to allow users to authenticate to Web-based applications without being challenged after they have logged into their operating system.
- Can provide cross-site single sign on (CSSO) using proprietary CSSO technology
- Can make authorization decisions for Application Server. J2EE authorization decisions are delegated to the Access Manager authorization service. This allows for roles to be defined that span enterprise resources rather than having an Application Server role, a Windows role, a RACF role, and so on.
- Can be used with Web services when using HTTP or HTTPS.
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.
Figure 12 shows a simple architecture using Tivoli Federated Identity Manager:
Figure 13. Tivoli Federated Identity Manager
Briefly, Tivoli Federated Identity Manager:
- Is implemented as an Application Server application
- Depends on Tivoli Access Manager
- Provides security token service functionality (WS-Trust, WS-Federation)
- Adds Security Assertion Markup Language (SAML) token support, which can be used per the SAML HTTP profiles or as a token in a WS-Security header.
- Provides the Liberty Aliance Project identity federation protocol implementation.
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 Application Server 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.
Figure 12 shows a simple architecture using DataPower.
Figure 14. DataPower
Briefly, the DataPower XS40 Security device provides the following functions:
- 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.
This article provides an introduction to some simple Web services security architectures. Subsequent articles in this series will provide step-by-step instructions on how to implement these architectures using IBM products, as well as further advice on selecting tokens.
- Part 2: Using Username Token and SSL
- Part 3: Using XML encryption and digital signature
- Part 4: Using the LTPA token
- Part 5: DataPower as a gateway device
developerWorks WebSphere Web services zone: Get all the latest information and downloads for WebSphere Web services.
developerWorks SOA and Web services zones: Get all the latest information and downloads for IBM SOA and Web services technologies.
End-to-End Arguments in System Design, by J.H. Saltzer, D.P. Reed and D.D. Clark, M.I.T. Laboratory for Computer Science: This paper describes a design principle called the end-to-end argument, which suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. One of the examples discussed in the paper is security using encryption.
OASIS: Learn more about WS-Security.
Liberty Alliance Project: Learn more about Identity federation and Web services frameworks.
WebSphere Application Server: Get more information about Tivoli Access Manager.
WebSphere Application Server: Get more information about Tivoli Federated Identity Manager.
DataPower: Get more information about DataPower.
Get products and technologies
WebSphere Application Server: Learn more about WebSphere Application Server V6 and download a trial version.
Web services forums: Get answers to your questions on Web services forums.
Tony Cowan is a senior consultant with the IBM Software Services for WebSphere (ISSW) team in IBM. He has been consulting in distributed system development for over 11 years and has lead IBM teams on many projects with Fortune 1000 companies. Tony currently focuses on teaching Web services and Web services security to IBM consultants and customers. A frequent speaker at technical events, one of Tony's primary objectives at IBM is to bring real customer requirements to the IBM development teams to assist in aligning IBM products with real world needs. You can contact Tony at email@example.com.