The page allows you to set WS-I, and policy set, and binding
defaults.
Profile compliance
This section of the service
policies page can be used to set the level of WS-I compliance. For
more information on WS-I, refer to their Web site: http://www.ws-i.org/.
- WS-I AP 1.0 (WS-I Attachments Profile 1.0)
- Supports interoperable SOAP messages with attachments-based web
services.
- WS-I BP 1.1 + SSBP 1.0 (WS-I Basic Profile and WS-I Simple SOAP
Binding Profile)
- This includes the basic profile and requirements related to the
serialization of an envelope and its representation in a SOAP message.
- WS-I BP 1.2 (WS-I Basic Profile)
- The WS-I Basic Profile 1.2 builds on Basic Profile 1.1 by incorporating
Basic Profile 1.1 errata and requirements from Simple SOAP Binding
Profile 1.0, and adding support for WS-Addressing and MTOM.
- WS-I BP 2.0 (WS-I Basic Profile)
- The WS-I Basic Profile 2.0 consists of a set of non-proprietary
web services specifications, along with clarifications, refinements,
interpretations and amplifications of those specifications which promote
interoperability.
- WS-I BSP 1.0 (WS-I Basic Security Profile)
- The Basic Security Profile 1.0 provides guidance on the use of
WS-Security and the REL, Kerberos, SAML, UserName and X.509 security
token formats.
For each profile you can select from three levels
of compliance with WS-I specifications:
- Require WS-I compliance - this level prevents you from creating
a non-compliant web service.
- Suggest WS-I compliance - this level allows you to create a non-compliant
web service, but provides a visible warning stating how the service
is non-compliant.
- Ignore WS-I compliance - this level allows you to create a non-compliant
web service and does not notify you of non-compliance.
WebSphere general
bindings
Policy set bindings contain platform specific information,
like keystore, authentication information or persistent information,
required by a policy set attachment. General bindings, new in WebSphere® Application Server
v7.0, can be configured to be used across a range of policy sets and
can be reused across applications and for trust service attachments.
Although general bindings are highly reusable, they do not provide
configuration for advanced policy requirements, such as multiple signatures.
Bindings
can be created in the WebSphere Application
Server administrative console and then optionally imported into the
development workspace using . Once service and client bindings have been created,
you can apply them to the entire workspace or a single project as
the default binding using the Service policies preference page.
The
sample general bindings shipped with the product are the following:
Important: - The general bindings that are shipped with the product are provider
and client sample bindings. These bindings are initially set as the
cell default bindings. Do not use these bindings in their current
state in a production environment. To use the sample bindings, modify
them to meet your security needs in a production environment. Alternatively,
create a copy of the bindings and then modify the copy.
- You cannot assign a binding to a service provider resource that
does not have a policy set or has an inherited attachment. To assign
a binding to such a service provider resource, you must first attach
a policy set to the resource. Also, you cannot assign a binding to
a service client resource that does not have an effective policy configuration
or has an inherited policy attachment. To assign a binding to such
a service client resource, you must first attach a policy set or specify
the use of the provider policy.
For more information on general bindings and how
to create them, refer to the WebSphere Application
Server v7.0 documentation topic: Defining and managing policy set bindings.
WebSphere policy
sets
You can use the preferences page to select the default
policy set for web services and clients. Several policy sets are included
with the workbench by default when you choose to install a runtime
or stub, while additional policy sets can be imported.
The
following policy sets are included with the workbench:
- WebSphere v6.1 Policy
Sets
- LTPA RAMP default. This policy set provides the following
features:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity by digital signature that includes signing the
body, timestamp, WS-Addressing headers and WS-ReliableMessaging headers
using the WS-SecureConversation and WS-Security specifications
- Confidentiality by encryption that includes encrypting the body,
signature and signature confirmation 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
- LTPA SecureConversation. This policy set provides the following
features:
- Message integrity by digital signature that includes signing the
body, timestamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality by 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
- LTPA WSSecurity default. This policy set provides the following
features:
- Message integrity by digital signature (using RSA public-key cryptography)
to sign the body, timestamp, and WS-Addressing headers using WS-Security
specifications
- Message confidentiality by encryption (using RSA public-key cryptography)
to encrypt the body, signature and signature confirmation elements
using WS-Security specifications
- A Lightweight Third Party Authentication (LTPA) token included
in the request message to authenticate the client to the service
- RAMP default: Default Reliable Asynchronous Messaging Profile
(RAMP) 1.0. This policy set provides the following features:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity by digital signature that includes signing the
body, timestamp, WS-Addressing headers and WS-ReliableMessaging headers
using the WS-SecureConversation and WS-Security specifications
- Confidentiality by encryption that includes encrypting the body,
signature and signature confirmation elements, using the WS-SecureConversation
and WS-Security specifications
- 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.
- SecureConversation. This policy set provides the following
features:
- Message integrity by digital signature that includes signing the
body, timestamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality by encryption that includes encrypting
the body, signature and signature confirmation elements, using WS-SecureConversation
and WS-Security specifications
- Username RAMP default. This policy set provides the following
features:
- Reliable message delivery to the intended receiver by enabling
WS-ReliableMessaging
- Message integrity by digital signature that includes signing the
body, timestamp, WS-Addressing headers and WS-ReliableMessaging headers
using the WS-SecureConversation and WS-Security specifications
- Confidentiality by encryption that includes encrypting the body,
signature and signature confirmation elements, using the WS-SecureConversation
and WS-Security specifications
- A user name token included in the request message to authenticate
the client to the service. The user name token is encrypted in the
request
- Username SecureConversation. This policy set provides the
following features:
- Message integrity by digital signature that includes signing the
body, timestamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality by 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
- Username WSSecurity default. This policy set provides the
following features:
- Message integrity by digital signature (using RSA public-key cryptography)
to sign the body, timestamp, and WS-Addressing headers using WS-Security
specifications
- Message confidentiality by encryption (using RSA public-key cryptography)
to encrypt the body, signature and signature confirmation 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
- WSAddressing default. This policy set 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. This policy set provides SSL transport
security for the HTTP protocol with web services applications.
- WSReliableMessaging 1_0. This policy set enables both WS-ReliableMessaging
Version 1.0 and WS-Addressing, and it uses the minimum quality of
service unmanaged non-persistent. This quality of service requires
minimal configuration. This quality of service is non-transactional,
however. Although it allows for the re-sending of messages that are
lost in the network, failure of a server results in lost messages.
This quality of service is for single-server use only; it does not
work in a cluster. You can use this policy set with .NET-based web
services.
- WSReliableMessaging default. This policy set enables both
WS-ReliableMessaging and WS-Addressing, and the policy set 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 re-sending of messages that are lost
in the network, failure of a server results in lost messages. This
quality of service is for single server only; it does not work in
a cluster.
- WSReliableMessaging persistent. This policy set enables
both WS-ReliableMessaging and WS-Addressing, and the policy set 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.
- WSSecurity default. This policy set provides the following
features:
- Message integrity by digital signature (using RSA public-key cryptography)
to sign the body, timestamp, and WS-Addressing headers using WS-Security
specifications
- Message confidentiality by encryption (using RSA public-key cryptography)
to encrypt the body, signature and signature confirmation elements
using WS-Security specifications
- WSTransaction. This policy set enables WS-Transaction,
which provides the ability to coordinate distributed transactional
work atomically and interoperably using the WS-AtomicTransaction specification.
- WebSphere v7.0 and
v8.0 Policy Sets
- 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 in the WebSphere Application Server Information
Center.
- LTPA WSSecurity default. This policy set provides the following
features:
- Message integrity by digital signature (using RSA public-key cryptography)
to sign the body, timestamp, and WS-Addressing headers using WS-Security
specifications
- Message confidentiality by encryption (using RSA public-key cryptography)
to encrypt the body, signature and signature confirmation elements
using WS-Security specifications
- A Lightweight Third Party Authentication (LTPA) token included
in the request message to authenticate the client to the service
- 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.
- Username SecureConversation. This policy set provides the
following features:
- Message integrity by digital signature that includes signing the
body, timestamp, and WS-Addressing headers using WS-SecureConversation
and WS-Security specifications
- Message confidentiality by 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
- Username WSSecurity default. This policy set provides the
following features:
- Message integrity by digital signature (using RSA public-key cryptography)
to sign the body, timestamp, and WS-Addressing headers using WS-Security
specifications
- Message confidentiality by encryption (using RSA public-key cryptography)
to encrypt the body, signature and signature confirmation 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
- WS-I RSP This policy set enables WS-ReliableMessaging Version
1.1 and uses the minimum quality of service, unmanaged non-persistent,
which provides the ability to deliver a message reliably to its intended
receiver. This policy set only works in a single server environment
and does not work in a clustered environment. 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.
In-order delivery is set to "false", so messages are not necessarily
delivered in the order in which they were sent. Message integrity
is provided by digitally signing the body, the time stamp, and the
WS-Addressing headers. Message confidentiality is provided by encrypting
the body and the signature. This policy set follows the WS-SecureConversation
and WS-Security specifications.
- WSAddressing default. The WSAddressing default policy set
provides a transport-neutral way to uniformly address web services
and messages. This policy set 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 This policy set provides SSL transport
security for the HTTP protocol with web services applications.
- 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 WebSphere Application
Server administrative console or the wsadmin tool.
- WebSphere v7.0 v8.0System
Policies
- SystemWSSecurityDefault This system policy set specifies
the asymmetric algorithm and both the public and private keys to provide
message security. Message integrity is provided by digitally signing
the body, time stamp, and WS-Addressing headers using RSA encryption.
Message confidentiality is provided by encrypting the body and signature
using RSA encryption. This policy set follows the WS-Security specifications
for the issue and renew trust operation requests.
For more information
on system policy sets, refer to: System policy sets
WebSphere Programming
Models
- JAX-WS annotation scanning message severity
- Use this preference to set the level of error message generated
for JAX-WS annotation scanning.
The WebSphere JAX-WS runtime scans Web applications
for JAX-WS annotations when the application is added to WebSphere Application server. For performance
reasons WebSphere Application
Server does not scan all projects for annotations by default. On WebSphere Application Server
v7 and later, version 2.4 web modules are not scanned unless the UseWSFEP61ScanPolicy property
is set to true in the MANIFEST.MF file. To inform
you that WebSphere is
not performing an annotation scan, the workbench adds an error marker.
However
if you are using a non-WebSphere implementation of the JAX-WS runtime,
this error message is invalid, and may prevent you from publishing
to WebSphere Application
Server. Use this preference to change the level of error message severity
for your workspace or project so that you can publish successfully.
- Provide JAX-WS 2.1.6 and above method exposure guidance
- JAX-WS 2.1.6 and above assistance can now be enabled when this
is set to true. When this support is turned
on, warnings will be issued for methods in Java™ classes that will be implicitly exposed
as a result of the new specification and a quickfix will be available
to hide these methods and preserve the web service interface from
prior JAX-WS standards.
For more information on JAX-WS 2.1.6 refer
to: Java API for XML based web services