Index Changes

Using the HTTP Binding Component

Contents


HTTP Binding Component Security



The HTTP Binding Component provides external connectivity between the JBI environment and external environments. To ensure that transactions are secure, the HTTP Binding Component employs both transport and message security.

  • Transport Layer Security provides mechanisms to secure network transactions between clients and servers, such as the username/password used in HTTP Basic authentication and authorization.
  • Message Layer Security uses security information contained within the message or message attachment, such as the UsernameToken used in SOAP Message Security.

Using Basic Authentication with the HTTP Binding Component

Basic authentication enables you to require credentials, in the form of a username and password, to make a transaction. These credentials are transmitted as plain text. The username and password are encoded as a sequence of base-64 characters before transmission to ensure privacy. So, for example, the user name “Fred” and password “Dinosaur” are combined as “Fred:Dinosaur.” When encoded in base-64, these characters are equivalent to “RnJlZDpEaW5vc2F1cg0K”.

For a Provider web service, a request message from a client contains the user name and password fields in the request header.

For a Consumer web service invoking a web service with basic authentication enabled, the user name and password are appended to the request headers for authentication.

For more information on basic authentication protocol see RFC 1945 (Hypertext Transfer Protocol HTTP/1.0), RFC 2616 (Hypertext Transfer Protocol HTTP/1.1), and RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).

Basic Authentication Supported Features

Basic authentication is supported by specifying a policy in the WSDL. A basic authentication policy can be added to the WSDL either manually or by using the WS-Policy Attachment window accessed from CASA and provided through Tango (WSIT). A basic authentication policy is specified at the root level of the WSDL and a reference to the policy is made in the WSDL Port type section, binding the policy to the endpoint.

To support basic authentication, the HTTP Binding Component defines the following WSDL elements:

  • MustSupportBasicAuthentication: This element has an attribute called on which can be used to turn authentication on or off. This attribute accepts the values true or false. The MustSupportBasicAuthentication element within a policy is required to enable basic authentication in the endpoint.
  • UsernameToken: This element specifies the user name and password fields for one of the following actions:
    • Authenticate the request when the endpoint is a provider
    • Invoke a web service with basic authentication enabled when the configured endpoint is a consumer
      The user name and password fields can be specified either as plain text in the WSDL, or as tokens in the WSDL and configured at runtime.

Authentication Mechanisms for Consumer Endpoints

Four types of authentication mechanisms are supported for web service consumer endpoints.

A consumer endpoint can be configured to use one of these mechanisms by adding it as a child element to the MustSupportBasicAuthentication element of the endpoints Policy.

  • WssTokenCompare Username/Password Authentication: Compares the username and password extracted from the HTTP Authorization request header with the username and password specified in the Policy's WssUsernameToken10 and WssPassword elements.
  • Access Manager: Configures the consuming endpoint to use the Sun Access Manager to authenticate the HTTP client's credentials.
  • OpenSSO Web Services Security (WSS) Agent: Configures the consuming endpoint to use the OpenSSO Web Services Security Agent to authenticate the HTTP client's credentials.
  • Realm: Configures the consuming endpoint to use the Sun Realm security to authenticate the HTTP client's credentials.

The following sections describe these mechanisms in more detail.

WssTokenCompare Username/Password Authentication

To use the WssTokenCompare feature, the Policy element must be present, and specify the username and password that are used for authentication. The username and password extracted from the HTTP Authorization request header are compared with the username and password specified in the Policy's WssUsernameToken10 and WssPassword elements.

The following sample WSDL contains the policy and its reference to use WssTokenCompare. Note that an application variable token is used for the password so that the password is not exposed in the WSDL. The value of the password can be specified in the component's Application Variable property in NetBeans.

<wsdl:service name="echoService">
   <wsdl:port name="echoPort" binding="tns:echoBinding">
       <soap:address location="http://pponnala-tecra-xp.stc.com:18181/echoService/echoPort"/>
       <wsp:PolicyReference URI="#HttpBasicAuthBindingBindingPolicy"/>
   </wsdl:port>
</wsdl:service>

<wsp:Policy wsu:Id="HttpBasicAuthBindingBindingPolicy">
   <mysp:MustSupportBasicAuthentication on="true">
       <mysp:BasicAuthenticationDetail>
          <mysp:WssTokenCompare/>
       </mysp:BasicAuthenticationDetail>
   </mysp:MustSupportBasicAuthentication>
   <mysp:UsernameToken mysp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
           <sp:WssUsernameToken10>wilma</sp:WssUsernameToken10>
           <sp:WssPassword>${pass_token}</sp:WssPassword>
      </wsp:Policy>
 </mysp:UsernameToken>
</wsp:Policy>

Using Access Manager for Authentication and Authorization

To use Access Manager to configure access-level authorization, you configure the consuming endpoint to use the Sun Access Manager to authenticate the client's credentials. The HTTP Binding Component SOAP binding integrates seamlessly with Sun Access Manager to authenticate the HTTP client's credentials (the username and password extracted from the HTTP Authorization header) against the user's credentials in the Sun Access Manager database.

Installing the Access Manager Add-on

Access Manager is installed as an GlassFish add-on which includes the Access Manager Server and JAR files. To install Access Manager, do the following:

  1. Download the standalone (15 MB) Sun Java System Access Manager 7.1 Patch 1.
  2. Extract the access_manager-7_1–p01–rr.zip file to the following directory: /GlassFishESBv21/glassfish/bin/accessmanager
  3. Install the Access Manager add-on to GlassFish using the following asadmin command from your CLI: /GlassFishESBv21/glassfish/bin/asadmin install-addon /accessmanager/am_installer.jar
    Access Manager is extracted into /GlassFishESBv21/glassfish/addons/accessmanager with the necessary JAR files and AMConfig.properties.
  4. Restart the GlassFish server. Upon restart the post-configuration is done automatically for Access Manager

Installing Access Manager with Java Application Platform SDK

You can also download Access Manager as part of the Java Application Platform SDK installation, following the SDK Update 7 Installation Instructions. Upon installation, the Access Manager is available in the SDK install directory in the addons/accessmanager directory.

To configure and deploy the Access Manager instance that is installed with the SDK package from GlassFish ESB, modify the server.policy file of GlassFish from GlassFish ESB as follows:

From the Command Line:

  1. Copy (cp) /GlassFishESB21/glassfish/domains/domain1/config/server.policy to /GlassFishESB21/glassfish/domains/domain1/config/server.policy.Orig
  2. Cat /~<SDK_location>/addons/accessmanager/as9.0_serverpolicy to /GlassFishESB21/glassfish/domains/domain1/config/server.policy.
  3. Autodeploy amserver.war.
    Copy (cp) /~<SDK_location>/addons/accessmanager/amserver.war to /GlassFishESB21/glassfish/domains/domain1/autodeploy
  4. Restart GlassFish
    /GlassFishESB21/stop_glassfish_domain1
    /GlassFishESB21/start_glassfish_domain1

Configure the HTTP Binding Component to use Access Manager

To configure the Sun Access Manager Configuration Directory, do the following:

  1. Access the HTTP Binding Component Properties from the NetBeans Services window. Right-click sun-http-binding under Servers → GlassFish → JBI → Binding Components, and choose Properties from the pop-up menu.
  2. Configure the Sun Access Manager Configuration Directory property to specify the location of the Sun Access Manager's AMConfig.properties file. For example: C:/GlassFishESBv21/glassfish/addons/accessmanager
    Configure the Sun Access Manager Configuration Directory property to point to the directory that contains the the AMConfig.properties file. For example: C:/GlassFishESBv21/glassfish/addons/accessmanager
  3. Configure the Sun Access Manager Classpath property to point to the following JAR files extracted to the /GlassFishESBv21/glassfish/addons/accessmanager directory:
    • amclientsdk.jar
    • amWebServicesProvider.jar
      Note that the two files must be separated by a comma.
      Image shows the HTTP Binding Component Properties Editor as described in context

  4. Modify the AMConfig.properties file as needed to connect to Access Manager. At a minimum, the following properties must be configured:

    com.iplanet.am.naming.url=@PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/namingservice com.sun.identity.agents.app.username=@APPLICATION_USER@ com.iplanet.am.service.password=@APPLICATION_PASSWD@ am.encryption.pwd=@ENCRYPTION_KEY@ com.iplanet.am.server.protocol=@SERVER_PROTOCOL@ com.iplanet.am.server.host=@SERVER_HOST@ com.iplanet.am.server.port=@SERVER_PORT@ com.iplanet.am.services.deploymentDescriptor=@DEPLOY_URI@ com.sun.identity.loginurl=@SERVER_PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/UI/Login com.sun.identity.liberty.authnsvc.url=@SERVER_PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/Liberty/authnsvc

  5. Configure the policy in the WSDL to enable Authorization by changing the Access Manager authorization attribute to true (note the attribute authorization="true" in the example below). This attribute is optional and the default value is false.

The following sample WSDL contains the policy and its reference to use Access Manager.

&lt;service name="AuthAMService">
    &lt;port name="AuthAMPort" binding="tns:AuthAMBinding">
        &lt;soap:address location="http://localhost:${HttpDefaultPort}/AuthAMService
/AuthAMPort"/>
        &lt;wsp:PolicyReference URI="#HttpAuthorizationBindingAMPolicy"/>
    &lt;/port>
&lt;/service>
&lt;wsp:Policy wsu:Id="HttpAuthorizationBindingAMPolicy">
    &lt;mysp:MustSupportBasicAuthentication on="true">
        &lt;!-- authenticationType is one of simple, am, or realm -->
        &lt;mysp:BasicAuthenticationDetail>
            &lt;mysp:AccessManager authorization="true"/>
        &lt;/mysp:BasicAuthenticationDetail>
    &lt;/mysp:MustSupportBasicAuthentication>
&lt;/wsp:Policy>

For more information on HTTP Binding Component authorization using Sun Access Manager, and Access Manager Classpath configuration, see: HTTP BC Access Manager Authorization.

Note - When OpenSSO Enterprise Server is running on an HTTPS port, the certificates on the OpenSSO Enterprise server must be installed on the client side in order for the HTTP Binding Component to access the server. Certificates should be installed in the GlassFish domain config directory. For example: \GlassFishESBv21\glassfish\domains\domain1\config.


Using OpenSSO Web Services Security (WSS) Agent for Authentication and Authorization

To configure access-level authorization using OpenSSO Web Services Security Agent, you configure the consuming endpoint to use OpenSSO WSS Agent to authenticate the client's credentials (the username and password extracted from the HTTP Authorization header) against the user's credentials in the WSS Agent database. OpenSSO Web Services Security Agent allows the HTTP Binding Component to talk to OpenSSO Enterprise Server 8 installed on a remote or local computer.

Install OpenSSO Enterprise Server

To use the OpenSSO Web Services Security Agent, first download and install OpenSSO Enterprise Server following the directions and requirements presented in the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Configure the HTTP Binding Component to use OpenSSO Web Service Security

With OpenSSO Enterprise Server installed, you can now configure the HTTP Binding Component to use the OpenSSO WSS Agent. The OpenSSO WSS Agent file contains the client configuration AMConfig.properties, and OpenSSO ClientSDK, that allow web service providers and clients to easily integrate, to validate and secure web service communications.

  1. Download openssowssproviders.zip. This file is available from http://download.java.net/general/opensso/stable/opensso-build6/openssowssproviders.zip, or you can go to the OpenSSO Download page and click WSS Agent to download the zip file.
  2. Create a directory, such as /GlassFishESB/WSSAgent_OpenSSO/, and extract the contents of the openssowssproviders.zip file into it.
  3. From the NetBeans Services window, make sure that the GlassFish server is started. If not, right-click GlassFish and choose Start from the pop-up menu.
  4. Open the HTTP Binding Component Properties. To do this, expand Servers → GlassFish → JBI → Binding Components in the Services window, right-click sun-http-binding and select Properties from the pop-up menu.
    The HTTP Binding Component Properties Editor appears.
  5. Configure the Sun Access Manager Classpath property to point to the following JAR files that you extracted to the WSSAgent_OpenSSO directory:
    • openssoclientsdk.jar
    • openssowssproviders.jar

      Note that the two files must be separated by a comma.
      Image shows the HTTP Binding Component Properties Editor as described in context
  6. Configure the Sun Access Manager Configuration Directory property to point to the directory that contains the the AMConfig.properties file. This is located in the ./resources directory extracted to the WSSAgent_OpenSSO directory.
    Image shows the Sun Access Manager Configuration Directory property custom editor, as described in context

  7. Modify the AMConfig.properties file as needed to connect to OpenSSO Enterprise Server. At a minimum, the following properties must be configured:

    com.iplanet.am.naming.url=@PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/namingservice com.sun.identity.agents.app.username=@APPLICATION_USER@ com.iplanet.am.service.password=@APPLICATION_PASSWD@ am.encryption.pwd=@ENCRYPTION_KEY@ com.iplanet.am.server.protocol=@SERVER_PROTOCOL@ com.iplanet.am.server.host=@SERVER_HOST@ com.iplanet.am.server.port=@SERVER_PORT@ com.iplanet.am.services.deploymentDescriptor=@DEPLOY_URI@ com.sun.identity.loginurl=@SERVER_PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/UI/Login com.sun.identity.liberty.authnsvc.url=@SERVER_PROTOCOL@://@SERVER_HOST@:@SERVER_PORT@/@DEPLOY_URI@/Liberty/authnsvc

  8. Restart GlassFish and HTTP BC and test the modifications.


Using GlassFish Realm Security to Authenticate the HTTP Client Credentials

The HTTP Binding Component can integrate with GlassFish Application Server, out of the box, to provide authentication of requesting clients by authenticating the client against the credentials in a "realm". To take advantage of this security feature, the HTTP/SOAP Binding Component's consuming endpoint needs to be properly configured in the WSDL.

To configure an HTTP/SOAP endpoint to use Realm security configure the PolicyReference element which belongs in the namespace, http://schemas.xmlsoap.org/ws/2004/09/policy. The PolicyReference identifies the Policy, which also belongs in the namespace, http://schemas.xmlsoap.org/ws/2004/09/policy, that provides the details for configuring Realm security.

This is an example of an endpoint with an associated PolicyReference element.

<port name="SoapBasicAuthPortRealm" binding="tns:SoapBasicAuthRealmBinding">
   <soap:address location="http://localhost:12081/SoapBasicAuthService/SoapBasicAuthRealmPort"/>
   <wsp:PolicyReference URI="#HttpBasicAuthBindingBindingRealmPolicy"/>
</port>

The PolicyReference element contains an attribute called URI. The value of the URI consists of a '#' character followed by the name of the policy defined somewhere else in the WSDL. Taking this example further, the example below defines the Policy that the PolicyReference references. In the following example, ignore the UsernameToken. This is used by the "outbound" endpoint for sending the username/password credential when it sends a request. You don't need to have this element for "inbound" (consuming) endpoints, but it's included here to illustrate the bi-directionality of an endpoint.

<wsp:Policy wsu:Id="HttpBasicAuthBindingBindingRealmPolicy">
   <mysp:MustSupportBasicAuthentication on="true">
       <mysp:BasicAuthenticationDetail>
          <mysp:Realm realmName="file" />
       </mysp:BasicAuthenticationDetail>
   </mysp:MustSupportBasicAuthentication>
   <mysp:UsernameToken mysp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
           <sp:WssUsernameToken10>wilma</sp:WssUsernameToken10>
           <sp:WssPassword>pebbles</sp:WssPassword>
      </wsp:Policy>
   </mysp:UsernameToken>
</wsp:Policy>

The PolicyReference and Policy elements are used above simply to ensure that we adhere to the standard for SOAP binding. There are no Tango WS-Policy Attachments involved and the WS-Policy Attachment "runtime" will ignore the child element MustSupportBasicAuthentication which is specific to the HTTP Soap BC. MustSupportBasicAuthentication is in the namespace, http://sun.com/ws/httpbc/security/BasicauthSecurityPolicy.

For example, your GlassFish installation comes with a preconfigured file realm which is essentially a file-based user database. See the Realms, or for a demonstration of how Realm security is configured for a SOAP endpoint see Securing Communications in Open ESB with Glassfish Realm Security.

Configuring Security Mechanisms

This section discusses the following Security Mechanisms available through Tango, and the server configuration options for each selection. For more information on any of these security mechanisms, see Metro Security Mechanisms The available security mechanisms are:

  • Username Authentication with Symmetric Key
  • Mutual Certificates Security
  • Transport Security (SSL)
  • Message Authentication over SSL
  • SAML Authorization over SSL
  • Endorsing Certificate
  • SAML Sender Vouches with Certificates
  • SAML Holder of Key
  • STS Issued Token
  • STS Issued Token with Service Certificate

Username Authentication with Symmetric Key

The Username Authentication with Symmetric Keys mechanism protects your application for integrity and confidentiality. Symmetric key cryptography relies on a single, shared, secret key that is used to both sign and encrypt a message, and is usually faster than public key cryptography.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • Default User: Configure either a default username and password, a UsernameCallbackHandler, or leave these options blank and specify a user at runtime.
  • User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.
Table 12 - Username Authentication with Symmetric Key Configuration Properties
Property Description Value
Authentication Token Authentication Token:
Specifies which supporting token will be used to sign and/or encrypt the specified message parts. Options include Username, X509, SAML, Issued, or None
Username
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

An algorithm suite specifies actual algorithms and allowed key lengths. A mechanism alternative will define what algorithms are used and how they are used. The value of this attribute is typically referenced by a security binding and is used to specify the algorithms used for all cryptographic operations performed under the security binding. The default value is Basic 128 bit.

Some of the algorithm suite settings require that Unlimited StrengthEncryption be configured in the Java Runtime Environment (JRE), particularly the algorithm suites that use 256 bit encryption. For instructions on downloading and configuring unlimited strength encryption, see: Java SE Security or Java SE Downloads
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header.

The options are:

* Strict: Items are added to the security header following the general principle of ?declare before use?

* Lax: Items are added to the security header in any order that conforms to WSS: SOAP Message Security. However, WSIT follows Strict even when Lax is selected.

* Lax (Timestamp First): The same as Lax, except that the first item in the security header must be a wsse:Timestamp.

* Lax (Timestamp Last): The same as for Lax, except that the last item in the security header must be a wsse:Timestamp.
Strict
Require Derived Keys Require Derived Keys:
Specifies that a derived key is required.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key (for example, when using Secure Conversation) for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.
Select the checkbox to enable
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

When this option and Require Derived Keys are both enabled, a derived key will be used.

If not, the original session key will be used. Note on Secure Session and Reliable Message Delivery: Reliable Messaging can be used independently of the security mechanisms; however, when used with a security mechanism, Reliable Messaging requires the use of Secure Session, which will be automatically configured for a security mechanism when Reliable Messaging is selected before the security mechanism is selected. If Secure Session is selected for a security mechanism and the Reliable Messaging option is not selected before the security mechanism is specified, Reliable Messaging will need to be manually selected in order for Secure Session to work.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Key above for more information.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key. If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

Mutual Certificates Security

The Mutual Certificates Security mechanism uses security through authentication and message protection to ensure integrity and confidentiality. This mechanism requires a keystore and truststore file for both the client and server sides of the application.

For an example of configuring WS Security for Mutual Certificates Security see Using the WSIT Mutual Certificates Security Mechanism with the HTTP BC.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore (no alias): Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
Table 13 - Mutual Certificates Security Configuration Properties
Property Description Value
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. The options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys Require Derived Keys:
Specifies that a derived key is required.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key (for example, when using Secure Session) for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Keys above for more information.
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key.

If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

Transport Security (SSL)

The Transport Security mechanism uses SSL for authentication and confidentiality during message transport. Transport-layer security relies on secure HTTP transport (HTTPS) using Secure Sockets Layer (SSL). This point-to-point security mechanism that can be used for authentication, message integrity, and confidentiality.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.
  • User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.

Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.
  • User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.
Table 14 - Transport Security (SSL) Configuration Properties
Property Description Value
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Client Certificate Require Client Certificate:
Specifies that a client certificate must be provided to the server for verification.

If you are using a security mechanism with SSL, a client certificate will be required by the server both during its initial handshake and again during verification.
Select the checkbox to enable.

Message Authentication over SSL

The Message Authentication over SSL mechanism attaches a cryptographically secured identity or authentication token with the message and use SSL for confidentiality protection. Authentication is specified through a Username Supporting Tolken or an X.509 Supporting Tolken.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.
  • User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.

Table 15 - Message Authentication over SSL Configuration Properties
Property Description Value
Authentication Token Authentication Token:
Specifies which supporting token will be used to sign and/or encrypt the specified message parts. Options include Username, X509, SAML, Issued, or None
Username
WSS Version WSS Version:
Specifies which version of the Web Services Security specification is followed. Options are 1.0 and 1.1.

Enabling WSS 1.1 enables the Server to reuse an encrypted key already generated by the client. This saves the time otherwise required to create a Symmetric Key during the course of response, encrypt it with the client public key (which is also an expensive RSA operation), and transmit the encrypted key in the message (it occupies markup and requires Base64 operations). Enabling WSS 1.1 also enables encrypted headers.
1.1
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys for Secure Session.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.

SAML Authorization over SSL

The SAML Authorization over SSL mechanism attaches an authorization token to the message. SSL is used for confidentiality protection. In this mechanism, the SAML token is expected to carry some authorization information about an end user. The sender of the token is actually vouching for the credentials in the SAML token.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore (no alias): Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.

Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • SAML Callback Handler: Specify a SAML Callback Handler. To use a SAML Callback Handler, you need to create one, as there is no default.
  • SSL: Configure the system to point to the client and server Keystore and Truststore files.

Table 16 - SAML Authorization over SSL Configuration Properties
Property Description Value
SAML Version SAML Version:
Specifies which version of the SAML token should be used. The SAML Version is something the CallbackHandler has to verify, not the security runtime.

SAML tokens are defined in WSS: SAML Token Profile documents, available from http://www.oasis-open.org/specs/index.php.
1.1 (Profile 1.0)
WSS Version WSS Version:
Specifies which version of the Web Services Security specification is followed. Options are 1.0 and 1.1.

Enabling WSS 1.1 enables the Server to reuse an encrypted key already generated by the client. This saves the time otherwise required to create a Symmetric Key during the course of response, encrypt it with the client public key (which is also an expensive RSA operation), and transmit the encrypted key in the message (it occupies markup and requires Base64 operations). Enabling WSS 1.1 also enables encrypted headers.
1.1
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Client Certificate Require Client Certificate:
Specifies that a client certificate must be provided to the server for verification.

If you are using a security mechanism with SSL, a client certificate will be required by the server both during its initial handshake and again during verification.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.

Endorsing Certificate

The Endorsing Certificate mechanism uses secure messages that use symmetric key for integrity and confidentiality, and an endorsing client certificate to augment the claims provided by the token associated with the message signature. The client knows the service's certificate, and requests need to be endorsed or authorized by a special identity.

Server-Side Requirements The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.

Client-Side Requirements The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.

Table 17 - Endorsing Certificate Configuration Properties
Property Description Value
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Establish Secure Session (Secure Conversation) Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message. For more information see Establish Secure Session under Table 12. Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Key above for more information.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys for Secure Session.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key.

If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

SAML Sender Vouches with Certificates

This mechanism uses mutual certificates to provide integrity and confidentiality for messages, and uses a Sender Vouches SAML token to provide authorization. The Sender Vouches method establishes correspondence between a SOAP message and the SAML assertions added to the SOAP message. Confirmation evidence, used to establish correspondence between the subject of the SAML subject statements (in SAML assertions) and SOAP message content, is provided by the attesting entity.

The message payload needs to be signed and encrypted. The requestor is vouching for the credentials (present in the SAML assertion) of the entity on behalf of which the requestor is acting. The initiator token, which is an X.509 token, is used for signature. The recipient token, which is also an X.509 token, is used for encryption. For the server, this is reversed, the recipient token is the signature token and the initiator token is the encryption token. A SAML token is used for authorization.

For an example of configuring WS Security for SAML Sender Vouches with Certificates see: Using the SAML Sender Vouches with Certificates Security Mechanism with the HTTP BC

Server-Side Requirements The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore (no alias): Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.

Client-Side Requirements The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • SAML Callback Handler: Specify a SAML Callback Handler. To use a SAML Callback Handler, you need to create one, as there is no default.
Table 18 - SAML Sender Vouches with Certificates Configuration Properties
Property Description Value
SAML Version SAML Version:
Specifies which version of the SAML token should be used. The SAML Version is something the CallbackHandler has to verify, not the security runtime.

SAML tokens are defined in WSS: SAML Token Profile documents, available from http://www.oasis-open.org/specs/index.php.
1.1 (Profile 1.0)
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys Require Derived Keys:
Specifies that a derived key is required.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Keys above for more information.
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key.

If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

SAML Holder of Key

This mechanism protects messages with a signed SAML assertion (issued by a trusted authority) carrying client public key and authorization information with integrity and confidentiality protection using mutual certificates. The Holder-of-Key (HOK) method establishes the correspondence between a SOAP message and the SAML assertions added to the SOAP message.
For more information see the SAML Token Profile document at {http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf].

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore (no alias): Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • SAML Callback Handler: Specify a SAML Callback Handler. To use a SAML Callback Handler, you need to create one, as there is no default.

Table 19 - SAML Holder of Key Configuration Properties
Property Description Value
SAML Version SAML Version:
Specifies which version of the SAML token should be used. The SAML Version is something the CallbackHandler has to verify, not the security runtime.

SAML tokens are defined in WSS: SAML Token Profile documents, available from http://www.oasis-open.org/specs/index.php.
1.1 (Profile 1.0)
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys Require Derived Keys:
Specifies that a derived key is required.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Keys above for more information.
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key.

If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

STS Issued Token

Protects messages using a token issued by a trusted Secure Token Service (STS) for message integrity and confidentiality protection.
To use this mechanism for the web service, select this option as your security mechanism. You must have a Security Token Service that can be referenced by the service. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application. The client Truststore must contain the certificate of the STS, which has the alias of wssip if you are using the updated GlassFish certificates.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:

  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism.
Client-Side Requirements The following client-side options need to be configured for this security mechanisms:

  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application.

Table 20 - STS Issued Token Configuration Properties
Property Description Value
Issuer Address Issuer Address:
Specifies the address of the issuer (STS) that will accept the security token presented in the message. The element type is an endpoint reference. An STS contains a set of interfaces used to issue, exchange, and validate security tokens.

For example, for JAX-WS services, the Issuer Address is: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Issuer Metadata Address Issuer Metadata Address:
Specifies the address from which to retrieve the issuer metadata. This should just be the URLs.

For example, for JAX-WS services, the Issuer Metadata Address is as follows: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Token Type Token Type:
Specifies the type of SAML token required by the service provider.

For example: urn:oasis:names:tc:SAML1.0:assertion.The options are 1.0, 1.1, or 2.0.
1.1
Key Type Key Type:
Specifies the type of key preferred by the service provider.

The choices are public key or symmetric key:

* Symmetric Key: cryptography relies on a shared secret and is usually faster than Public Key cryptography.

* Public Key: cryptography relies on a key that is made public to all and is primarily used for encryption but can be used for verifying signatures.

Applies to Issued Token mechanisms only.
Symmetric Key
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys for Issued Token Require Derived Keys for Issued Token:
Specifies that a derived key is required for Secure Session.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys for Issued Token.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session.

See Require Derived Keys for Issue Token above for more information.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key. If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

STS Issued Token with Service Certificate

Similar to STS Issued Token, except that in addition to the service requiring the client to authenticate using a SAML token issued by a designated STS, confidentiality protection is achieved using a service certificate. A service certificate is used by a client to authenticate the service and provide message protection. For GlassFish, a default certificate of s1as is included.

To use this mechanism for the web service, select this option as your security mechanism. You must have a Security Token Service that can be referenced by the service. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application. The client Truststore must contain the certificate of the STS, which has the alias of wssip if you are using the updated GlassFish certificates.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application.

Table 21 - STS Issued Token with Service Certificate Configuration Properties
Property Description Value
Issuer Address Issuer Address:
Specifies the address of the issuer (STS) that will accept the security token presented in the message. The element type is an endpoint reference. An STS contains a set of interfaces used to issue, exchange, and validate security tokens.

For example, for JAX-WS services, the Issuer Address is: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Issuer Metadata Address Issuer Metadata Address:
Specifies the address from which to retrieve the issuer metadata. This should just be the URLs.

For example, for JAX-WS services, the Issuer Metadata Address is as follows: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Token Type Token Type:
Specifies the type of SAML token required by the service provider.

For example: urn:oasis:names:tc:SAML1.0:assertion.

The options are 1.0, 1.1, or 2.0.
1.1
Key Type Key Type:
Specifies the type of key preferred by the service provider.

The choices are public key or symmetric key:

* Symmetric Key: cryptography relies on a shared secret and is usually faster than Public Key cryptography.

* Public Key: cryptography relies on a key that is made public to all and is primarily used for encryption but can be used for verifying signatures.

Applies to Issued Token mechanisms only.
Symmetric Key
Key Size Key Size:
Specifies the size of the symmetric key requested in number of bits.

This information is provided as an indication of the desired strength of the security. Valid choices include 128, 192, and 256. The security token is not obligated to use the requested key size, nor is the STS obligated to issue a token with the same key size. That said, the recipient should try to use a key at least as strong as the specified value if possible.

Applies to Issued Token mechanisms only.
128
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys Require Derived Keys:
Specifies that a derived key is required A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session. See Require Derived Keys above for more information.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key.

If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.

STS Issued Endorsing Token

Similar to STS Issued Token, except that the client authenticates using a SAML token that is issued by a designated STS. An endorsing token is used to sign the message signature.

Message integrity and confidentiality are protected using ephemeral keys encrypted for the service. Ephemeral keys use an algorithm where the exchange key value is purged from the cryptographic service provider (CSP) when the key handle is destroyed. The service requires messages to be endorsed by a SAML token issued by a designated STS.

For this mechanism, the service requires that secure communications be endorsed by a trusted STS. The service does not trust the client directly, but instead trusts tokens issued by a designated STS. In other words, the STS is taking on the role of a second service with which the client has to securely authenticate.

To use this mechanism for the web service, select this option as your security mechanism. You must have a Security Token Service that can be referenced by the service. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application. The client Truststore must contain the certificate of the STS, which has the alias of wssip if you are using the updated GlassFish certificates.

Server-Side Requirements
The following server-side options need to be configured for this security mechanisms:
  • Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism.

Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
  • Keystore: Cconfigure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
  • Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
  • STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application.

Table 22 - STS Issued Endorsing Token Configuration Properties
Property Description Value
Issuer Address Issuer Address:
Specifies the address of the issuer (STS) that will accept the security token presented in the message. The element type is an endpoint reference. An STS contains a set of interfaces used to issue, exchange, and validate security tokens.

For example, for JAX-WS services, the Issuer Address is: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Issuer Metadata Address Issuer Metadata Address:
Specifies the address from which to retrieve the issuer metadata. This should just be the URLs.

For example, for JAX-WS services, the Issuer Metadata Address is as follows: http://localhost:8080/jaxws-sts/sts
http://localhost:8080/jaxws-sts/sts
Token Type Token Type:
Specifies the type of SAML token required by the service provider.

For example: urn:oasis:names:tc:SAML1.0:assertion.The options are 1.0, 1.1, or 2.0.
1.1
Key Type Key Type:
Specifies the type of key preferred by the service provider.

The choices are public key or symmetric key:

* Symmetric Key: cryptography relies on a shared secret and is usually faster than Public Key cryptography.

* Public Key: cryptography relies on a key that is made public to all and is primarily used for encryption but can be used for verifying signatures.

Applies to Issued Token mechanisms only.
Symmetric Key
Key Size Key Size:
Specifies the size of the symmetric key requested in number of bits.

This information is provided as an indication of the desired strength of the security. Valid choices include 128, 192, and 256. The security token is not obligated to use the requested key size, nor is the STS obligated to issue a token with the same key size. That said, the recipient should try to use a key at least as strong as the specified value if possible.

Applies to Issued Token mechanisms only.
128
Algorithm Suite Algorithm Suite:
Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens.

See Algorithm Suite under Table 12 for more information.
Basic 128bit
Security Header Layout Security Header Layout:
Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last).

See Security Header Layout under Table 12 for more information.
Strict
Require Derived Keys for X509 Token Require Derived Keys for X509 Token:
Specifies that a derived key is required for X509 Token. See Require Derived Key above for more information.

A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys for X509 Token.
Select the checkbox to enable.
Require Derived Keys for Issued Token Require Derived Keys for Issued Token:
Specifies that a derived key is required for Issued Token. See Require Derived Keys for X509 Token above for more information.
Select the checkbox to enable.
Establish Secure Session (Secure Conversation) Establish Secure Session:
Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message.

For more information see Establish Secure Session under Table 12.
Select the checkbox to enable.
Require Derived Keys for Secure Session Require Derived Keys for Secure Session:
Specifies that a derived key is required for Secure Session.

See Require Derived Keys for X509 Token above for more information.
Select the checkbox to enable.
Require Signature Confirmation Require Signature Confirmation:
Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .
Select the checkbox to enable.
Encrypt Signature Encrypt Signature:
Specifies whether the primary signature and signature confirmation elements must be encrypted.
Select the checkbox to enable.
Encrypt before Signing Encrypt before Signing:
Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key. If not selected, the default behavior is Sign Before Encrypt.
Select the checkbox to enable.


Previous
Next

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-13) was last changed on 15-Jun-09 10:42 AM, -0700 by rjacobus