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:
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.
<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.
<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.
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:HttpBasicAuthentication/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
To configure transport-level Web Services security via one or more policy files:
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.
@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. @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
-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
-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.
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:
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.
@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.
See “Developing WebLogic Web Services” in Getting Started With WebLogic Web Services Using JAX-RPC
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.
-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
-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.
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:
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.
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.
-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
javax.net.ssl.keyStorePassword=
keyStorePassword
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:
weblogic.wsee.connection.transport.https.HttpsTransportInfo
.HttpsTransportInfo.setSSLAdapter(SSLAdapter adapter)
.(stub of type javax.xml.rpc.Stub)
by callingstub._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