Secure web services using policy sets

Policy sets are assertions about how services are defined. They are used to simplify the quality of service configuration for web services.

Policy sets combine configuration settings, including those for transport and message level configuration, such as WS-Addressing, WS-ReliableMessaging, and WS-Security. There are two main types of policy sets; application policy sets and system policy sets. Application policy sets are used for business-related assertions. These assertions are related to the business operations defined in the Web Services Description Language (WSDL) file. System policy sets, on the other hand, are used for non-business-related system messages. These messages are not related to the business operations defined in the WSDL, but instead refer to messages defined in other specifications which apply qualities of service (QoS). Such QoS are the request security token (RST) messages defined in WS-Trust, or create sequence messages defined in WS-Reliable Messaging metadata exchange messages of the WS-MetadataExchange.

Use policy sets only with Java™ API for XML-Based Web Services (JAX-WS) or Service Component Architecture (SCA) applications. We cannot use policy sets with Java API for XML-based RPC (JAX-RPC) applications.

Policies are defined based on a quality of service. Policy definition is typically based on WS-Policy standard language, for example, the WS-Security policy is based on the current WS-SecurityPolicy from the Organization for the Advancement of Structured Information Standards (OASIS) standards.

Policy sets do not include environment or platform-specific information, such as keys for signing, keystore information, or persistent store information. This type of information is defined in the binding. A policy set attachment defines how a policy set is attached to service resources and bindings. The attachment definition is outside the policy set definition and is defined as meta-data associated with application data.

To secure JAX-WS web services with message-level security using policy sets:

1. Select, create, or copy and modify a policy set to specify the message-level protection required. The policy specifies what protection will be applied, for example, what message parts to sign or encrypt and the token types and algorithms to use.

   • Select one of the web services policy sets.

   • Create, copy, modify, import, export or delete a policy set. For more information, read about managing policy sets using the administrative console

2. Attach the policy set to the application.

3. Create or select the policy set bindings to be used. The bindings are then attached to the application along with the policy set. The bindings used can either be general bindings that can be shared among applications or application specific bindings. For more information, read about defining and managing policy set bindings.

4. If WS-SecureConversation is being used, specify the trust service system policy sets and bindings on the application server.

Subtopics

• Get Started: Use a policy set and default bindings to sign and encrypt a message
  This procedure describes how to configure the message-level WS-Security policy set and bindings to sign and encrypt a SOAP message that uses a custom policy set and default bindings. This task is intended to help get familiar with adding WS-Security constraints to a JAX-WS application.

• Configure a policy set and bindings for a stand-alone security token (UsernameToken or LTPA Token)
  We can secure web services by configuring the message-level WS-Security policy set and bindings for a stand-alone security token that is either a LTPA token or a Username token.

• Configure a policy set and bindings to consume an LTPA and/or UsernameToken (optional security tokens)
  This procedure describes how to configure the message-level WS-Security policy set and bindings to consume an LTPA token, a UsernameToken or both. This procedure can be modified to apply to any pair of dissimilar token value types. We cannot create a configuration that will make one token required and the other optional.

• Configure a policy set and bindings for XML Digital Signature with client and provider application specific bindings
  We can create a custom policy set and application specific bindings for using XML Digital Signature to sign the body of the request and response SOAP messages.

• Configure a policy set and bindings for Asymmetric XML Digital Signature and/or XML Encryption
  This procedure describes how to configure the message-level WS-Security policy set and bindings to sign and encrypt a SOAP message using asymmetric XML Digital Signature and Encryption with application specific bindings. As part of this procedure specify whether you will sign and/or encrypt both the request and response messages.

• Configure a policy set and bindings for Asymmetric XML Digital Signature and/or XML Encryption with client and provider general bindings
  This procedure describes how to configure the message-level WS-Security policy set and bindings to sign and encrypt a SOAP message by using asymmetric XML Digital Signature and Encryption by using general bindings. As part of this procedure specify whether you sign and encrypts or sign or encrypt both the request and response messages.

• Configure policy set and bindings to encrypt a UsernameToken
  This example shows how to configure the message-level WS-Security policy set and bindings to send a Username token in a JAX-WS request, and to encrypt the Username token using asymmetric encryption.

• Configure a policy set and bindings for Signer Certificate Encryption
  This procedure describes how to configure a JAX-WS consumer/provider for signer certificate encryption. Signer certificate encryption means that the client's public certificate used to verify the digital signature of the inbound request message is used to encrypt the outbound response.

• Configure the username and password for WS-Security Username or LTPA token authentication
  When using the Username WSSecurity default policy set, configure the username and password for username token authentication separately from the security settings defined in the bindings.

• Enable or disable single sign-on interoperability mode for the LTPA token
  We can set an interoperability flag on the token generator to determine whether an LTPA Version 1 token or an LTPA Version 2 token is retrieved when a request message is received.

Related concepts

JAX-WS

Web services policy sets

Related tasks

Secure requests to the trust service using system policy sets

Manage policy sets using the administrative console

Attaching a policy set to a service artifact

Define and manage policy set bindings