Monthly Archive: May 2011

Analyzing WebSphere Thread Dump

We can take thread dump on WAS using wsadmin tool in the following way.

D:\IBM\WebSphere\AppServer\profiles\ProcessCommander\bin>wsadmin.bat
WASX7209I: Connected to process “server1” on node WKHANFXPNode02 using SOAP conn
ector; The type of process is: UnManagedProcess
WASX7029I: For help, enter: “$Help help”
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
WebSphere:name=JVM,process=server1,platform=proxy,node=WKHANFXPNode02,j2eeType=J
VM,J2EEServer=server1,version=6.1.0.0,type=JVM,mbeanIdentifier=JVM,cell=WKHANFXP
Node01Cell,spec=1.0
wsadmin>$AdminControl invoke $jvm dumpThreads

This will create a java core file in the following directory

D:\IBM\WebSphere\AppServer\profiles\ProcessCommander

javacore.20110511.174141.9628.txt

We need to download IBM Thread Dump Analyzer from here

Start the tool using the following command

E:\tools\jca412>java -Xmx515m -jar jca412.jar

Open the thread dump from

File > Open Thread Dumps

Then click on Analysis > Thread Details.

This will give you details of all the threads.

 

Weblogic SSL configuration with Custom Identity and Custom Trust

These days the enterprise applications have grown more complex and boast a great deal of sensitive and critical data online. Cyber security has become more than important these days to secure the data.

Secure Sockets Layer plays a pivotal role in how a sensitive data can be protected, accessed over a network.

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection 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. Encryption makes data transmitted over the network intelligible only to the intended recipient.

It provides transport level security by usage of the SSL certificates which are provided by the Industry standard Certificate Authorities like Verisign, GeoTrust, GoDaddy etc.

WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs protocol in the connection URL, for example, https://myserver:7002.

The below post describes the complete procedure about procuring the certificate, installing and configuring the certificate to the WebLogic Server. (WebLogic SSL Configuration).

1: Generating and procuring the certificate:

a: Open a command prompt and set the environment by running the setDomainEnv script.

b: Generate the private – public key pair. For demonstration we would use keytool java utility to do so. However we can use other utilities like openssl etc.

keytool -genkey -alias client -keyalg  RSA -keysize 2048  -keystore identity.jks -storepass password -keypass password

c: Generate a Certificate Signing Request (CSR) and send it to Certifying Authority.

keytool -certreq -keyalg RSA -keysize 2048 -alias client -file certreq.csr -keystore identity.jks -storepass password

The CA would return with the certificate reply and the RootCA and sometimes an intermediateCA certificate.

d:  Import the certificates into the keystore, this can be done in two ways either by importing the certificates in an order of RootCA, intermediateCA and then Certificate reply. Or we can create a certificate chain clubbing them in an order into a .pem file.

For demo, we would create a certificate chain file CertChain.pem and import it into the identity keystore overriding the private key alias which is client in this example.

keytool -import  -file CertChain.pem -alias client -keystore  identity.jks -storepass password

e: Create a trust keystore, this can be done my importing your RootCA certificate into another keystore that constitutes the trust.

keytool -import  -file rootCA.cer -alias RootCA -keystore trust.jks -storepass password

To verify the contents of the keystore, you can use the below command,

Keytool –list –v –keystore <keystore-name> -storepass  <keystore-password>

 

2: Configuring the keystore on the WebLogic Server.

a: Log into the Admin Console, select the server on which you want to configure the SSL certificate.

Server  –>  Click on the Keystore tab. By default it points to the Demo Certificates.

From the dropdown list select the “Custom Identity and  Custom Trust” option.

Enter the identity and trust keystore details.

b: Configure the identity of the server:

Click on the SSL tab and enter the alias of the private key i.e. client in this case and the keypass password.

NOTE: If you enable the SSL for a WebLogic Server, by default it would be One Way SSL. If you want to change to Two Way SSL, you would require to select  the two way SSL behavior from the Advanced option list.

c: Configure the SSL port.

By default it would be 7002.

Go to server –> General tab –> Specify  and enable SSL port.

You can see the below messages in the server logs which indicate that the certificates are loaded.

<Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias client from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\identityVerisign.jks.>

<Notice> <Security> <BEA-090169> <Loading trustedcertificates from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\trustVerisign.jks.>

 

3: Test the setup:

You can test the setup by accessing the admin console (if SSL is configured for Admin Server) or any application deployed on the server by accessing it on https protocol.

https://localhost:7002/console

Now verify whether the right certificate is configured or not.

Click on the certificate details and you would find the details about the identity and the RootCA along with the certificate chain.

 

NOTE: For a production environment make sure that CN (Common Name) of the certificate matches with the server host name.

You can also use self signed certificates or trial certificates for testing purpose. However is it not recommended to use them in production environment.

You can get the Verisign trail certificates from the below link.

http://www.verisign.com/ssl/free-30day-trial/

For further reading :

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/secmanage/ssl.html

Regards,

Wonders Team 🙂

Securing WebServices using Username / Password mechanism

Security is an important aspect of your application design. When the web services are deployed and accessed, you might like to restrict its accesses to particular set of users/ groups or any users of a particular role. Hence we specify the policies for the application  webservice in this case at the transport level.

WebServices can be secured using the below mechanisms:

Transport-level security secures the connection between the client application and WebLogic Server 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.

Encryption makes data transmitted over the network intelligible only to the intended recipient.

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

Message-Level Security refers to securing some or all of the message content, which relies on the WS-Security specification. WS-Security provides support for encrypting and/or signing part or all of a message. It also provides authentication using token-based credentials. In addition to WS-Security, WebLogic Server also supports the WS-SecureConversation standard to enable a secure session to be established between two trusted parties to facilitate the exchange of multiple messages in a stateful and secure manner.

Access control security answers the question “who can do what?” First you specify the security roles that are allowed to access a Web Service; a security role is a privilege granted to users or groups based on specific conditions. Then, when a client application attempts to invoke a Web Service operation, the client authenticates itself to WebLogic Server, and if the client has the authorization, it is allowed to continue with the invocation. Access control security secures only WebLogic Server resources. That is, if you configureonly access control security, the connection between the client application and WebLogic Server is not secure and the SOAP message is in plain text

 

The below post describes a demonstration of simple username/password-based authentication for webservices.

Pre-requisites :

1: WebService  deployed.

You can refer the below posts to create a sample WebService and a Java stand alone client to access the same.

http://weblogic-wonders.com/weblogic/2011/05/20/webservice-by-bottom-up-approach-using-ant-script/

http://weblogic-wonders.com/weblogic/2011/05/23/creating-stand-alone-webservice-client-from-wsdl/

 

Please follow the steps below:

1. Defining security poilicies:

Define the  policies to the WebService from the console:-

Go to Deployments –> WebService application deployed –> Security –> Policies. From the predicate list select a User / Group/ Role who can access the WebService.

Click save to create the security policy for the WebService.

2: Test the setup:

If you access the WebService without proper credentials, then you would experience the below error.

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Access denied to operation sayHelloWorld

at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:188)

at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:116)

at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)

at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)

at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)

at $Proxy29.sayHelloWorld(Unknown Source)

at com.test.webservice.client.Main.main(Main.java:17)

Caused by: javax.xml.ws.soap.SOAPFaultException: Access denied to operation sayHelloWorld

at weblogic.wsee.jaxws.security.AuthorizationTube.processRequest(AuthorizationTube.java:189)

In the java client, specify the user credentials to access the WebService as below.

Map<String, Object> rc = ((BindingProvider)port).getRequestContext();

rc.put(BindingProvider.USERNAME_PROPERTY, "weblogic");

rc.put(BindingProvider.PASSWORD_PROPERTY, "weblogic");

The JAX-WS BindingProvider class contains username and password properties that we set to specifythe user’s credentials. The underlying web service stub takes care of base 64 encoding these credentials and including them in the HTTP headers of the SOAP request.

A typical java standalone client would look like below.

 

import com.test.webservice.client.*;

import java.util.Map;

import javax.xml.ws.BindingProvider;

public class Main {

public static void main(String[] args) {

com.test.webservice.client.HelloWorldService service = new com.test.webservice.client.HelloWorldService();

com.test.webservice.client.HelloWorldPortType port = service.getHelloWorldPortTypePort();

Map<String, Object> rc = ((BindingProvider)port).getRequestContext();

rc.put(BindingProvider.USERNAME_PROPERTY, "weblogic");

rc.put(BindingProvider.PASSWORD_PROPERTY, "weblogic");

String result=port.sayHelloWorld(" Anandraj ");

System.out.println("********* RESULT from WebService ***********");
System.out.println(result);

System.out.println("********************************************");
}

}

 

Compile and execute the java client, then you would be able to invoke the secured WebService successfully.

You can refer the below link for securing the WebService using the Basic Authentication:

http://weblogic-wonders.com/weblogic/2010/01/04/securing-webservices-using-basic-authentication-on-weblogic-server/

For further reading :

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webserv_sec/message.html

Regards,

Wonders Team. 🙂