Using Hudson as CI tool on WLS

One of the key concept of Service Oriented Architechture is that services are no longer built to last, but rather built to change.

In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

Now if we follow SOA principles, then the design and implementation should be optimized. However what SOA doesn't address is how we build, deploy, test and finally released that code into production.

This is where a CI tool (details of CI can be found here) comes very useful.

Hudson is such a continuous integration (CI) tool written in Java, which runs in a servlet container, such as Apache Tomcat or the WebLogic application server. It supports SCM tools including CVS, Subversion, Git and Clearcase and can execute Apache Ant and Apache Maven based projects, as well as arbitrary shell scripts and Windows batch commands.

In the following steps we will see how to configure Hudson on WebLogic (Due to Weblogic's class loading structure, if the hudson.war is directly deployed, the application will fail to startup. This is to because there are jar conflicts between Hudson and Weblogic. To get around the issue, we use the FilteringClassLoader mechanism so that specific hudson jars get priority in the classpath over Weblogic's jars).

Versions
-----------
Hudson: 2.2.0
WebLogic: 10.3.1 (11g R1)

Steps:
-----------
1> Downnload Hudson Binary (2.2.0) from here
2> Unzip downloaded hudson.zip
3> Go inside the unzipped location and make a .war file from the content (jar -cvf hudson.war .)
4> copy the hudson war to a directory (e.g. E:\installers\hudson) and create another folder (META-INF) in it.
5> add application.xml and weblogic-application.xml in the META-INF directory

application.xml
===============


weblogic-application.xml
========================


6> Repackage the complete content in hudson.ear and deply in WebLogic
7> Access the Hudson on http://<server_ip>:<port>/hudson

Enabling OSB to support X.509 token identity

In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. Further detail is available here

With OSB supporting X.509 certificates, guarantees that the hosts with which OSB communicates with are the ones that it expects.

Adding X.509 Support to the WebLogic Default Identity Asserter

Since OSB uses the underlying framework that is supplied by WLS, by setting the default identity asserter within WLS to accept X.509 certificates, we can allow users and/or processes to present X.509 certificates to identify themselves. To do this, we need to access the WebLogic Server console and open the Security Realm -> Providers -> Authentication tab.



within the Default Identity Asserter, under the common tab, move the X.509 token type from the available list to the chosen list.



Then under the Provider Specific tab, check the use of the Default Name Mapper. This checks that the certificates mapped to the user has not expired.



Adding WebLogic PKI Credential Mapping Provider

A Credential Mapping provider allows WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. You must have one Credential Mapping provider in a security realm, and you can configure multiple Credential Mapping providers in a security realm. It is only one of the types of credential mapper that are available. For this example we will need to have a keystore available. To do this you might need to use the keytool command.

The basic steps to create a keystores (jks) using keytool can be referred in the jdk documents, for reference the following are four easily usable commands to create identity, trust stores along with a certificate (self signed)

keytool -genkey -alias test -keyalg RSA -keysize 1024 -dname "cn=L-0219016978.XXX.com,ou=Consulting,o=XXX" -keypass password -keystore identity.jks -storepass password
keytool -selfcert -v -alias test -keypass password -keystore identity.jks -storepass password -storetype JKS
keytool -export -v -alias test -file rootCA.der -keystore identity.jks -storepass password
keytool -import -v -trustcacerts -alias test -file rootCA.der -keystore trust.jks -storepass password

To configure a Credential Mapping Provider, we need to add a new provider in the security realm, under Providers -> Credential Mapping, by clicking “New”





Once, the PKI Credential Mapper is created, configure it as below.



The type of keystore will by JKS and the keystore filename/password will be the ones given while using keytool to create the keystore.

Configuring OSB Inbound WebServices



Within the web services security list, the default_x509_handler is the one that we need to change (to use the newly created keystore).



Nw we need to set up the Token Handler Property of UseX509ForIdentity to be true.



Configuring WebLogic for SSL

The next step is to configure WebLogic Server for SSL, using the same keystore.





Next step is to create an user that is contained within certificate from the keystore. After these dynamic changes, server need to be restarted

Once we complete the above mentioned steps, our OSB system is ready to suppot the X.509 token identity.

Further reference can be pointed to Oracle WebLogic Documentation:

http://docs.oracle.com/cd/E13222_01/wls/docs103/ConsoleHelp/taskhelp/webservices/webservicesecurity/CreateDefaultWSSConfig.html
http://docs.oracle.com/cd/E13222_01/wls/docs103/ConsoleHelp/taskhelp/webservices/webservicesecurity/UseX509ForIdentity.html