Web services security overview

The OASIS web services security (WSS) Version 1.0 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. WSS is a message-level standard that is based on securing 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.
Important: Applicable to WebSphere® Application Server traditional

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 and Kerberos, in heterogeneous environments such as Microsoft .NET and Java™ (Java EE). 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 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, and the XrML profile.

Enabling JAX-WS web services security using policy sets

In the V6.1 Feature Pack for Web Services and V7, WebSphere Application Server uses the policy set model for implementing the WSS 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 settings 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 Managing policy sets for JAX-WS web services and clients.

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 protects against modifications to a message while in transit. If the contents are altered illegally during a transmission, the signature is changed, and the receiver is notified.
Add XML encryption
XML encryption provides confidentiality for your web service; it makes 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 correct key.
Add a stand-alone security token
A stand-alone security token provides authentication for your web service; it validates the user and determines 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 user name and password are extracted from the token, and verified. The server verifies that the user name and password combination is valid and then accepts and processes 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 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.

For more information, see IBM Redbooks: Rational® Application Developer V7 Programming Guide.

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

When you create a web service with the web service wizard using the WebSphere runtime environments, you have the following security options:

  • None - This option does not enable security. This option is the only WS-I compliant option.
  • XML Digital Signature - This option provides integrity against elements of a SOAP message. You can then digitally sign elements in the SOAP message to protect integrity.
  • XML Encryption - With this option, you can encrypt elements of a SOAP message and propagate the encrypted data.
  • XML Digital Signature and XML Encryption - This option 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 an 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; do not use them in a production environment. They point to keystore and certificate files in WebSphere Application Server. For more information, see Default web services security configuration.

If you want to enable security for a web service in a production environment, see 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 more information, see Securing JAX-RPC web services manually based on WS-Security.

More information on securing web services

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


Feedback