Skip Headers
Oracle® Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server
11g Release 1 (10.3.6)

Part Number E13713-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Configuring Transport-Level Security

The chapter describes how to configure transport-level security for your WebLogic Web service using Java API for XML Web Services (JAX-WS) and Java API for XML-based RPC (JAX-RPC).

Transport-level security refers to securing the connection between a client application and a Web service with Secure Sockets Layer (SSL).

SSL provides secure connections by allowing two applications connecting over a network to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. A client certificate (two-way SSL) can be used to authenticate the user.

See "Secure Sockets Layer (SSL)" in Understanding Security for Oracle WebLogic Server for general information about SSL and the implementations included in WebLogic Server.

Transport-level security includes HTTP BASIC authentication as well as SSL.

This chapter includes the following sections:

Configuring Transport-Level Security Through Policy

WebLogic Server includes the predefined transport-level policy files described in Available Transport-Level Policies, which typically satisfy the security needs of most programmers and use cases.

You can also create and use your own WS-SecurityPolicy file if you need additional configuration, as described in Creating and Using a Custom Policy File. If you need to do this, you can use the predefined WS-SecurityPolicy files as templates to create your own custom files. The policy .xml files are located in MW_HOME/WL_HOME/server/lib/weblogic.jar. Within weblogic.jar, the policy files are located in /weblogic/wsee/policy/runtime.

For example, the Oracle-supplied Wssp1.2-2007-Saml2.0-Bearer-Https.xml policy file includes the following assertion indicating that the policy requires one-way SSL, as shown in Example 3-1.

Example 3-1 Specifying SSL in a Policy

<sp:TransportToken> 
<wsp:Policy>
<sp:HttpsToken/>
</wsp:Policy>
</sp:TransportToken> 

If you needed to instead use two-way SSL, you could create a custom policy that adds the RequireClientCertificate assertion, as shown in Example 3-2.

Example 3-2 Two-Way SSL in a Policy

<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken >
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>

The Wssp1.2-2007-Https-BasicAuth.xml policy file requires both SSL and HTTP BASIC Authentication, as shown in Example 3-3.

Example 3-3 SSL and HTTP Basic Authentication in a Policy

<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:HttpBasicAuthentication/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>

Available Transport-Level Policies

These policies require use of the https protocol to access the WSDL and invoke Web services operations:

Table 3-1 Transport Level Policies

Policy File Description

Wssp1.2-2007-Saml2.0-Bearer-Https.xml

One-way SSL uses SAML 2.0 token with Bearer confirmation method for Authentication.

Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml

Same as Wssp1.2-2007-Saml2.0-Bearer-Https.xml but uses a stronger hash algorithm of Sha-256.

Wssp1.2-2007-Saml1.1-Bearer-Https.xml

One-way SSL uses SAML 1.1 token with Bearer confirmation method for Authentication.

Wssp1.2-2007-Saml1.1-Bearer-Https-Basic256Sha256.xml

Same as Wssp1.2-2007-Saml1.1-Bearer-Https.xml but uses a stronger hash algorithm of Sha-256.

Wssp1.2-2007-Https.xml

One way SSL.

Wssp1.2-2007-Https-BasicAuth.xml

One way SSL with Basic Authentication. A 401 challenge occurs if the Authorization header is not present in the request.

Wssp1.2-2007-Https-ClientCertReq.xml

Two way SSL. The recipient checks for the initiator's public certificate. Note that the client certificate can be used for authentication.

Set Two Way Client Cert Behavior to "Client Certs Requested But Not Enforced." See "Configure two-way SSL" in Oracle WebLogic Server Administration Console Help for information on how to do this.

Wssp1.2-2007-Https-UsernameToken-Digest.xml

One way SSL with digest Username Token.

Wssp1.2-2007-Https-UsernameToken-Plain.xml

One way SSL with plain text Username Token.

Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml

Same as Wssp1.2-2007-Https-UsernameToken-Plain.xml but uses a stronger hash algorithm of Sha-256.

Wssp1.2-Https.xml

One way SSL.

Wssp1.2-Https-BasicAuth.xml

One way SSL with Basic Authentication. A 401 challenge occurs if the Authorization header is not present in the request.

Wssp1.2-Https-UsernameToken-Digest.xml

One way SSL with digest Username Token.

Wssp1.2-Https-UsernameToken-Plain.xml

One way SSL with plain text Username Token.

Wssp1.2-Https-ClientCertReq.xml

Two way SSL. The recipient checks for the initiator's public certificate. Note that the client certificate can be used for authentication.


Prerequisite: Configure SSL

Before you can use a transport-level policy to protect a Web service, you must configure SSL for the core WebLogic Server security subsystem.

The out-of-the-box private key and X.509 certificate pairs are provided for demonstration and testing purposes. For this reason Oracle highly recommends you use your own keystore and key pair in production.

You can configure one-way SSL where WebLogic Server is required to present a certificate to the client application, or two-way SSL where both the client applications and WebLogic server present certificates to each other.

To configure two-way or one-way SSL for the core WebLogic Server security subsystem, see "Configuring SSL" in Securing Oracle WebLogic Server.

If you configure two-way SSL for WebLogic Server, you must also configure SSL for the client application, as described in Configuring Two-Way SSL for a Client Application

Configuring SSL: Main Steps

This section summarizes the procedure described in Setting Up SSL: Main Steps. The steps are described here for your convenience; see Setting Up SSL: Main Steps for complete information.

To set up SSL:

  1. Configure identity and trust, as described in Configure Identity and Trust:

    1. Obtain digital certificates, private keys, and trusted CA certificates from the CertGen utility, the keytool utility, or a reputable vendor such as Entrust or Verisign. You can also use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit. The demonstration digital certificates, private keys, and trusted CA certificates should be used in a development environment only.

    2. Store the private keys, digital certificates, and trusted CA certificates. Private keys and trusted CA certificates are stored in a keystore.

    3. Configure the identity and trust keystores for WebLogic Server in the WebLogic Server Administration Console. See "Configure keystores" in the Oracle WebLogic Server Administration Console Help.

  2. Set SSL configuration options for the private key alias and password in the WebLogic Server Administration Console.

    Optionally, set configuration options that require the presentation of client certificates (for two-way SSL). See "Configure two-way SSL" in the Oracle WebLogic Server Administration Console Help.

Configuring Two-Way SSL for a Client Application

Note:

Web services using asynchronous or reliable messaging will automatically use the server's SSL certificate when establishing a new connection (back from the receiving service to the sending service) for the purposes of sending asynchronous responses, acknowledgments, and so forth.

If you configured two-way SSL for WebLogic Server, the client application must present a certificate to WebLogic Server, in addition to WebLogic Server presenting a certificate to the client application as required by one-way SSL. You must also follow these requirements:

  • Create a client-side keystore that contains the client's private key and X.509 certificate pair.

    The SSL package of Java SE requires that the password of the client's private key must be the same as the password of the client's keystore. For this reason, the client keystore can include only one private key and X.509 certificate pair.

  • Configure the core WebLogic Server's security subsystem, mapping the client's X.509 certificate in the client keystore to a user. See "Configuring a User Name Mapper" in Securing Oracle WebLogic Server.

  • Create a truststore which contains the certificates that the client trusts; the client application uses this truststore to validate the certificate it receives from WebLogic Server. Because of the Java SE password requirement described in the preceding bullet item, this truststore must be different from the keystore that contains the key pair that the client presents to the server.

    You can use the Cert Gen utility or the keytool (http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html) utility to perform this step. For development purposes, the keytool utility is the easiest way to get started.

    See "Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authorities" in Securing Oracle WebLogic Server.

  • Set Two Way Client Cert Behavior to "Client Certs Requested But Not Enforced." See "Configure two-way SSL" in Oracle WebLogic Server Administration Console Help for information on how to do this.

  • When you run the client application that invokes the Web service, specify the following properties:

    • -Djavax.net.ssl.trustStore=trustStore

    • -Djavax.net.ssl.trustStorePassword=trustStorePassword

      where trustStore specifies the name of the client-side truststore that contains the list of trusted certificates (one of which should be the server's certificate) and trustStorePassword specifies the truststore's password.

      The preceding properties are in addition to the standard properties you must set to specify the client-side keystore:

    • -Djavax.net.ssl.keyStore=keyStore

    • -Djavax.net.ssl.keyStorePassword=keyStorePassword

Configuring Transport-Level Security Through Policy: Main Steps

To configure transport-level Web services security via one or more policy files:

  1. As outlined in Prerequisite: Configure SSL, configure SSL for the core WebLogic Server security subsystem.

    You can configure one-way SSL where WebLogic Server is required to present a certificate to the client application, or two-way SSL where both the client applications and WebLogic server present certificates to each other.

    To configure two-way or one-way SSL for the core WebLogic Server security subsystem, see "Configuring SSL" in Securing Oracle WebLogic Server.

  2. Use @Policy or @Policies JWS annotations in your JWS file, or associate policy files only at runtime using the Administration Console, or specify some policy files using the annotations and then associate additional ones at runtime.

    See Table 3-1 for a description of the available transport-level policies.

    Note:

    If you specify a transport-level security policy for your Web service, it must be at the class level.

    In addition, the transport-level security policy must apply to both the inbound and outbound directions. That is, you cannot have HTTPS for inbound and HTTP for outbound.

    The following example attaches the policy at the class level:

    @Policy(uri="policy:Wssp1.2-2007-Saml2.0-Bearer-Https.xml")
    public class EchoService {
       ....
    
  3. If you added @Policy or @Policies JWS annotations in your JWS file, compile and redeploy your Web service as part of the normal iterative development process.

  4. When you run the client application that invokes the Web service, specify certain properties to indicate the SSL implementation that your application should use. In particular:

    • To specify the Certicom SSL implementation, use the following properties

      -Djava.protocol.handler.pkgs=weblogic.net
      -Dweblogic.security.SSL.trustedCAKeyStore=trustStore  
      

      where trustStore specifies the name of the client-side truststore that contains the list of trusted certificates (one of which should be the server's certificate). To disable host name verification, also specify the following property:

      -Dweblogic.security.SSL.ignoreHostnameVerification=true
      
    • To specify the Sun SSL implementation, use the following properties:

      -Djavax.net.ssl.trustStore=trustStore  
      

      where trustStore specifies the name of the client-side truststore that contains the list of trusted certificates (one of which should be the server's certificate). To disable host name verification, also specify the following property:

      -Dweblogic.wsee.client.ssl.stricthostchecking=false
      

      See Configuring Two-Way SSL for a Client Application for additional details about two-way SSL.

Example of Configuring Transport Security for JAX-WS

This section describes a simple example for configuring JAX-WS with Transport Security from a standalone client for one-way SSL.

See the following documentation for additional prerequisite information:

One-Way SSL (HTTPS and HTTP Basic Authentication Example)

The Web service Java source is shown in Example 3-4:

Note:

If you specify a transport-level security policy for your Web service, it must be at the class level.

In addition, the transport-level security policy must apply to both the inbound and outbound directions. That is, you cannot have HTTPS for inbound and HTTP for outbound.

Example 3-4 Web Service One-Way SSL Example

package httpbasicauth
import javax.jws.WebMethod;
import javax.jws.WebService;
 
import weblogic.jws.Policy;
 
@WebService(name="HttpsBasicAuth", portName="HttpsBasicAuthSoapPort"
 targetNamespace="https://httpsbasicauth")
 
// Security Policy for Https and Http Basic Authentication
@Policy(uri = "policy:Wssp1.2-2007-Https-BasicAuth.xml)
 
 
public class HttpsBasicAuth {
 
  
 public HttpsBasicAuth() {}
 
 WebMethod()
 public String echoString(String input) {
 
   return("[HttpsBasicAuth.echoString]: " + input); 
 
 } 
 
}

The standalone Java Web service client code that uses "weblogic.net" as the Java protocol handler is shown in Example 3-5:

Example 3-5 Web Service Client One-Way SSL Example With weblogic.net

package httpbasicauth.client
 
import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.Map;
 
import javax.xml.namespace.QName;
 
import javax.xml.ws.BindingProvider;
 
import httpsbasicauth.client.HttpsBasicAuthService;
import httpsbasicauth.client.HttpsBasicAuth;
 
 
public class HttpsBasicAuthClient
 
  private final static String ENDPOINT = .....;
  private final static String TARGET_NAMESPACE = "https://httpsbasicauth
  private final static String USERNAME = ....;
  private final static String PASSWORD = ....;
  private final static String TRUST_STORE_LOCATION = .....;
  private final static String TARGET_NAMESPACE = ....;
 
  private HttpsBasicAuthService service;
  private HttpsBasicAuth stub;
 
 
   public HttpsBasicAuthClient() {
    
    try {
      // This ignores the host name verifcation for the Public Certificate used by the Server 
      System.setProperty("weblogic.security.SSL.ignoreHostnameVerification","true");
 
      System.setProperty("java.protocol.handler.pkgs", "weblogic.net");
      System.setProperty("weblogic.security.TrustKeyStore","CustomTrust");
      System.setProperty("weblogic.security.CustomTrustKeyStoreFileName", "TRUST_STORE_LOCATION");
      System.setProperty("weblogic.security.CustomTrustKeyStorePassPhrase","TRUST_STORE_PASSWORD"); 
      System.setProperty("weblogic.security.CustomTrustKeyStoreType","JKS");
 
      URL url = new URL(endpoint+"?WSDL");
      QName serviceName = new QName(TARGET_NAMESPACE, "HttpsBasicAuthService");
 
      service = new HttpsBasicAuthService();
     
      stub = service.getHttpsBasicAuthSoapPort();
 
      BindingProvider bp = (BindingProvider) stub;
 
      Map<String,Object> context = bp.getRequestContext(); 
 
      context.put(BindingProvider.USERNAME_PROPERTY, USERNAME)
      context.put(BindingProvider.PASSWORD_PROPERTY, PASSWORD);
      context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT);
 
    } catch (Exception e) {
      System.out.println("Error in creating the stub : " + e.getMessage());
      if (verbose) e.printStackTrace();
    } 
  }
 
  public void invokeEchoString() throws Exception {
 
    String output = stub.echoString(ENDPOINT);
 
    System.out.println("[HttpsBasicAuthClient.invokeGEchoString]: " + output);
     
  }
    
  public static void main(String[] argv) throws Exception {
 
    HttpsBasicAuthClient client = new HttpsBasicAuthClient();
   
    System.setProperty("weblogic.wsee.verbose","*");
    
    System.out.println("----------------------");
    System.out.println("            Invoking echoString            ");
    client.invokeEchoString();
 
  }
 
}

The standalone Java Web service client code that uses the default Java protocol handler is shown in Example 3-6:

Example 3-6 Web Service Client One-Way SSL Example With java.net

package httpbasicauth.client
 
import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.Map;
 
import javax.xml.namespace.QName;
 
import javax.xml.ws.BindingProvider;
 
import httpsbasicauth.client.HttpsBasicAuthService;
import httpsbasicauth.client.HttpsBasicAuth;
 
 
public class HttpsBasicAuthClient
 
  private final static String ENDPOINT = .....;
  private final static String TARGET_NAMESPACE = "https://httpsbasicauth
  private final static String USERNAME = ....;
  private final static String PASSWORD = ....;
  private final static String TRUST_STORE_LOCATION = .....;
  private final static String TARGET_NAMESPACE = ....;
 
  private HttpsBasicAuthService service;
  private HttpsBasicAuth stub;
 
  public HttpsBasicAuthClient() {
 
     try { 
 
       System.setProperty("java.protocol.handler.pkgs", "java.net");
       System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_LOCATION);
       System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASSWORD);
    
 
       URL url = new URL(ENDPOINT+"?WSDL");
       QName serviceName = new QName(TARGET_NAMESPACE, "HttpsBasicAuthService");
 
       service = new HttpsBasicAuthService();
     
       stub = service.getHttpsBasicAuthSoapPort();
 
       BindingProvider bp = (BindingProvider) stub;
 
       Map<String,Object> context = bp.getRequestContext(); 
 
       context.put(BindingProvider.USERNAME_PROPERTY, USERNAME)
       context.put(BindingProvider.PASSWORD_PROPERTY, PASSWORD);
       context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT);
 
     } catch (Exception e) {
      System.out.println("Error in creating the stub : " + e.getMessage());
      if (verbose) e.printStackTrace();
    } 
 
  }
   
 
  public void invokeEchoString() throws Exception {
 
    String output = stub.echoString(ENDPOINT);
 
    System.out.println("[HttpsBasicAuthClient.invokeGEchoString]: " + output);
     
  }
 
  public static void main(String[] argv) throws Exception {
 
    HttpsBasicAuthClient client = new HttpsBasicAuthClient();
   
    System.setProperty("weblogic.wsee.verbose","*");
    
    System.out.println("----------------------");
    System.out.println("            Invoking echoString            ");
    client.invokeEchoString();
 
  } 
    
}

The related portion of the ant build file is shown in Example 3-7:

Example 3-7 Ant Build File

<property name="output.dir" value="../../build/httpsbasicauth" />
<property name="service.dir" value="${output.dir}/httpsbasicauthApp" />
<property name="output.dir.client" value="${output.dir}/client" />
<property name="clientclasses.dir" value="${output.dir}/client" />
<property name="service.name" value="HttpsBasicAuth" />
<property name="wsdl.name" value="HttpsBasicAuthService" />
<property name="packageName" value="httpsbasicauth.client" />
 
<path id="client.class.path">
  <pathelement path="${java.class.path}" />
  <pathelement path="${clientclasses.dir}" />
</path>
 
<taskdef name="clientgen"
           classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<taskdef name="jwsc" classname="weblogic.wsee.tools.anttasks.JwscTask"/>
 
 
 <target name="jwsc">
 
    <jwsc srcdir="." destdir="${output.dir.server}" sourcepath="../" debug="true" keepGenerated="true">
 
      <module name="HttpsBasicAuth" contextPath="httpsbasicauth">
 
        <jws file="HttpsBasicAuth.java" type="JAXWS" generateWsdl="true">
           <WLHttpTransport contextPath="httpsbasicauth" serviceUri="httpsbasicauth"/>
        </jws>
 
    </jwsc>
 
 </target>
 
  <target name="client">
 
    <clientgen wsdl="jar:file:${service.dir}/${service.name}.war!/WEB-INF/${wsdl.name}.wsdl"
               type="JAXWS"
               destDir="${clientclasses.dir}"
               packageName="${packageName}">
 
    </clientgen>
 
     <javac srcdir="${clientclasses.dir}"
           destdir="${clientclasses.dir}"
           includes="**/*.java"
           classpathref="client.class.path" /> 
 
    <javac srcdir="./"
           destdir="${clientclasses.dir}"
           includes="HttpsBasicAuthClient.java"
           classpathref="client.class.path" />
 
  </target>
 
  <target name="run">
    
    <java classname="httpsbasicauth.client.HttpsBasicAuthClient" 
          classpathref="client.class.path" 
          fork="true" />
  </target>

Persisting the State of a Request over SSL (JAX-WS Only)

JAX-RPC clients can use the SSLAdapter mechanism described in Using a Custom SSL Adapter with Reliable Messaging (JAX-RPC Only) to persist the state of a request over an SSL connection. In doing so, they persist the instance of the custom SSLAdapter used to establish the connection.

Oracle WebLogic Server includes a two-way SSL client API for JAX-WS that you can use to construct an SSLSocketFactory from system properties or from a new weblogic.wsee.jaxws.sslclient.PersistentSSLInfo class. The API can persist SSL info for Reliable Messaging, callbacks, and so forth, and supports the following well-known system properties:

The following new classes are available. See the Javadoc for complete descriptions.

Example of Getting SSLSocketFactory From System Properties

Example 3-8 shows an example of getting the SSLSocketFactory from system properties and using them in the request context.

Note:

The clientKeyStore and clientKeyStorePasswd have this restriction: the SSL package of Java SE requires that the password of the client's private key must be the same as the password of the client's keystore. For this reason, the client keystore can include only one private key and X.509 certificate pair.

Example 3-8 Getting SSLSocketFactory From System Properties

String clientKeyStore = ...;
      String clientKeyStorePasswd = ...;
      String trustKeystore = ...;
      String trustKeystorePasswd = ...;
      
      System.setProperty("javax.net.ssl.keyStore", clientKeyStore);
      System.setProperty("javax.net.ssl.keyStorePassword", clientKeyStorePasswd);
      System.setProperty("javax.net.ssl.trustStore", trustKeystore);
      System.setProperty("javax.net.ssl.trustStorePasswd", trustKeystorePasswd);
              
      ((BindingProvider) port).getRequestContext().put(
          JAXWSProperties.SSL_SOCKET_FACTORY, 
          SSLClientUtil.getSSLSocketFactoryFromSysProperties());

Example 3-9 shows an example of getting SSLSocketFactory from persistent info (PersistentSSLInfo), as well as directly setting a SSLSocketFactory if persistence is not needed.

Example 3-9 Getting SSLSocketFactory from PersistentSSLInfo

String clientKeyStore = ...;
      String clientKeyStorePasswd = ...;
      String clientKeyAlias = ...;
      String clientKeyPass = ...;
      String trustKeystore = ...;
      String trustKeystorePasswd = ...;
      
      PersistentSSLInfo sslInfo = new PersistentSSLInfo();
      sslInfo.setKeystore(clientKeyStore);
      sslInfo.setKeystorePassword(clientKeyStorePasswd);
      sslInfo.setKeyAlias(clientKeyAlias);
      sslInfo.setKeyPassword(clientKeyPass);
      sslInfo.setTrustKeystore(trustKeystore);
      
      //user can print out the sslInfo for debug
      System.out.print(sslInfo.toString());
 
//Put sslInfo into requestContext for persistence, it might be required by JAX-WS
advance features, such as, RM, Callback
      ((BindingProvider) port).getRequestContext().put(
        JAXWSProperties.CLIENT_PERSISTENT_SSL_INFO, sslInfo);
        
      //Alternatively, you can directly set a SSLSocketFactory if persistence is
not necessary. Note: The following line should be omitted if sslInfo is set with
above line.
      ((BindingProvider) port).getRequestContext().put(
        JAXWSProperties.SSL_SOCKET_FACTORY, 
        SSLClientUtil.getSSLSocketFactory(sslInfo));

sslInfo can set a key alias (clientKeyAlias) that points to a key in keystore (as an SSL client-side key) in the event that the client keystore has multiple keys.

Configuring Transport-Level Security Via UserDataConstraint: Main Steps (JAX-RPC Only)

The UserDataConstraint annotation requires that the Web service be invoked using the HTTPS transport.

To configure transport-level Web services security via the UserDataConstraint annotation in your JWS file:

  1. Configure SSL for the core WebLogic Server security subsystem.

    You can configure one-way SSL where WebLogic Server is required to present a certificate to the client application, or two-way SSL where both the client applications and WebLogic server present certificates to each other.

    To configure two-way or one-way SSL for the core WebLogic Server security subsystem, see "Configuring SSL" in Securing Oracle WebLogic Server.

  2. In the JWS file that implements your Web service, add the @weblogic.jws.security.UserDataConstraint annotation to require that the Web service be invoked using the HTTPS transport.

    For details, see "weblogic.jws.security.UserDataConstraint" in the WebLogic Web Services Reference for Oracle WebLogic Server.

  3. Recompile and redeploy your Web service as part of the normal iterative development process.

    See "Developing WebLogic Web Services" in Getting Started With JAX-RPC Web Services for Oracle WebLogic Server

  4. Update the build.xml file that invokes the clientgen Ant task to use a static WSDL to generate the JAX-RPC stubs of the Web service, rather than the dynamic deployed WSDL of the service.

    The reason clientgen cannot generate the stubs from the dynamic WSDL in this case is that when you specify the @UserDataConstraint annotation, all client applications are required to specify a truststore, including clientgen. However, there is currently no way for clientgen to specify a truststore, thus the Ant task must generate its client components from a static WSDL that describes the Web service in the same way as the dynamic WSDL.

  5. When you run the client application that invokes the Web service, specify certain properties to indicate the SSL implementation that your application should use. In particular:

    • To specify the Certicom SSL implementation, use the following properties

      -Djava.protocol.handler.pkgs=weblogic.net
      -Dweblogic.security.SSL.trustedCAKeyStore=trustStore 
      

      where trustStore specifies the name of the client-side truststore that contains the list of trusted certificates (one of which should be the server's certificate).To disable host name verification, also specify the following property:

      -Dweblogic.security.SSL.ignoreHostnameVerification=true
      
    • To specify the Sun SSL implementation, use the following properties:

      -Djavax.net.ssl.trustStore=trustStore  
      

      where trustStore specifies the name of the client-side truststore that contains the list of trusted certificates (one of which should be the server's certificate). To disable host name verification, also specify the following property:

      -Dweblogic.wsee.client.ssl.stricthostchecking=false
      

      See Configuring Two-Way SSL for a Client Application for details about two-way SSL.

Using a Custom SSL Adapter with Reliable Messaging (JAX-RPC Only)

Note:

All objects placed into Stub and MessageContext properties must be serializable and externalizable, and must have their implementations available on the server system CLASSPATH. This section describes the specific case of a custom SSLAdapter implementation.

You can use a custom SSLAdapter implementation to provide client certificates and other services needed to establish SSL connections between client and server when using reliable messaging or buffering. The reliable messaging and buffering subsystems persist the state of a request over an SSL connection. In doing so, they persist the instance of the custom SSLAdapter used to establish the connection.

When the request is restored from persistence, the persistence facility must have access to the custom SSLAdapter class in order to properly restore the custom SSLAdapter object saved with the request. To allow for this, you must provide your custom SSLAdapter class via the server's system CLASSPATH (and not within an application deployed to the server).

The custom SSLAdapter must extend SSLAdapter, and is installed and enabled via the following procedure:

  1. Create an instance of weblogic.wsee.connection.transport.https.HttpsTransportInfo.

  2. Set the custom SSL adapter on that transport info by calling HttpsTransportInfo.setSSLAdapter(SSLAdapter adapter).

  3. Set the transport info on the web services stub instance (stub of type javax.xml.rpc.Stub) by calling

    stub._setProperty(weblogic.wsee.connection.soap.SoapClientConnection.TRANSPORT_INFO_PROPERTY,ti); 
    

    Where stub is the Web services stub, and ti is the HttpsTransportInfo you configured.

If you do not follow this procedure and provide the custom SSLAdapter class on the system CLASSPATH, a ClassNotFoundException exception is generated:

java.io.IOException: java.lang.ClassNotFoundException: 
 examples.webservices.client.ServiceBase$TestSSLAdapter