Policy sets are assertions about how services are defined.
They are used to simplify your quality of service configuration for
web services.
Note: You can use policy sets only with Java API
for XML-Based Web Services (JAX-WS) applications. You cannot use policy
sets with Java API for XML-based RPC (JAX-RPC)
applications.
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
that are 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
that are defined in the WSDL, but instead refer to messages that are
defined in other specifications which apply qualities of service (QoS).
Such QoS are the request security token (RST) messages that are defined
in WS-Trust, or create sequence messages that are defined in WS-Reliable
Messaging metadata exchange messages of the WS-MetadataExchange.
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.
An instance of a policy set consists of a collection of policies.
For example, the WS-I RSP default policy set consists of instances
of the WS-Security, WS-Addressing, and WS-ReliableMessaging policy
types. A policy set is identified by a unique name that is unique
across the cell. An empty policy set is a policy set with no policies
defined.
You can use a default policy set after it is imported. If you
want to change the properties for a default, not editable policy set,
you need to copy the policy set to create an editable version to modify.
See copy of default policy set and bindings settings. You can perform
the following actions on policy sets:
- create
- copy
- edit
- delete
- attach to service resources like applications
- detach from service resources like applications
- export
- import
Note which functions you can configure using policy sets and the
relationship of the security information that is configured. A set
of default policy sets are included that you can import; then copy
and rename for reuse. You can use a default policy set after it is
imported, but if you want to change any of the settings, you need
to copy the policy set to create an editable version. The configuration
can then be altered and customized on the copy.
Important: You
can only copy and customize policy sets using the administrative console
or administrative commands. Policy sets do not function correctly
if they are copied manually.
On the application server, policy sets are stored at the cell level.
Policy sets are centrally located so that they are available to all
applications on the server.
The following application policy sets are installed on the base
or network deployment (ND) profile by default: WS-I RSP or WS-I RSP
(ND), Username WSSecurity default, and WSHTTPS default. The WS-I RSP
(ND) is installed in a network deployment environment.
The following policy
sets are ready for you to use as is.
- LTPA WSSecurity Default
- Kerberos V5 HTTPS default
- SSL WSTransaction
- Username SecureConversation
- Username WSSecurity default
- WS-Addressing default
- WSHTTPS default
- WS-I RSP ND
- WS-ReliableMessaging persistent
The application server also provides other default policy sets
that you can use or customize. To use the additional policy sets,
you must import them from the default repository. Read about importing
policy sets from the administrative console for more information.
The following default policy sets are provided:
- WS-I RSP default
- This policy set provides:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity through digital signature that includes signing
the body, time stamp, WS-Addressing headers and WS-ReliableMessaging
headers using the WS-SecureConversation and WS-Security specifications
- Confidentiality through encryption that includes encrypting the
body, signature elements, using the WS-SecureConversation and WS-Security
specifications
- LTPA WS-I RSP default
- This policy set provides:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity through digital signature that includes signing
the body, time stamp, WS-Addressing headers and WS-ReliableMessaging
headers using the WS-SecureConversation and WS-Security specifications
- Confidentiality through encryption that includes encrypting the
body, signature elements, using the WS-SecureConversation and WS-Security
specifications
- A Lightweight Third Party Authentication (LTPA) token included
in the request message to authenticate the client to the service
- Username WS-I RSP default
- This policy set provides:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity through digital signature that includes signing
the body, time stamp, WS-Addressing headers and WS-ReliableMessaging
headers using the WS-SecureConversation and WS-Security specifications
- Confidentiality through encryption that includes encrypting the
body, signature elements, using the WS-SecureConversation and WS-Security
specifications
- A username token included in the request message to authenticate
the client to the service. The username token is encrypted in the
request
- SecureConversation
- This policy set provides:
- Message integrity through digital signature that includes signing
the body, time stamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality through encryption that includes encrypting
the body, signature and signature confirmation elements, using WS-SecureConversation
and WS-Security specifications
- LTPA SecureConversation
- This policy set provides:
- Message integrity through digital signature that includes signing
the body, time stamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality through encryption that includes encrypting
the body, signature and signature confirmation elements, using WS-SecureConversation
and WS-Security specifications
- A Lightweight Third Party Authentication (LTPA) token included
in the request message to authenticate the client to the service
- Username SecureConversation
- This policy set provides:
- Message integrity through digital signature that includes signing
the body, time stamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality through encryption that includes encrypting
the body, signature and signature confirmation elements, using WS-SecureConversation
and WS-Security specifications
- A username token included in the request message to authenticate
the client to the service. The username token is encrypted in the
request
- WSAddressing default
- Enables WS-Addressing support, which uses endpoint references
and message addressing properties to facilitate the addressing of
web services in a standard and interoperable way.
- WSHTTPS default
- Provides SSL transport security for the HTTP protocol with Web
services applications.
- Kerberos V5 HTTPS default
- This policy set provides message authentication with a Kerberos
Version 5 token. Message integrity and confidentiality are provided
by Secure Sockets Layer (SSL) transport security. This policy set
follows the OASIS Kerberos Token Profile V1.1 and WS-Security specifications.
When
you use this policy set, configure the basic authentication data and
custom properties such as the com.ibm.wsspi.wssecurity.krbtoken.targetServiceName
and com.ibm.wsspi.wssecurity.krbtoken.targetServiceHost custom properties
in the client bindings. For more information, see the Authentication
generator or consumer token settings and Protection token settings
(generator or consumer) topics.
- Kerberos V5 SecureConversation
- This policy set provides message integrity by digitally signing
the body, time stamp, and WS-Addressing headers. Message confidentiality
is provided by encrypting the body and the signature. The bootstrap
policy is configured with the Kerberos V5 token. This policy set follows
the WS-SecureConversation, OASIS specification for the Kerberos Token
Profile, in addition to the WS-Security specification.
To use this
policy set, you must also use the Client sample V2 and Provider sample
V2 general sample bindings for your applications. For more information,
refer to the topic General sample bindings for JAX-WS applications.
To use this new policy set,
create a new profile after installing the product.
To update
existing profiles with this new policy set and the general bindings,
Client sample V2 and Provider sample V2 general sample bindings, you
must complete some manual steps. You only need to update the deployment
manager profile and stand-alone application server profiles. To complete
the manual steps for an existing profile, refer to the topic Configuring
Kerberos policy sets and V2 general sample bindings.
- Kerberos V5 WSSecurity default
- This policy set provides message integrity by digitally signing
the body, time stamp, and WS-Addressing headers. Message confidentiality
is provided by encrypting the body and the signature using Advanced
Encryption Standard (AES) encryption. The derived key from the Kerberos
V5 token is used. This policy set follows the OASIS specification
for the Kerberos Token Profile, in addition to the WS-Security specification.
To
use this policy set, you must also use the Client sample V2 and Provider
sample V2 general sample bindings for your applications. For more
information, refer to the topic General sample bindings for JAX-WS
applications. To use this new policy set,
create a new profile after installing the product.
To update
existing profiles with this new policy set and the general bindings,
Client sample V2 and Provider sample V2 general sample bindings, you
must complete some manual steps. You only need to update the deployment
manager profile and stand-alone application server profiles. To complete
the manual steps for an existing profile, refer to the topic Configuring
Kerberos policy sets and V2 general sample bindings.
- TrustServiceKerberosDefault
- This policy set specifies the symmetric algorithm and the derived
keys to provide message security. Message integrity is provided by
digitally signing the body, time stamp, and WS-Addressing headers
using the HMAC-SHA1 algorithm. Message confidentiality is provided
by encrypting the body and signature using the Advanced Encryption
Standard (AES). This policy set follows the WS-Security and Secure
Conversation specifications for issuing and renewing trust operation
requests.
To use this policy set, you must also use the Client sample
V2 and Provider sample V2 general sample bindings for your applications.
For more information, refer to the topic General sample bindings for
JAX-WS applications. To use this new policy set, create a new profile after installing the product.
To
update existing profiles with this new policy set and the general
bindings, Client sample V2 and Provider sample V2 general sample bindings,
you must complete some manual steps. You only need to update the deployment
manager profile and stand-alone application server profiles. To complete
the manual steps for an existing profile, refer to the topic Configuring
Kerberos policy sets and V2 general sample bindings.
- WSReliableMessaging default
- This policy set enables both WS-ReliableMessaging Version 1.1 and WS-Addressing and uses the minimum quality of service, unmanaged non-persistent. This quality of service requires minimal configuration. However it is non-transactional and, although it allows for the resending of messages that are lost in the network, if a server becomes unavailable you will lose messages. This quality of service is for single server only and does not work in a cluster. In-order delivery is set to "false", so messages are not necessarily delivered in the order in which they were sent.
- WSReliableMessaging persistent
- This policy set enables both WS-ReliableMessaging and WS-Addressing and uses the maximum quality of service, managed persistent. This quality of service supports asynchronous web service invocations and uses a service integration messaging engine and message store to manage the sequence state. Messages are processed within transactions, are persisted at the web service requester server and at the web service provider server, and are recoverable in the event of server failure. In-order delivery is set to "false", so messages are not necessarily delivered in the order in which they were sent.
- Because this policy set specifies managed persistent quality of service, you have to define bindings to the service integration bus and messaging engine that you want to use to manage the WS-ReliableMessaging state. You can attach and bind a WS-ReliableMessaging policy set to a web service application by using the administrative console or the wsadmin tool.
- WSReliableMessaging 1_0
- This policy set enables both WS-ReliableMessaging Version 1.0 and WS-Addressing and uses the minimum quality of service, unmanaged non-persistent. This quality of service requires minimal configuration. However it is non-transactional and, although it allows for the resending of messages that are lost in the network, if a server becomes unavailable you will lose messages. This quality of service is for single server only and does not work in a cluster. In-order delivery is set to "false", so messages are not necessarily delivered in the order in which they were sent.
- You can use this policy set with .NET-based web services.
- WSSecurity default
- This policy set provides:
- Message integrity through digital signature (using RSA public-key
cryptography) to sign the body, time stamp, and WS-Addressing headers
using WS-Security specifications.
- Message confidentiality through encryption (using RSA public-key
cryptography) to encrypt the body, signature and signature elements
using WS-Security specifications.
- LTPA WSSecurity default
- This policy set provides:
- Message integrity through digital signature (using RSA public-key
cryptography) to sign the body, time stamp, and WS-Addressing headers
using WS-Security specifications.
- Message confidentiality through encryption (using RSA public-key
cryptography) to encrypt the body, signature and signature elements
using WS-Security specifications.
- A Lightweight Third Party Authentication (LTPA) token included
in the request message to authenticate the client to the service.
- Username WSSecurity default
- This policy set provides:
- Message integrity through digital signature (using RSA public-key
cryptography) to sign the body, time stamp, and WS-Addressing headers
using WS-Security specifications.
- Message confidentiality through encryption (using RSA public-key
cryptography) to encrypt the body, signature and signature elements
using WS-Security specifications.
- A username token included in the request message to authenticate
the client to the service. The username token is encrypted in the
request.
- WSTransaction
- This policy set enables WS-Transaction, which provides:
- The ability to coordinate distributed transactional work atomically
and interoperably using the WS-AtomicTransaction specification.
- The ability to coordinate loosely coupled business processes that
are distributed across the heterogenous web service environment, with
the ability to compensate actions if a failure occurs in the business
activity, using the WS-BusinessActivity specification.
- SSL WSTransaction
- This policy set enables WS-Transaction, which provides:
- The ability to coordinate distributed transactional work atomically,
interoperably, and securely, using the WS-AtomicTransaction specification
and SSL Transport security.
- The ability to coordinate loosely coupled business processes,
with the ability to compensate actions if a failure occurs in the
business activity, securely, using the WS-BusinessActivity specification
and SSL Transport security.
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.
Bindings are made up of environment and platform-specific information.
General bindings such as the service client or provider bindings for
the global security domain can be shared across applications.
To enable policy sets to work with applications, bindings are needed.
Use the administrative console to configure general bindings and application
specific bindings. Read about defining binding information for policy
sets for more information about working with attachments and bindings.