| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Programming WebLogic Web Services > Configuring Security |
|
Programming WebLogic Web Services
|
The following sections describe how to configure security for WebLogic Web Services:
Overview of Configuring Security
When you secure your WebLogic Web Service, you can configure two conceptually different types of security:
Configuring WebLogic Web Service Data Security
Data security in WebLogic Web Services follows the Web Services Security (WS-Security) specification.
This specification provides three main mechanisms: security token propagation, message integrity, and message confidentiality. These mechanism can be used independently (such as passing a username security token for user authentication) or together (such as digitally signing and encrypting a SOAP message and providing a security token hierarchy associated with the private/public keys used for signing and encrypting.)
For main steps and details for configuring data security, see Configuring Data Security (Digital Signatures and Encryption): Main Steps.
Configuring WebLogic Web Service Connection Security
Configuring connection security for WebLogic Web Services is basically no different from securing any other type of application or component that runs on WebLogic Server. You can secure the entire Web Service by restricting access to the URLs that invoke the Web Service and its WSDL. When you secure the entire Web Service, the components that make up the Web Service are automatically secured. Or you can secure individual components of the Web Service, such as the stateless session EJB, a selected list of its methods, the Web application that contains the web-services.xml file, and so on.
After you secure access to the Web Service or some of its components, you configure client applications to use HTTP or SSL to authenticate themselves when they invoke the Web Service.
For the main steps and details to configure connection security, see Configuring Connection Security: Main Steps.
Configuring Data Security (Digital Signatures and Encryption): Main Steps
To configure data security (such as digital signatures and encryption) for a WebLogic Web Service and a client that invokes the service, follow these steps. Later sections describe the steps in detail.
Note: The following procedure assumes that you have already implemented and assembled (with the servicegen Ant task) a WebLogic Web Service and you want to update it to use digital signatures and encryption.
Note: You can specify only a subset of the data security options using the servicegen Ant task. In particular, the default information specifies that the entire SOAP body be digitally signed or encrypted, rather than specific elements. A later step in this procedure shows you how to configure additional security features for your Web Service, if needed.
Configuring Standard WebLogic Server Security Features With the Administration Console
Web Service data security, such as digital signatures and encryption, uses many standard security features such as private/public keys and digital certificates. This section uses the following terms:
This section describes the tasks you must perform and points you to sections in the general WebLogic Server security documentation for details.
Updating the servicegen build.xml File
Update the build.xml file that contains the call to the servicegen Ant task by adding a <security> child element to the <service> element that builds your Web Service, as shown in the following example. By default, servicegen specifies that the entire SOAP body will be digitally signed or encrypted, rather than specific elements. Later sections describe how to digitally sign or encrypt specific elements.
<servicegen
destEar="c:\myWebService.ear"
warName="myWAR.war"
contextURI="web_services" >
<service
ejbJar="c:\myEJB.jar"
targetNamespace="http://www.bea.com/examples/Trader"
serviceName="TraderService"
serviceURI="/TraderService"
generateTypes="True"
expandMethods="True" >
<security
username="juliet"
password="secret"
signKeyName="mykey"
signKeyPass="secret"
encryptKeyName="mykey"
encryptKeyPass="secret"
/>
</service>
</servicegen>
The preceding build.xml file specifies that servicegen assemble a Web Service that includes the following data security information in the web-services.xml deployment descriptor file:
When you regenerate your Web Service using this build.xml file, only a minimal amount of default security information is added to the generated web-services.xml file. See Updating Security Information in the web-services.xml File for details on the default information that is added to web-services.xml. In particular, if you specify that you want to use digital signatures and encryption by specifying the signKeyName, signKeyPass, encryptKeyName, and encryptKeyPass attributes, the entire SOAP body will be encrypted or digitally signed.
If you want to specify particular elements of the SOAP message to be digitally signed or encrypted, update the web-services.xml file of your WebLogic Web Service manually. For details, see Updating Security Information in the web-services.xml File.
Updating Security Information in the web-services.xml File
The servicegen Ant task adds minimal default data security information to the generated web-services.xml deployment descriptor file. In particular, the default information specifies that the entire SOAP body be digitally signed or encrypted, rather than specific elements. This default behavior is adequate in many cases; however, you might sometimes want to specify just a subset of the elements to be digitally signed or encrypted. In this case, you must update the web-services.xml file manually.
Warning: BEA highly recommends that you do not change elements of the generated <security> element in the web-services.xml file, other than those described in this section.
If you use the build.xml file in Updating the servicegen build.xml File to run servicegen, the following example shows the resulting <security> element in the generated web-services.xml file:
<web-service>
...
<security>
<user>
<name>juliet</name>
<password>secret</password>
</user>
<signatureKey>
<name>mykey</name>
<password>secret</password>
</signatureKey>
<encryptionKey>
<name>mykey</name>
<password>secret</password>
</encryptionKey>
<spec:SecuritySpec
xmlns:spec="http://www.openuri.org/2002/11/wsse/spec">
<spec:UsernameTokenSpec
xmlns="http://schemas.xmlsoap.org/ws/2002/07/secext"
PasswordType="PasswordText" />
<spec:BinarySecurityTokenSpec
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"
EncodingType="wsse:Base64Binary"
ValueType="wsse:X509v3" />
<spec:SignatureSpec
SignatureMethod="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
SignBody="true"
CanonicalizationMethod="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
/>
<spec:EncryptionSpec
EncryptBody="true"
EncryptionMethod="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
/>
</spec:SecuritySpec>
</security>
</web-service>
The SignBody="true" and EncrpytBody="true" attributes of the preceding <spec:SignatureSpec> and <spec:EncryptionSpec> elements specify that the entire SOAP body be digitally signed and encrypted. To specify particular elements to be digitally signed or encrypted, add one or more <spec:ElementIdentifier> child elements.
For example, assume that, in addition to the entire SOAP body, you want to digitally sign an element in the SOAP header whose local name is Timestamp. To specify this configuration, add a <spec:ElementIdentifier> child element to the <spec:SignatureSpec> element as shown:
<spec:SignatureSpec
CanonicalizationMethod="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
SignatureMethod="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
SignBody="true" >
<spec:ElementIdentifier
LocalPart="Timestamp"
Namespace="http://schemas.xmlsoap.org/ws/2002/07/utility"
Restriction="header" />
</spec:SignatureSpec>
Warning: If you use the Restriction attribute to restrict the part of the SOAP message, only the top-level elements in the relevant SOAP message part (header or body) are searched for matching element names. If you do not specify this attribute, all elements, no matter how deeply nested, are searched.
If you do not want to digitally sign the entire SOAP body, but rather just sign an element whole local name is Created when it appears in any part of the SOAP message, update the <spec:SignatureSpec> element as shown:
<spec:SignatureSpec
CanonicalizationMethod="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
SignatureMethod="http://www.w3.org/2000/09/xmldsig#rsa-sha1" >
<spec:ElementIdentifier
LocalPart="Created"
Namespace="http://schemas.xmlsoap.org/ws/2002/07/utility" />
</spec:SignatureSpec>
Specifying a particular element to be encrypted is very similar. For example, to encrypt just the element CreditCardNumber, wherever it appears in the SOAP message, update the <spec:EncryptionSpec> element as shown:
<spec:EncryptionSpec
EncryptionMethod="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" >
<spec:ElementIdentifier
LocalPart="CreditCardNumber"
Namespace="http://schemas.xmlsoap.org/ws/2002/07/utility" />
</spec:EncryptionSpec>
Warning: If you use the <spec:ElementIdentifier> element to specify a particular element in the SOAP message to be encrypted, do not also specify the EncryptBody="true" attribute of the <spec:EncryptionSpec> element, or the encryption/decryption process might become too complex and cause your Web Service security not to work as you expect.
For details about the <security> element, and all its child elements discussed in this section, see WebLogic Web Service Deployment Descriptor Elements.
Updating a Java Client to Invoke a Data-Secured Web Service
To update a Java client application to invoke a WebLogic Web Service that uses digital signatures or encryption, follow these steps:
The following example shows a Java client application that invokes a data-secured WebLogic Web Service, with the security-specific code in bold (and described after the example):
import examples.security.basicclient.Basic;
import examples.security.basicclient.BasicPort;
import examples.security.basicclient.Basic_Impl;
import weblogic.webservice.context.WebServiceContext;
import weblogic.webservice.context.WebServiceSession;
import weblogic.webservice.core.handler.WSSEClientHandler;
import weblogic.xml.security.SecurityAssertion;
import weblogic.xml.security.UserInfo;
import javax.xml.namespace.QName;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.handler.HandlerInfo;
import javax.xml.rpc.handler.HandlerRegistry;
import java.io.FileInputStream;
import java.io.IOException;
import java.security.Key;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
public class AutoClient{private static final String CLIENT_KEYSTORE = "client_keystore";
private static final String KEYSTORE_PASS = "secret";
private static final String KEYNAME = "mykey";
private static final String USERNAME = "juliet";
private static String PASSWORD = "secret";
public static void main( String[] args )
throws IOException,ServiceException, Exception{
{final long iterations =
(args.length < 1) ? 1 : Integer.parseInt(args[0]);
Basic service = new
Basic_Impl("http://localhost:7001/secservice/basic?WSDL");
// Get the WebServiceContext of the Web Service
WebServiceContext context = service.context();
System.out.println("passing context info to the client");// Load X509 digital certificates from the local keystore
X509Certificate clientcert;
clientcert = getCertificate(KEYNAME, CLIENT_KEYSTORE);
// Load the private key from the local keystore
PrivateKey clientprivate;
clientprivate = (PrivateKey) getPrivateKey(KEYNAME, KEYSTORE_PASS, CLIENT_KEYSTORE);
// Get the WebLogic Web Service session
WebServiceSession session = context.getSession();
// Pass the private key and digital certificate information to the Web
// service by setting the specified WebServiceSession attributes.
session.setAttribute(WSSEClientHandler.CERT_ATTRIBUTE, clientcert);
session.setAttribute(WSSEClientHandler.KEY_ATTRIBUTE, clientprivate);
// Create a UserInfo object, then pass the user information to the Web
// service by setting the specified WebServiceSession attributes.
UserInfo ui = new UserInfo(USERNAME, PASSWORD);
session.setAttribute(WSSEClientHandler.REQUEST_USERINFO, ui);
long time = 0;
BasicPort port = service.getbasicPort();
String result =null;
for (int i = 0 ; i < iterations+1 ; i++) {
if (i == 1) time = System.currentTimeMillis();
result = port.helloback();
}
time = System.currentTimeMillis() - time;
System.out.println(iterations+" transactions in "+time/1000.0+" seconds");
System.out.println(((iterations*1000.0)/(time))+" transaction second");
System.out.println(result);
}
}
private static Key getPrivateKey(String alias, String password, String keystore)
throws Exception
{
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), KEYSTORE_PASS.toCharArray());
Key result = ks.getKey(alias, password.toCharArray());
return result;
}
private static X509Certificate getCertificate(String alias, String keystore)
throws Exception
{
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), KEYSTORE_PASS.toCharArray());
X509Certificate result = (X509Certificate) ks.getCertificate(alias);
return result;
}
private static Key getPublicKey(String alias, String keystore)
throws Exception
{
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), KEYSTORE_PASS.toCharArray());
X509Certificate cert = (X509Certificate) ks.getCertificate(alias);
if (cert != null) return cert.getPublicKey();
return null;
}
}
The main points to note about the preceding code are as follows:
WebServiceContext context = service.context();
The weblogic.webservice.context.WebServiceContext class is a proprietary WebLogic Web Service client API.
X509Certificate clientcert;
clientcert = getCertificate(KEYNAME, CLIENT_KEYSTORE);
PrivateKey clientprivate;
clientprivate = (PrivateKey) getPrivateKey(KEYNAME,
KEYSTORE_PASS,CLIENT_KEYSTORE);
WebServiceSession session = context.getSession();
The weblogic.webservice.context.WebServiceSession class is a proprietary WebLogic Web Service client API.
session.setAttribute(WSSEClientHandler.CERT_ATTRIBUTE,
clientcert);
session.setAttribute(WSSEClientHandler.KEY_ATTRIBUTE,
clientprivate);
UserInfo ui = new UserInfo(USERNAME, PASSWORD);
session.setAttribute(WSSEClientHandler.REQUEST_USERINFO, ui);
The weblogic.xml.security.UserInfo class is a proprietary WebLogic Web Service client API.
Running the Client Application
When you run the client application that uses digital signatures and encryption to invoke a Web Service, you can set the following system properties to view more runtime security information:
Configuring Connection Security: Main Steps
To configure connection security for a WebLogic Web Service and a client that invokes the service, follow these steps. Later sections describe the steps in detail.
Controlling Access to WebLogic Web Services
As previously discussed, WebLogic Web Services are packaged as standard J2EE Enterprise applications. Consequently, to secure access to the Web Service, you secure access to some or all of the following standard J2EE components that make up the Web Service:
You can use basic HTTP authentication or SSL to authenticate a client that is attempting to access a WebLogic Web Service. Because the preceding components are standard J2EE components, you secure them by using standard J2EE security procedures.
Note: If the backend component that implements your Web Service is a Java class or a JMS listener, the only way to secure the Web Service is by adding security constraints to the URL that invokes the Web Service, as described in the next section.
For additional and detailed information about configuring, programming, and managing WebLogic security, see the security documentation.
Securing the Web Service Using the Adminstration Console
You secure a Web Service by creating a security policy through the Administration Console and assigning it to a WebLogic Web Service. Security policies answer the question "who has access" to a WebLogic resource, such as a Web Service. A security policy is created when you define an association between a WebLogic resource and a user, group, or role. A WebLogic resource has no protection until you assign it a security policy.
You assign security policies to an individual resource or to attributes or operations of a resource. If you assign a security policy to a type of resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of resource.
To use a user or group to create a security policy, the user or group must be defined in the Authentication provider configured in the default security realm. To use a role to create a security policy, the role must be defined in the Role Mapping provider configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured.
For more information and procedures about setting protections for WebLogic Web Services using the Adminstration Console, see Configuring WebLogic Security.
Client applications use a URL to access a Web Service, as described in The WebLogic Web Services Home Page and WSDL URLs. An example of such a URL is:
http://ariel:7001/web_services/TraderService
You can restrict access to the entire Web Service by restricting access to its URL. To do this, update the web.xml and weblogic.xml deployment descriptor files (in the Web application that contains the web-services.xml file) with security information.
If you want to restrict access to the Web Service, but allow users to view its WSDL, you must remap the WSDL URL to a different URL, and then restrict this new URL. For example, the default WSDL of the Web Service described in the beginning of this section is:
http://ariel:7001/web_services/TraderService?WSDL
You can use the URL mapping elements of the web.xml deployment descriptor file to map this URL to something else, such as:
http://ariel:7001/WSDLS/TraderServiceWSDL
and set different security constraints on it from the security on the Web Service itself.
For detailed information about restricting access to URLs, remapping the WSDL URL to a different URL, and so on, see Assembling and Configuring Web Applications.
Securing the Stateless Session EJB and Its Methods
If you secure the stateless session EJB that implements a Web Service, client applications that invoke the service have access to the Web application, the WSDL, and the Web Service Home Page, but might not be able to invoke the actual method that implements an operation. This type of security is useful if you want to closely monitor who has access to the business logic of the EJB but do not want to block access to the entire Web Service.
You can also use this type of security to decide at the method-level who has access to the various operations of the Web Service. For example, you can specify that any user can invoke a method that views information, but only a certain subset of users are allowed to update the information.
To secure the methods of a stateless session EJB, you must update both the ejb-jar.xml and weblogic-ejb-jar.xml deployment descriptor files.
Use the <assembly-descriptor> element in the ejb-jar.xml file to list the security roles for this EJB and the methods which can be invoked by the security roles, as shown in the following example:
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC
"-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
"http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
...
<assembly-descriptor>
<security-role>
<description>Secure EJB role has access to all methods</description>
<role-name>SecureEJBRole</role-name>
</security-role>
<method-permission>
<description>Secure EJB role has all access to all methods</description>
<role-name>SecureEJBRole</role-name>
<method>
<ejb-name>WebService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
...
</assembly-descriptor>
</ejb-jar>
Then use the <security-role-assignment> element in the weblogic-ejb-jar.xml file to map the security roles you listed in the ejb-jar.xml file to actual WebLogic users, as shown in the following example:
<?xml version="1.0"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC
'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN'
'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
...
<security-role-assignment>
<role-name>SecureEJBRole</role-name>
<principal-name>user_d1</principal-name>
</security-role-assignment>
</weblogic-ejb-jar>
For additional information about restricting access to EJBs, see Programming WebLogic Enterprise JavaBeans.
You make a Web Service accessible only through HTTPS by updating the protocol attribute of the <web-service> element in the web-services.xml file that describes the Web Service, as shown in the following excerpt:
<web-services>
<web-service name="stockquotes"
targetNamespace="http://example.com"
uri="/myStockQuoteService"
protocol="https" >
...
</web-service>
</web-services>
Note: If you configure SSL for WebLogic Server and you do not specify the HTTPS protocol in the web-services.xml file, client applications can access the Web Service using both HTTP and HTTPS. However, if you specify HTTPS access in the web-services.xml file, client applications cannot use HTTP to access the Web Service.
If you use the servicegen Ant task to assemble the Web Service, use the protocol attribute of the <service> element to specify the HTTPS protocol, as shown in the following sample build.xml file:
<project name="buildWebservice" default="ear">
<target name="ear">
<servicegen
destEar="ws_basic_statelessSession.ear"
contextURI="WebServices"
<service
ejbJar="HelloWorldEJB.jar"
targetNamespace="http://www.bea.com/webservices/basic/statelesSession"
serviceName="HelloWorldEJB"
serviceURI="/HelloWorldEJB"
protocol="https"
generateTypes="True"
expandMethods="True">
</service>
</servicegen>
</target>
</project>
Configuring SSL for WebLogic Server
If your client applications are going to use SSL to authenticate themselves, you must also configure SSL for WebLogic Server, as described in the following steps:
http://host:port/console
Coding a Client Application to Invoke a Secure Web Service
When you write a JAX-RPC client application that invokes a Web Service, you use the following two properties to send a user name and password to the service so that the client can authenticate itself:
The following example, taken from the JAX-RPC specification, shows how to use these properties when using the javax.xml.rpc.Stub interfaces to invoke a secure Web Service:
StockQuoteProviderStub sqp = // ... get the Stub;
sqp._setProperty ("javax.xml.rpc.security.auth.username", "juliet");
sqp._setProperty ("javax.xml.rpc.security.auth.password", "mypassword");
float quote sqp.getLastTradePrice("BEAS");
If you use the WebLogic-generated client JAR file to invoke a Web Service, the Stub classes are already created for you, and you can pass the user name and password to the Service-specific implementation of the getServicePort() method, as shown in the following example taken from the JAX-RPC specification:
StockQuoteService sqs = // ... Get access to the service;
StockQuoteProvider sqp = sqs.getStockQuoteProviderPort ("juliet", "mypassword");
float quote = sqp.getLastTradePrice ("BEAS");
In this example, the implementation of the getStockQuoteProvidePort() method sets the two authentication properties.
For additional information on writing a client application using JAX-RPC to invoke a secure Web Service, see http://java.sun.com/xml/jaxrpc/index.html.
Configuring SSL for a Client Application
Configure SSL for your client application by using either:
For additional detailed information about the APIs discussed in this section see the Web Service security Javadocs.
Using the WebLogic Server-Provided SSL Implementation
WebLogic Server provides an implementation of SSL in the webserviceclient+ssl.jar client runtime JAR file. In addition to the SSL implementation, this client JAR file contains the standard client JAX-RPC runtime classes contained in webservicesclient.jar.
To configure basic SSL support for your client application, follow these steps:
where license_file_directory refers to the directory that contains the BEA license file license.bea, as shown in the following example:
java -Dbea.home=c:\bea_home \
-Djava.protocol.handler.pkgs=com.certicom.net.ssl my_app
For detailed information, see the Web Service security Javadocs.
Configuring SSL Programatically
You can also configure the WebLogic Server-provided SSL implementation programatically by using the weblogic.webservice.client.WLSSLAdapter adapter class. This adapter class hold configuration information specific to WebLogic Server's SSL implementation and allows the configuration to be queried and modified.
The following excerpt shows an example of configuring the WLSSLAdapter class for a specific WebLogic Web Service; the lines in bold are discussed after the example:
// instantiate an adapter...
WLSSLAdapter adapter = new WLSSLAdapter();
adapter.setTrustedCertifcatesFile("mytrustedcerts.pem");
// optionally set the Adapter factory to use this
// instance always...
SSLAdapterFactory.getDefaultFactory().setDefaultAdapter(adapter);
SSLAdapterFactory.getDefaultFactory().setUseDefaultAdapter(true);
//create service factory
ServiceFactory factory = ServiceFactory.newInstance();
//create service
Service service = factory.createService( serviceName );
//create call
Call call = service.createCall();
call.setProperty("weblogic.webservice.client.ssladapter",
adapter); try {//invoke the remote web service
String result = (String) call.invoke( new Object[]{ "BEAS" } );
System.out.println( "Result: " +result);
} catch (JAXRPCException jre) {
...
}
The example first shows how to instantiate an instance of the WebLogic Server-provided WLSSLAdapter class, which supports the SSL implementation contained in the webserviceclient+ssl.jar file. It then configures the adapter instance by setting the name of the file that contains the Certificate Authority certificates using the setTrustedCertificatesFile(String) method; in this case the file is called mytrustedcerts.pem.
The example then shows how to set WLSSLAdapter as the default adapter of the adapter factory and configures the factory to always return this default.
Note: This step is optional; it allows all Web Services to share the same adapter class along with its associated configuration.
You can also set the adapter for a particular Web Service port or call. The preceding example shows how to do this when using the Call class to invoke a Web Service dynamically:
call.setProperty("weblogic.webservice.client.ssladapter", adapter);Set the property to an object that implements the weblogic.webservice.client.SSLAdapter interface (which in this case is the WebLogic Server-provided WLSSLAdapter class.)
The following excerpt shows how to set the adapter when using the Stub interface to statically invoke a Web Service:
((javax.xml.rpc.Stub)stubClass)._setProperty("weblogic.webservice.client.ssladapter", adapterInstance);You can get the adapter for a specific instance of a Web Service call or port by using the following method for dynamic invocations:
call.getProperty("weblogic.webservice.client.ssladapter");Use the following method for static invocations:
((javax.xml.rpc.Stub)stubClass)._getProperty("weblogic.webservice.client.ssladapter");For detailed information, see the Web Service security Javadocs.
Using a Third-Party SSL Implementation
If you want to use a third-party SSL implementation, you must first implement your own adapter class. The following example shows a simple class that provides support for JSSE; the main steps to implementing your own class are discussed after the example:
import java.net.URL;
import java.net.Socket;
import java.net.URLConnection;
import java.io.IOException;
public class JSSEAdapter implements weblogic.webservice.client.SSLAdapter {javax.net.SocketFactory factory =
javax.net.ssl.SSLSocketFactory.getDefault();
// implements weblogic.webservice.client.SSLAdapter interface...
public Socket createSocket(String host, int port) throws IOException {
return factory.createSocket(host, port);
} public URLConnection openConnection(URL url) throws IOException {
// assumes you have java.protocol.handler.pkgs properly set..
return url.openConnection();
}// the configuration interface...
public void setSocketFactory(javax.net.ssl.SSLSocketFactory factory) {
this.factory = factory;
} public javax.net.ssl.SSLSocketFactory getSocketFactory() {
return (javax.net.ssl.SSLSocketFactory) factory;
}
}To create your own adapter class, follow these steps:
weblogic.webservice.client.SSLAdapter
public Socket createSocket(String host, int port)
throws IOException
public URLConnection openConnection(URL url) throws IOException
weblogic.webservice.client.ssl.adapterclass
For detailed information, see the Web Service security Javadocs.
Extending the SSLAdapterFactory Class
You can create your own custom SSL adapter factory class by extending the SSLAdapterFactory class, which is used to create instances of adapters. One reason for extending the factory class is to allow custom configuration of each adapter when it is created, prior to use.
To create a custom SSL adapter factory class, follow these steps:
weblogic.webservice.client.SSLAdapterFactory
public weblogic.webservice.client.SSLAdapter createSSLAdapter();
This method is called whenever a new SSLAdapter, or an adapter that implements this interface, is created by the adapter factory. By overriding this method, you can perform custom configuration of each new adapter before it is actually used.
SSLAdapterFactory.setDefaultFactory(factoryInstance);
For detailed information, see the Web Service security Javadocs.
If your client application is running inside a firewall, for example, and needs to use a proxy server, set the host name and the port of the proxy server using the following two System properties:
For more information on these System properties, see WebLogic Web Services System Properties.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||