© Copyright International Business Machines Corporation 2002. All rights reserved.

This month, we asked IBM Web Services security expert, Tony Cowan, to answer your questions about Web Services security issues, specifically where the standards are heading and how to secure your services. Tony is a team lead for Web Services in the IBM Software Group. He specializes in security and IBM's J2EE interoperability with Microsoft.NET®. If you want more information about WebSphere® Services, see WebSphere Web Services Zone.

We appreciate and thank all the WebSphere developers who submitted questions.

Question: I am consulting as a security architect for a leading global bank with over 100,000 employees. We are currently discussing what type of standards/guidelines we should develop internally to assist development teams in implementing Web Services Security or what type of infrastructure and standard products we should have in place. How would you approach a problem like this? (submitted by EG)

Answer: You are in good company grappling with this issue. Because this is an area of tremendous flux at present, I'd set expectations at the bank that short term tactical solutions implemented today will need to be replaced over time. You'll want to make a statement something like "Our long term position is that all applications making use of Web services will depend on the WS-* standards implemented by "off the shelf" infrastructure to conduct secure conversations. However, until commercial infrastructure products completely support those still evolving standards, each application is free to augment the functionality offered by the infrastructure to fulfill its independent needs for integrity, confidentiality, and non-repudiation in an efficient application specific manner. The chosen solution needs to provide a reasonable migration path to the stated long term objective." In providing something along those lines, you're indicating that security is really an infrastructure issue. Application developers should keep whatever code they need to write to implement the required security functionality in some separate module that will be replaced by bought infrastructure over time.

Today, Web services development and deployment environments will generate and check WS-Security headers with digital signatures, user name, and password tokens in them. There have been demonstrations of binary tokens X509 and Kerberos tickets being passed, but the infrastructure to make use of those at either end is largely hand coded. Some large organizations are still developing fat clients, and of those, some have chosen to use C# as their platform, which introduces interoperability issues on top of the immaturity issues. In short, most deployed Web services are using standard HTTP security techniques of SSL and HTTP basic Auth to provide their immediate security needs. This simple, single transport solution lacks the following: end to end protection, non-repudiation, selective protection (securing a subset of the message), a robust and flexible authentication mechanism, and provision for message level (or end to end) secure context. As Web services are more broadly applied, HTTP level security will need to be replaced by the WS-Security related mechanisms. Within a couple of years, the bank will be able to purchase infrastructure that implements the WS-* standards. I would avoid more elaborate intermediate solutions than the HTTP techniques, unless your application demands more. Unfortunately, about half of real applications do require more than HTTPS provides. For example, non-repudiation is a recurring theme at financial institutions, so most likely some systems might need to implement signed requests.

Question: If I'm developing a Web Services client to talk to Web services through an HTTP server that has basic auth on, how do I do it? I keep getting "403 Forbidden" unless the Web server admin disables the security. (submitted by PG)

Answer: If you are using code based on the Apache SOAP project, you can use an instance of a "Call" class. If you are building your clients with WebSphere Studio Application Developer (hereafter called Application Developer), you will see reference to the call object in the generated proxy class. The "Call" object allows you to set HTTP user ID and password for basic auth, and also similar methods to cater for intermediate HTTP proxies, if they exist. Unfortunately, the generated proxy does not provide any mechanism to expose the imbedded call object, so you need to add some code by hand to allow your application to access those methods on the call object. Beware that the way the generated proxy creates a Call object depends on whether you have chose to use synchronized methods or not. If you chose to use synchronized methods (the default), the proxy creates a single call object upon instatiation, then uses it for every method. If you chose to generate methods without the synchronized keyword, the generated proxy creates a new call object for every method invocation, so you'll need to initialize the HTTP user ID, etc, inside every method call.

Question: Axis WS-Security implementation is based on handlers so that you can don't have to change the code to secure it. But how can a SW artifact manage WS-Security related information? For instance, how do you know who signed the request, how do you know if the message is encrypted, how do you specify the credential to use to sign the response. When will WebSphere Application Server and WebSphere Studio Application Developer support WS-Security? As far as I know, version 5.0 doesn't support it yet. When will WS-Policy, WS-Trust, WS-Privacy be available? And when will they be integrated in IBM products? (submitted by PL)

Answer: First, let's look at the main question about how developers writing Web services get access to information in the headers of incoming requests and how they get to specify what goes in the headers of outgoing requests and replies. The way WebSphere Application Server (hereafter called Application Server) handles most of what you need is through configuration files. These are IBM extensions that allow you to specify such things as what certificate to use to sign or encrypt messages to a certain service, and what to expect back from the service in the reply. Naturally, the server side of the exchange has similar configuration files that allow it to authenticate incoming requests and sign and encrypt outgoing replies. This abstraction of the "infrastructure" requirements out of the "business code" and into the deployment domain makes sense in most situations, and is similar to the general J2EE world. For example, when writing EJBs, you typically do not care who invoked the EJB and are happy to rely on the container to determine if the call is authorized. When you do need to know who invoked you (for further authorization restriction, or some auditing type of requirement), you can call getCallerPrincipal(). You can use this same EJB API when implementing your Web services to determine the caller principal. Obviously, you need to implement your Web services as an EJB rather than just Java^TM beans. So in a nutshell, you don't get programmatic control over what keys to use, or what parts to include in the WS-Security header. However, you do get to specify those things declaratively in configuration files, which is mostly what you want. For those times when you need to know the principal associated with the incoming request, you can implement your Web service using EJBs, and then use getCallerPrincipal() to find out who invoked your service.

WebSphere Application Server V5 provides support for username token, X509, identity assertion, signatures and encryption as "technical previews", meaning that they are not supported. A Tech Preview is provided for development and planning purposes. The intention is that customers can use them to develop applications for deployment with a subsequent release of Application Server. IBM does not announce what features will be provided in releases before they ship, but I would expect these to be officially supported around the middle of 2003. IBM is continuing to work on the specifications outlined in the roadmap and once the specifications have been released, we will work on incorporating them in our products.

Question: What happens to LTPA functionality (e.g. not a browser client) or do you need to re-authenticate with each request? (submitted by IC)

Answer: Lightweight Third Party Authentication (LTPA) is an IBM proprietary solution to authentication. You should not use it in a generic Web services environment. The current state of the art is to use a Web Services Security (WS-Security) header in the SOAP Envelope Header to identify and authenticate the user with every request. This mechanism functions almost identically to an HTTP Basic Authentication header by providing a user name and password with every request. Future implementations will optionally incorporate Kerberos tickets or X.509 certificates for authentication. If you are implementing Web services "internally" and have control over the client code, you can configure Application Server to generate LTPA tokens and have the client return them in cookies. This allows Application Server to identify the user with each request. You would also have to consider your challenge mechanism to ensure it does not require user interaction. In a J2EE 1.3 environment (Application Server 5.x), J2EE introduces a Callback mechanism for this very sort of thing (in case users want to hook up their own mechanism for providing security information). In the meantime, basic auth, or certificates would work, but form based challenge is more complicated because you cannot send the authentication information with the Web service request. Using authentication mechanisms outside of the SOAP envelope (such as passing a cookie around) introduces a dependency on a particular protocol (HTTP). Increasingly, people are looking to use message based transports and offer "asynchronous" invocation options. To allow your Web service to work over various underlying protocols, make use of the WS-Security header for authentication, as it is passed with all protocols. Note that WebSphere's WS-Security implementation will be a Tech Preview for the 5.0 timeframe.

Question: When will WebSphere Studio Application Developer build tooling to allow XML Signatures, WS-I, etc? (submitted by KH)

Answer: Version 5.0 provides WS-Security headers with username tokens, x509 certs, identity assertions, dig sigs, and encryption as a Tech Preview. Expect a later version to include them as "supported."

Question: How do I express all this stuff in WSDL? Do the WSAD wizards build all this? (submitted by KH)

Answer: The Version 5 Tech Preview does not express security requirements in the Web Services Description Language (WSDL) files. It makes use of IBM extension files to indicate what security is provided or required by a service. The files are created by hand. In the future, look for a GUI tooling to create WS-SecurityPolicyAssertions either directly in WSDL, or separately and referenced from WSDL.

Question: How does it interoperate? (submitted by KH)

Answer: Although the runtime does not use WS-Policy to describe the elements of the WS-Security header (it uses IBM config files), the WS-Security headers produced conform to the current WS-Security proposal. They are compatible with other runtimes that support the WS-Security proposed standard.

Question: How do I propagate this through intermediaries? (submitted by KH)

Answer: Per the WS-Security specification, you can "address" WS-Security headers to specific actors. If you want to propagate your security information only as far as a particular intermediary, you can address a particular WS-Security header to that actor. You can have multiple WS-Security headers in a SOAP envelope. Intermediaries are welcome to add content to a WS-Security header bound for another actor, but they must not remove the header (per WS-Routing).

Question: What do I need to be careful of? Where are the holes? How secure am I? (submitted by KH)

Answer: We do not have a "supported" product, so do not take this into production yet. This is a changing space and the effort you invest in designing procedures to use it should take that into account. Expect the tooling to do a lot more for you in the future. The holes and how secure it is, I would say pretty secure. This is using mature technology in a clunky way, but it is still mature technology. If you're using the Tech Preview WS-Security header generation with X.509 certificates, you're in good shape. As always, having good technology is only the beginning. You need to make sure people are using it and that the key stores are secure.

Question: How can I pass trust on from one service to another? (submitted by KH)

Answer: The new standards that are emerging, WS-Trust and buddies, will provide a mechanism for delegating credentials.

Question: How much of this will work regardless of the protocol (JMS/SMTP/HTTP/xxx)? (submitted by KH)

Answer: All of it will work regardless of the transport protocol because it's wrapped up in the WS-Security header in the SOAP envelope. So in a sense, you're bound to SOAP. If you define Web services as "something described by WSDL", then more work needs to be done to describe and implement security for you in a consistent fashion across non-SOAP services.

Question: What is the best way to implement single sign-on for a Web service which calls other Web services? (submitted by RR)

Answer: By configuring the IBM extension config files on the intermediary Web service with the security needs of the "other" Web services, you are effectively providing "single sign on." The application code does not need to be concerned with authentication information.

Question: Which parts of WS-Security are supported in WebSphere Application Server 5.0 with Apache SOAP? (submitted by RR)

Answer: From a development point of view, IBM extends SOAP to make it easier to use, and to address some limitations with the implementation. From a "wire format" point of view, the messages generated from the IBM implementation is consumed by other implementations based on Apache SOAP and others. Now, WebSphere Studio Application Developer V5 will build proxies and servers that generate and check digital signatures and run on the SOAP implementation shipping with Application Server 5.0. The Tech Preview allows for digital signatures, encryption, uid/pw, X.509, ID assertion, and runs on top of a new run. This also ships with WebSphere Application Server V5, but there is no tooling support to generate the configuration files that specify what the WS-Security header should contain.

Question: How do I integrate WS-Security into my J2EE Application? (submitted by RR)

Answer: The Tech Preview shipping with Application Server 5.0 will create a security context for you. Use your normal J2EE authorization procedures to authorize access to Web services implemented as EJBs. If your Web service calls EJBs, the security context may or may not be propagated depending on the configuration of the called EJB.

Question: How can I restrict access for a single Web service to authorized users/roles? (submitted by RR)

Answer: Implement your Web service as an EJB, then configure (through the deployment descriptor and IBM extension files) access to the EJB as per standard EJB practices.

Question: I want to restrict access to view account information to the owners of an account. Is there a way to do this through configuration versus coding rules in my WebSphere Application Server Java^TM code? (submitted by RR)

Answer: Use the same options and restrictions when using EJBs directly. Tivoli provides a solution that relieves the business code from having to implement that kind of authorization extension. It's called Privacy Manager, and it integrates with WebSphere Application Server V5 authorization.

Question: What is the big deal about encrypting part of a Web services message? Why wouldn't I just use SSL between the requestor and the provider? (submitted by RR)

Answer: There are a couple of aspects to this. Firstly, sometimes only part of a message contains sensitive information, and so you are wasting cycles if you encrypt the whole message. Sometimes you want to route the message based on some of the content in the message. If the whole message is encrypted for the final recipient, intermediaries cannot use the message content for routing or other purposes. It is also possible that you expect more than one "actor" to act on the message you send, and you might want to encrypt different bits of the message for the different actors. Secondly, SSL provides a connection based solution to encryption, and so the encryption does not survive multiple hops nor being persisted. You might want to persist an encrypted or signed message for non-repudiation purposes.

Question: How do I setup secure exchange of messages between Microsoft.NET and WebSphere Application Server? In terms of encryption, authentication, and authorization? (submitted by RR)

Answer: Consult Microsoft^TM manuals to learn how to configure that product, but you configure the WebSphere technology through the IBM extension configuration files for authentication, encryption, and signing. You can configure authorization on WebSphere Application Server servers using a combination of the standard J2EE deployment descriptors and IBM extensions to those files.

Resources

• Web services interoperability between the WebSphere and .Net platforms
  
  
• Security in a Web Services World: A Proposed Architecture and Roadmap
  
  
• Web Services Security (WS-Security), Version 1.0
  
  
• Web Services Security Addendum
  
  
• W3C recommendation: XML-Signature Syntax and Processing
  
  
• W3C recommendation: Canonical XML Version 1.0
  
  
• W3C recommendation: Exclusive XML Canonicalization Version 1.0
  
  
• W3C candidate: XML Encryption Syntax and Processing
  
  
• W3C candidate: Decryption Transform for XML Signature
  
  

About the author

Tony Cowan is team lead for Web Services in the IBM Software Group.

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers