Securing WebLogic Web Services

Configuring Transport-Level Security

Transport-level security refers to securing the connection between a client application and a Web Service with Secure Sockets Layer (SSL) or HTTP Basic authentication, either alone or in combination.

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 WebLogic Security for general information about SSL and the implementations included in WebLogic Server.

The following sections describe how to configure transport-level security for your Web Service:

• Configuring Transport-Level Security Through Policy

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

• Configuring Two-Way SSL for a Client Application

• Using a Custom SSL Adapter with Reliable Messaging

 

---

Configuring Transport-Level Security Through Policy

You can specify a policy that requires SSL, HTTP BASIC authentication, or both.

If the policy requires SSL, make sure you 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 WebLogic Server.

For example, the Oracle-supplied Wssp1.2-2007-Saml2.0-Bearer-Https.xml policy file includes the following assertion indicating that the policy is expecting a client certificate via SSL, as shown in Listing 3-1. Listing 3-1 Specifying SSL in a Policy

<sp:TransportToken> 

<wsp:Policy>

<sp:HttpsToken/>

</wsp:Policy>

</sp:TransportToken> 

If two-way SSL is required, also use the RequireClientCertificate assertion, as shown in Listing 3-2. Listing 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 a client certificate via SSL and HTTP BASIC Authentication, as shown in Listing 3-3. Listing 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>

 

Configuring Transport-Level Security Through Policy: Main Steps

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

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 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.

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.

   See “Developing WebLogic Web Services” in Getting Started With WebLogic Web Services Using JAX-RPC

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 Sun's 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.

 

---

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 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.

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

   See “Developing WebLogic Web Services” in Getting Started With WebLogic Web Services Using JAX-RPC

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 Sun's 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.

 

---

Configuring Two-Way SSL for a Client Application

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 J2SE 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 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 J2SE 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 Sun Microsystem's keytool 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 WebLogic Server.

• 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 set to specify the client-side keystore:

  • -Djavax.net.ssl.keyStore=keyStore

  • -Djavax.net.ssl.keyStorePassword=keyStorePassword

 

---

Using a Custom SSL Adapter with Reliable Messaging

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, 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