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

 

 

Creating stand alone WebService Client from WSDL

The below post provides an implementation of a Java stand alone client for a sample Java WebService.  All you need to know is the URL to its public contract file, or WSDL.

Per-Requisites:

A WSDL file, describing the WebService deployed on the Server.

You can refer the below link to create a WebService in WebLogic.

http://weblogic-wonders.com/weblogic/2011/05/19/webservices-in-weblogic/

Please follow the below steps to generate a standalone WebService client  using ant script.

1.  Setting up the Environment:

Open a command prompt and set the classpath by running the setDomainEnv.sh under the domain directory.

2. Create Ant Script:

Create a standard ant script with the clientgen ant task.

The clientgen WebLogic Web Service Ant task to generate the artifacts that your client application needs to invoke the Web Service operation. These artifacts include:

  • The Java class for the Service interface implementation for the particular Web Service you want to invoke.
  • JAXB data binding artifacts.
  • The Java class for any user-defined XML Schema data types included in the WSDL file.

A definition of clientgen is as below.

<taskdef name=”clientgen”
classname=”weblogic.wsee.tools.anttasks.ClientGenTask” />

A sample snippet of clientgen ant task would like below.

<clientgen

type="JAXWS"

wsdl="http://${wls.hostname}:${wls.port}/HelloWorldImpl/HelloWorldService?WSDL"

destDir="${clientclass-dir}"

packageName="com.test.webservice.client"/>

The clientgen Ant task uses the WSDL of the deployed HelloWorldService Web Service to generate the necessary artifacts and puts them into the output/clientclassdirectory, using the specified package name.

A complete ant task looks like below.

************************************************

 

<project name="webservices-simple_client" default="all">

<!-- set global properties for this build -->

<property name="wls.hostname" value="localhost" />

<property name="wls.port" value="7001" />

<property name="example-output" value="output" />

<property name="clientclass-dir" value="${example-output}/clientclass" />

<path id="client.class.path">

<pathelement path="${clientclass-dir}"/>

<pathelement path="${java.class.path}"/>

</path>

<taskdef name="clientgen"

classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

<target name="clean" >

<delete dir="${clientclass-dir}"/>

</target>

<target name="all" depends="clean,build-client,run" />

<target name="build-client">

<clientgen

type="JAXWS"

wsdl="http://${wls.hostname}:${wls.port}/HelloWorldImpl/HelloWorldService?WSDL"

destDir="${clientclass-dir}"

packageName="com.test.webservice.client"/>

<javac

srcdir="${clientclass-dir}" destdir="${clientclass-dir}"

includes="**/*.java"/>

<javac

srcdir="." destdir="${clientclass-dir}"

includes="com/test/webservice/client/*.java"/>

</target>

<target name="run" >

<java fork="true"

classname="com.test.webservice.client.Main"

failonerror="true" >

<classpath refid="client.class.path"/>

</java>

</target>

</project>

 

************************************************

4.  Create the client specific artifacts:

Create client specific artifacts by running the below ant command

ant build-client

This would generate the client specific files under the output/clientclasses folder.

5. Create a Java client:

Create a java standalone client to access the WebService deployed using the client artifacts generated by the clientgen utility.

A sample client would look like below.

*****************************************************************

 

package com.test.webservice.client;

import com.test.webservice.client.*;

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();

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

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

System.out.println(result);

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

}

}

 

*****************************************************************

6. Compile and execute the java client and you can see that it is displaying the response from the WebService.

javac -d . Main.java

java com.test.webservice.client.Main

For further reading:

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/webserv/use_cases.html#wp244847

Downloads :

SourceFiles

 

Cheers,

Wonders Team.

WebService by Bottom Up approach using ant script

The JAX-WS allows you to implement a simple java class as a webservice by exposing its public methods as webservice operations.

There are two programming approaches to develop a WebService.

 

1. Code-First This is a bottom-up, implementation-first strategy where we write the Java class and the data POJOs representing the complex data types used by the web service operations. Then, we use WebLogic Server’s JAX-WS tools to generate the web service’s WSDL interface and associated XML schema types. In JAX-WS terminology, this approach is often referred to as Java-to-WSDL.

 

This approach consumes a JWS (Java Web Service) file, which is a simple java class annotated with @WebService annotation at the beginning that tells the Java interpreter that you intend to publish the methods of this class as a web service.

The output is a WSDL (Web Service Descriptor Language) an XML language for describing Web services.

 

2. WSDL-First This is a top-down, interface-first strategy where we manually create the web service’s WSDL interface and any associated XML schemas. Then, we use WebLogic Server’s JAX-WS tools to generate the Java interface and the data POJOs. Finally, we complete the web service implementation by writing a class that implements the generated Java interface. In JAX-WS terminology, this approach is often referred to as WSDL-to-Java.

The below post shows a sample example of developing a WebService by BottomUp approach using an ant build script.

1: Generate a JWS file.

JWS file can be developed by annotating a simple java class file using the @webservice annotation.

A sample JWS file looks like below.

****************************************************************

 

package com.test.webservice;
import javax.jws.WebService;

@WebService(name="HelloWorldPortType", serviceName="HelloWorldService")
public class HelloWorldImpl {
public String sayHelloWorld(String message) {
try {
System.out.println("sayHelloWorld:" + message);
}
catch (Exception ex) { ex.printStackTrace(); }
return "Here is the message: '" + message + "'";
}
}

 

****************************************************************

2: Compile the JWS file.

Save the file to any folder like c:\HelloWorldWebService and compile the same as below.

javac –d . HelloWorldImpl.java

That would create the directory structure according to package name specified in the class.

3. Create a standard Ant build script:

In the ant script, include the WebLogic’s jwsc ant task.

The jwsc Ant task takes as input one or more Java Web Service (JWS) files that contains both standard (JSR-181) and WebLogic-specific JWS annotations and generates all the artifacts you need to create a WebLogic Web Service.

A jwsc ant task definition looks like below.

<taskdef name=”jwsc”  classname=”weblogic.wsee.tools.anttasks.JwscTask” />

A sample jwsc ant task looks like below.

 

<target name="build-service">

<jwsc

srcdir="."

destdir="${ear-dir}">

<jws file="examples/webservices/hello_world/HelloWorldImpl.java"

type="JAXWS"/>

</jwsc>

</target>

 

NOTE: After generating all the artifacts, the jwsc Ant task compiles the Java and JWS files, packages the compiled classes and generated artifacts into a deployable Web application WAR file, and finally creates an exploded Enterprise Application directory that contains the JAR file. You then deploy this Enterprise Application to WebLogic Server.

4: Generating the client specific files (Optional):

If you want to generate components that client can use to invoke the WebServices, then include the clientgen ant task. This ant task reads from the existing WSDL file to generate the components.

A clientgen ant task definition looks like below.

          <taskdef name="clientgen"
            classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

A sample clientgen ant task would look like below.

 

<clientgen

wsdl="http://${wls.hostname}:${wls.port}/HelloWorldImpl/HelloWorldService?WSDL"

destDir="${clientclass-dir}"

packageName="com.test.webservice.client"

type="JAXWS"/>

 

Along with the above annotations, we specify other generic tasks like wldeploy etc.

A complete ant build script would look like below.

*************************************************************

 

<project name="webservices-hello_world" default="all">

<!-- set global properties for this build -->

<property name="wls.username" value="weblogic" />

<property name="wls.password" value="weblogic" />

<property name="wls.hostname" value="localhost" />

<property name="wls.port" value="7001" />

<property name="wls.server.name" value="AdminServer" />

<property name="ear.deployed.name" value="helloWorldEar" />

<property name="example-output" value="output" />

<property name="ear-dir" value="${example-output}/helloWorldEar" />

<property name="clientclass-dir" value="${example-output}/clientclasses" />

<path id="client.class.path">

<pathelement path="${clientclass-dir}"/>

<pathelement path="${java.class.path}"/>

</path>

<taskdef name="jwsc"

classname="weblogic.wsee.tools.anttasks.JwscTask" />

<taskdef name="clientgen"

classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

<taskdef name="wldeploy"

classname="weblogic.ant.taskdefs.management.WLDeploy"/>

<target name="all" depends="clean,build-service,deploy,client" />

<target name="clean" depends="undeploy">

<delete dir="${example-output}"/>

</target>

<target name="build-service">

<jwsc

srcdir="."

destdir="${ear-dir}">

<jws file="HelloWorldImpl.java"

type="JAXWS"/>

</jwsc>

</target>

<target name="deploy">

<wldeploy action="deploy" name="${ear.deployed.name}"

source="${ear-dir}" user="${wls.username}"

password="${wls.password}" verbose="true"

adminurl="t3://${wls.hostname}:${wls.port}"

targets="${wls.server.name}" />

</target>

<target name="undeploy">

<wldeploy action="undeploy" name="${ear.deployed.name}"

failonerror="false"

user="${wls.username}" password="${wls.password}" verbose="true"

adminurl="t3://${wls.hostname}:${wls.port}"

targets="${wls.server.name}" />

</target>

<target name="client">

<clientgen

wsdl="http://${wls.hostname}:${wls.port}/HelloWorldImpl/HelloWorldService?WSDL"

destDir="${clientclass-dir}"

packageName="com.test.webservice.client"

type="JAXWS"/>

<javac

srcdir="${clientclass-dir}" destdir="${clientclass-dir}"

includes="**/*.java"/>

<javac

srcdir="." destdir="${clientclass-dir}"

includes="com/test/webservice/client/**/*.java"/>

</target>

<target name="run">

<java classname="client.HelloWorldService"

fork="true" failonerror="true" >

<classpath refid="client.class.path"/>

<arg line="http://${wls.hostname}:${wls.port}/HelloWorldImpl/HelloWorldService"  />

</java> </target>

</project>

 

*************************************************************

5. Generate the WebServices artifacts:

Generate the WebServices artifacts by running the ant script as below:

ant build-service

This would generate the required WebServices Artifacts.

6. Deploy the WebService:

Deploy the WebService on to the WebLogic Server by running the below command.

ant deploy

7. Test the WebService:

Test that the Web Service is deployed correctly by invoking its WSDL in your browser:

http://host:port/HelloWorldImpl/HelloWorldService?WSDL

A sample WSDL would look like below.

This suggests that the WebService is successfully deployed.

WebLogic server provides a Test Tool for testing the WebServices where you can see the Service request/response.

a.  Go to the WebService EAR Application deploymed –>  Testing  –>  Select the testing point as ‘Test Client

b. Pass the argument and click on the WebService operation.

NOTE: You can download the source files used for the demo, below:

Source

If you want to create a WebService in an IDE (Eclipse) refer the below post.

http://weblogic-wonders.com/weblogic/2011/05/19/webservices-in-weblogic/

Further reading:

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/webserv/use_cases.html

Cheers,

Wonders Team. 🙂

WebServices in WebLogic

Web services are de facto standards in today’s internet world. They use XML-based standards and transport protocols to exchange data with clients.

The below post gives a brief understanding of the webservices in WebLogic Service.

Before moving on with a sample WebServer demonstration, lets understand the structure of the WebLogic WebService Container.

WebLogic WebService container implements the JAX-WS 2.1 specification and provides built in WS-1 Basic Profile inter-operablity support. Facilitates the processing of the SOAP requests and response. It is integrated with WebLogic Server Security to provide WS security standards like WS-Security and SAML tokens.

WebLogic Web Service container looks like below.

The web services container provides two transport mechanisms for invoking web services:

  1. SOAP over HTTP and
  2. SOAP over JMS.

 

Follow the below steps to create a sample Web Service using IDE:

1. Create a WebService project in IDE:

Open your IDE (Eclipse), then create a WebService project

2: Create JWS (Java Web Service) file:

Create the JWS file that implements the Web Service using the @webservice annotation.


import javax.jws.*;

@WebService(serviceName="HelloWorldService" , name="HelloWorldPortType")


public class HelloWorldImpl {

@WebMethod public void hello()
{
System.out.println("*** Sample Test WebService Application ***");
}

public String sayHelloWorld(String message)
{
try
{
System.out.println("sayHelloWorld:" + message);
}

catch (Exception ex)
{
ex.printStackTrace();
}

return "Here is the message: '" + message + "'"; } }

 

 

Note:  @WebService annotation at the beginning that tells the Java interpreter that you intend to publish the methods of this class as a web service.

The @WebMethod annotation customizes a method that is exposed as a web service operation. The associated method must be public.

3: Deploy the WebService:

Clean and build the project, then run the Web Service on the server.

4: Test the WebService:

Test that the Web Service is deployed correctly by invoking its WSDL in your browser:

http://host:port/HelloWorldImpl/HelloWorldService?WSDL

You construct the URL using the default values for the contextPath and serviceUri attributes. The default value for the contextPath is the name of the Java class in the JWS file.

A typical WSDL file would look like below.

You can also create a WebService using ant task jwsc,

Refer the below example for the same using ant  script.

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/webserv/use_cases.html#wp241983

Note: You can invoke the WebService using a standalone client or a Web Application.

Refer the below link for the same.

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/webserv/use_cases.html#wp244847

Regards,

Wonders Team 🙂