Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

Accessing an HTTPS web service from WAS web client

Calling an HTTPS web service is a hell, if all our configurations are not correct. Accessing or calling a secured or HTTPS web service from a WAS web client, involves some configuration at the WAS side. If we miss these configurations we will get some nice SSL exceptions.

In order to get rid of all these SSL exceptions we need to import the server certificate to WAS trust store. So first extract the server certificate. To extract the server security certificate enter the URL in the browser (I was using IE). The browser will show the security alert pop up. Click on View Certificate

Now click on the Details tab and click on ‘Copy to File’ button

The certificate export wizard will be open. Click on Next button. From the export file format page accept the default values (DER encoded binary X.509 (.CER) will be selected by default) and click on next.

In the next screen enter the location where we want to store our certificate. (I used d:\wps.cer)

Click next and finish. We will be presented with a dialog box saying ‘The export was successful’. OK. We have done with our certificate export. The next step is to import the SSL certificate to server trust file.

For importing the SSL certificate to WebSphere Application Server’s trust store we need to know the location of the trust store file. To check the SSL setting, login to admin console. Click on SSL under security menu. From the SSL configuration repertoires page click on your SSL settings configuration link. Find out the trust file name and path under Trust file section.

If you are using the default settings the trust file name will be DummyServerTrustFile.jks. The default path will be WAS_INSTALL_DIR/profiles/ /etc/

Now go to WAS_INSTALL_DIR/bin directory and execute the iKeyMan.bat file. The IBM Key Management utility will be opened up. Click on ‘Key Database File’ and select open. From the dialog box opened select Key database type as JKS and enter the Server trust file name and path (DummyServerTrustFile.jks in my case).

Click on OK button. You will be prompted to enter the password. If you are using the default server trust file the default password for DummyServerTrustFile.jks is WebAS. Enter the password and click on OK.

Click on Add and select the server SSL certificate file which we extracted using Internet Explorer. (If you are not able to find the add button, select the Signer certificates under Key database content drop down) Click on OK button. You will be prompted to enter a label for the certificate. Enter the label you want for the certificate and click on OK. The server SSL certificate will be added to the WebSphere Application Server trust store. You are done. Close IBM Key Management tool and restart the application server. Now you will be able to access HTTPS web service from within your WebSphere Application Server without any problems.

Application already exists in the configuration repository error when installing new EAR in WAS admin console.

If we can screw up our enterprise application installation properly, we would reach to a state where we cannot go forward and backward. It is a nice state in which if we try to uninstall the application we would get an error message from WebSphere. Whatever may be the reason we will not be able to uninstall the enterprise project using WAS admin console. Then we will try our luck by installing new enterprise application unluckily WAS wouldn’t allow us to do that also. This time WebSphere Application Server would give a nice error message. “Application already exists in the configuration repository”.

The solution to this issue is to manually delete/uninstall the application by editing the configuration file. Do a search for your ear file in the file system and delete all the occurrences of the XXX.ear folder (You can see one .ear directory in your WAS_INSTALL_DIR/profiles/ /installedApps directory and one in WAS_INSTALL_DIR/profiles/ /config/cells//applications folder). Once we deleted these entire XXX.ear folders, delete all the contents of temp and wstemp folder. Now go to

WAS_INSTALL_DIR\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>\

And edit the file serverindex.xml.

In this file we can see an entry for our application within the tag

 
<deployedApplications>xxx.ear</deployedApplications>

Delete this entry. We are done. Now we can install our application using WebSphere admin console without any issues.

Some times there might be cases like forgetting WebSphere admin console password where we need to disable WebSphere Application Server security by editing configuration files without logging into the WAS admin console. In order to does this go to

WAS_INSTALL_DIR/profiles/<profileName>/config/cells/<cellName>/

and open the file security.xml. Search for a tag name

<security:Security.

This would be the first tag in security.xml file. In this tag we can see an attribute called

enabled="true"

Just change the value to false. Save the file and restart the server. Security will be disabled on the server.

A shared or global library can be used when if we want to associated some library files to a deployed application.

In order to associate a shared library to a deployed application go to Applications -> Enterprise Applications -> and click on the application we want. From the window appeared click on Libraries. The library reference page will be displayed with all the libraries currently associated. Click on Add and select the library from the drop down box. click on Apply and save the changes to the master configuration.

Accessing BPC API using web service

If we want to create our own interface for working on Human Tasks, we need to use use the Business Process Choreographer APIs. Most of the time these user interface pages will be deployed in a separate Application Server and our human tasks and business processes will be running in another WPS box. The Business Process Choreographer API can be accessed in two different ways. One is BPC EJB API calls and another is BPC API calls using web service. Here I will be explaining what are the configurations required to access BPC API using web services from a web application.

WebSphere Process Server mandates security to be turned on, for accessing BPC API using web services. If you want to know how to turn on security in WAS, read my post here. Enabling security in WAS 6.0

Once the security is turned on, we need to share the LTPA key between the WAS server and WPS server. Select Global security from security menu. Now expand the ‘Authentication mechanisms’ link under Authentication section.

Now click on LTPA. In the window opened, enter the password you want for your LTPA key. Apply and Save the changes to master configuration. Now click on Generate LTPA key and Save the changes again to master configuration. Now we need to enter the keyfile name and location where we want to store the LTPA key. Save the settings to your master configuration and click on Export Keys. A key will be generated in the location we specified. Take this key and import it into the other server using the password used for generating the key.

The next step is to download the required WSDLs from admin console. For this login to admin console of WPS and navigate to Applications -> Enterprise Applications -> BPEContainer_nodeName_serverName. Here the nodeName will be the name of your WPS installation and serverName will be the name of your WPS server installation. In my case the nodeName is widNode and server name is server1

Now click on Publish WSDL files link.

Now click on the link ending with .zip and a download popup window opens. Save it to a temporary location in your file system. Before downloading the file, if you want to change the HTTP end point url, click on ‘Provide HTTP endpoint URL information’ link from ‘BPEContainer_widNode_server1′ menu.

Repeat the same steps for TaskContainer_widNode_server1 application also.

If you don’t have the WSDL files listed in your admin console, you may need to upgrade to WID version 6.0.2.

The next step is to generate web service client from the wsdls we downloaded from admin console. For that I copied the contents of wsdl folder after extracting BPEContainer_widNode_server1_WSDLFiles.zip to a temporary directory inside my web application. Now generate the web service client as mentioned in this post. Generating web service proxy client Here I generated my web service client with no wrapped style. (Windows -> Preferences -> Web services -> Code Generation -> IBM WebSphere run time -> ‘Generate Java from WSDL using the no wrapped style’ check box is checked.). Don’t ask me why I chose no wrapped style. . I feel that is better

If the web service client generation got over. Open your web.xml go to References tab and make sure that you have a Service Reference with name ‘service/BFMWSService’.

Now we need to create a new J2EE role for representing the authorization. Go to the security tab of Deployment Descriptor and click on Add under ‘Security Roles’. Enter WIDUser as the name of the role and click on Finish.

In the ‘security constraints’ section click on add and enter a name for the security constraint.

Click on Next. Enter the resource name and the url pattern. In my case I used /* as my url pattern to protect all the pages.

Click on Finish.

Click on Add under ‘Authorized Roles’ section. Select WIDUser and click on Finish.

Save the changes to the deployment descriptor (web.xml).

Now navigate to ‘WS Extention’ tab. Select service/BFMWSService under ‘Service References’ section and select BFMWSPort under ‘Port QName Binding section’.

Under ‘Request Generator Configuration’ expand ‘Security Token’ and click on Add.

In the dialog box opened enter the details as shown in the figure.

Click on OK.

All the settings required at ‘WS Extention’ tab also over. Now click on ‘WS Binding’ tab and select service/BFMWSService under Service references and BFMWSPort under Port Qualified Name Binding section. Expand ‘Security Request Generator Binding Configuration’ and ‘Token Generator’. Click on Add. Enter the details as shown in the figure.

Save the changes to DD.

Repeat all the steps performed in WS Extension and WS Binding tab for Human Task web service reference also. When making the changes for Human Task service, make sure that you are using a different name for the token generator.

Go to Pages tab of your DD. Under Login section select BASIC as the authentication method and enter a Realm name.

Now we have done with all the changes required in the web.xml.

The next step is to add the same roles in the EAR deployment descriptor (application.xml) also.

Open the deployment descriptor of your EAR Project which contains the web module. Go to the security tab and click on Gather to get all the roles defined in web.xml. Select WIDUser under security and select ‘All authenticated users’ under WebSphere Bindings section.

Well we are ready with our configuration for a secured HTM and BFM web service call.