by Paul Done
A service bus enables non-functional aspects of services, such as service security, to be defined and controlled in a uniform way. A service bus allows security concerns to be separated from service implementation. As a result, security policies do not need to be coded into individual services. This yields a far more flexible system with far greater potential for reuse, which is fundamental to security in an SOA context. This tutorial demonstrates an example of applying a central security policy to a service using BEA's AquaLogic Service Bus 2.0. The example shows how WS-Security-based, message-level security can be applied to a SOAP Web service. The tutorial employs a security policy that dictates that Web service client applications must sign SOAP requests and provide trusted certificates. The example shows just one of the many permutations of WS-Security-based policies that can be applied to ALSB-proxied Web services and outlines what steps must be taken in both ALSB and the underlying WebLogic Server to configure security for these Web services. The tutorial assumes the reader has a good technical understanding of Java, J2EE, and Web services, and has some experience using BEA WebLogic Server and AquaLogic Service Bus products.
The AquaLogic Service Bus (ALSB) is an enterprise service bus (ESB) product for managing and brokering services and routing service messages within a service-oriented architecture (SOA) environment. Host environments invariably contain a mix of remote Web services and more traditional message-based networked systems. ALSB acts an intermediary that receives messages and processes them to determine where to route the messages next and whether and how to transform the message content. ALSB receives messages via a transport protocol such as HTTP(S), JMS, File or FTP, and sends the messages on, via the same or a different transport protocol. ALSB is used to encapsulate existing "business services" and to provide a uniform facade for these as a set of "proxy services." By providing this facade, many service characteristics can be abstracted and applied in a single place, such as security policy, service location transparency, data format, transport protocol and messaging model (synchronous, asynchronous). It is then possible to centrally manage these services with respect to versioning, logging, monitoring, reporting, auditing, error handling and client application access. This architecture helps a company to maximize its control and reuse of existing services and provide an efficient model for incrementally adding new services over time.
ALSB can be used to apply security policies to services that it proxies. These security policies can address any combination of security requirements for Web service confidentiality, integrity, authentication, and access control. ALSB supports both transport-level security (such as SSL) and message-level security (such as WS-Security) or even a combination of these for the same service instance, if required. WS-Security is a set of specifications maintained by OASIS that specifies how Web service message content (for example, the SOAP headers and/or body) can be encrypted and signed and how service consumers can authenticate to a service provider (such as via SAML, X.509). By adopting a message-level security policy instead of a transport-level security policy, Web service intermediaries within an SOA (such as enterprise service buses like ALSB) can broker and route messages without necessarily having to decrypt and re-encrypt messages that pass through it. WS-Policy is another specification maintained by OASIS that enables generic attributes and assertions to be specified for Web services. The WS-Security specification adopts the WS-Policy specification as its syntax to enable security characteristics to be specified for Web services.
For this tutorial to easily demonstrate how Web services can be secured using ALSB, the example employs a simple "Echo" proxy service. When invoked, this Echo service copies the body text of the request and sends this text back in the body of the response. As a result, this proxy service does not actually route to a "backend" business service. This design is used to make it as simple as possible to understand how to incorporate WS-Security in ALSB. In a real-world use case, a proxy service would invariably route its messages to and from a "backend" business service. In addition, in this tutorial, self-signed certificates are used rather than certificates signed by a reputable certificate authority, and a single administration WebLogic Server is used rather than a cluster of managed servers.
This example creates and uses a custom WS-Policy file rather than using one of WebLogic Server's three "out-of-the-box" WS-Policy files for WS-Security. The Web service's WSDL and WS-Policy files dictate that service requests but not service responses should be signed by the client. The particular example policy file does not state that encryption should be used for the request or response. Toward the end of the tutorial an optional set of steps is included that describes how to set up access control for a proxy Web service based on the details of the certificate passed by a client application when calling the Web service. Figure 1 shows the basic structure of the tutorial example:
The following sections describe the steps required to configure ALSB and create and invoke the secured proxy service.
First, the AquaLogic Service Bus and its host WebLogic Server instance need to be installed and a domain needs to be configured.
WS-Security relies on PKI to support message encryption, signatures, and often authentication. In this example, a client application uses a private key from its "identity keystore" to sign a message, and the ALSB server uses its "trust keystore" to assist it in determining whether the message has been tampered with and if the supplied certificate is trusted. Therefore, the private-public key pair and associated certificate for the client application need to be created in a new identity keystore, and the certificate must be added to a new trust keystore ready for use by ALSB.
1. Using the Java "keytool" utility included with the WLS/ALSB shipped JDK, create a new public/private key pair for a sample user called "Bob" in a new Identity keystore in the domain's root directory. Here is how we did it:
> keytool -genkey -keyalg rsa -keystore wsidentity.jks -alias bob -keysize 1024 -keypass weblogic -storepass weblogic -validity 3650 What is your first and last name? [Unknown]: bob What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: BEA What is the name of your City or Locality? [Unknown]: LONDON What is the name of your State or Province? [Unknown]: LONDON What is the two-letter country code for this unit? [Unknown]: UK Is CN=bob, OU=IT, O=BEA, L=LONDON, ST=LONDON, C=UK correct? [no]: yes
2. Export the self-signed certificate for this key pair to a base-64 encoded file called "bob.pem":
> keytool -export -alias bob -file bob.pem -keystore wsidentity.jks -storepass weblogic -rfc
3. Import the Bob's self-signed certificate into a new trust keystore that WebLogic Server will use to determine trust for WS-Security and/or SSL client:
> keytool -import -alias bob -file bob.pem -keystore trust.jks-storepass weblogic