Service policies web services preferences

The Preferences > General > Service policies 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

Important: Applicable to WebSphere® Application Server traditional

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 Import > Web services > WebSphere named bindings. 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 Application Server policy sets

Important: Applicable to WebSphere Application Server traditional

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 Application Server 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 Application Server System 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 later method exposure guidance
JAX-WS 2.1.6 and later 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

Icon that indicates the type of topic Reference topic
Timestamp icon Last updated: July 17, 2017 21:58

File name: rqospref.html