Securing web services

Web services security for WebSphere® Application Server is based on standards included in the Organization for the Advancement of Structured Information Standards (OASIS) web services security (WSS) Version 1.0 specification, the Username token Version 1.0 profile, and the X.509 token Version 1.0 profile. These standards and profiles address how to provide protection for messages exchanged in a web service environment. The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message. web services security is a message-level standard based on securing Simple Object Access Protocol (SOAP) messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens. New in the Feature Pack for Web services, JAX-WS web services can be easily secured using policy sets.

To secure web services, you must consider a broad set of security requirements, including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, federation, delegation, and auditing across a spectrum of application and business topologies. One of the key requirements for the security model in today's business environment is the ability to interoperate between formerly incompatible security technologies (such as public key infrastructure, Kerberos and so on) in heterogeneous environments (such as Microsoft .NET and Java™ 2 Platform, Enterprise Edition (J2EE)). The complete web services security protocol stack and technology roadmap is described in Security in a Web Services World: A Proposed Architecture and Roadmap .

The Web Services Security: SOAP Message Security 1.0 specification outlines a standard set of SOAP extensions that you can use to build secure web services. These standards confirm integrity and confidentiality, which are generally provided with digital signature and encryption technologies. In addition, web services security provides a general purpose mechanism for associating security tokens with messages. A typical example of the security token is a username token, in which a user name and password are included as text. web services security defines how to encode binary security tokens using methods such as X.509 certificates and Kerberos tickets. However, the required security tokens are not defined in the web service security Version 1.0 specification. Instead, the tokens are defined in separate profiles such as the Username token profile, the X.509 token profile, the SAML profile, the Kerberos profile, the XrML profile and so on.

Enabling JAX-WS web services security using policy sets

In the v 6.1 Feature Pack for Web Services and v7, WebSphere Application Server uses the policy set model for implementing the Web Services Security Version 1.1 specification, the Username token Version 1.1 profile, and the X.509 token Version 1.1 profile. Policy sets combine configuration settings, including those for transport and message level configuration, such as WS-Addressing, WS-ReliableMessaging, WS-SecureConversation, and WS-Security.

To enable policy sets for your web services, refer to the following topic: Managing policy sets for JAX-WS web services and clients

Additionally, two samples and a tutorial are available which demonstrate policy sets.

The following book contains a chapter on policy sets in the WebSphere Application Server v6.1 Feature Pack for Web Services:IBM® Redbooks®: Web Services Feature Pack for WebSphere Application Server V6.1

Enabling JAX-RPC web services security using the web services security wizards

You can enable production-level security for your web services using the web services security wizards. These wizards provide you with the following options:

Add an XML digital signature: An XML digital signature provides integrity for your web service; it will protect against illegal modifications to a message while in transit. If the contents are altered illegally during a transmission, the signature is changed, and the receiver will be notified.
Add XML encryption: XML encryption provides confidentiality for your web service; it will make the transmitted data inaccessible or incomprehensible while it is being transmitted. The information is encrypted before it is sent over the web service, and decrypted when it arrives at the appropriate destination. The only way to access the encrypted information is with the proper key.
Add a stand alone security token: A stand alone security token provides authentication for your web service; it will validate the user, and determine whether a client is valid in a particular context. One primary form of authentication involves sending a user token to the web service server. The username and password are extracted from the token, and verified. The server verifies that the username and password combination is valid, and only then will the server accept and process the message.
Clone the security settings of another web service: If you are creating multiple web services and you want all of them to have the same security, you can choose to clone the security settings of a web service and apply them to another web service.

To enable web services security using the web service security wizards, refer to: Securing JAX-RPC web services using web services security wizards

More information including a practical example of using the wizards to apply security settings to a web service can be found here: IBM Redbooks: Rational® Application Developer V7 Programming Guide

Enabling JAX-RPC web services security in the web service creation wizards

When creating a web service with the web service Wizard using the WebSphere runtime environments, you have four security options:

None - this will not enable security. This is the only WS-I compliant option.
XML Digital Signature - this provides integrity against elements of a SOAP message. It allows you to digitally sign elements in the SOAP message protecting integrity.
XML Encryption - this allows you to encrypt elements of a SOAP message and propagate the encrypted data.
XML Digital Signature and XML Encryption - this combines the previous two options.

The web service client and web service must have the same setting for them to communicate with each other. For example, you cannot invoke a XML Digital Signature secured service if the client has a non-secured or XML encryption security setting.

The security options available through the wizard are for illustration purposes only - they should never be used in a production environment. They point to keystore and certificate files in WebSphere Application Server. For additional information on the default security configurations provided by WebSphere Application Server, refer to Default web services security configuration .

If you want to enable security for a web service in a production environment, refer to Securing web services using web services security wizards or Securing web services manually based on WS-Security .

Enabling JAX-RPC web services security manually

If the web services security wizards do not meet your needs, you have the option of manually securing your web services. This process gives you more control over the security settings, but is more time consuming and error prone than enabling security using the wizards.

For additional information on enabling web services security manually, refer to Securing JAX-RPC web services manually based on WS-Security

Additional information on securing web services

In addition to the information provided in this information centre, several useful tutorials and articles demonstrating how to secure web services using WebSphere Application Server are available on developerWorks®.