Creating keystore for Tomcat 6

I've been training on Ping Identity's Ping Federate server the last two weeks. This week I'm setting up separate Tomcat servers to interact with the Ping Federate servers; on both the identity and service provider servers. Before, I hosted the quickstart apps on the same server instance as Ping Federate.

To setup SSL with Tomcat I needed to edit the server.xml file under the conf directory and then create a keystore file that Tomcat will use to verify trusted certificates sent from the federated servers.

The initial command I ran was:

>>>> : keytool -genkey -alias amf -keyalg RSA -keystore tomcat.keystore [-file 111C353A88F.crt]

The last part of the command with the -file command line argument wasn't needed. I basically created a keystore file named tomcat.keystore and a new self-signed certificate where the Java keytool prompted me with some questions listed below:

Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Andrew Fernandez
What is the name of your organizational unit?
[Unknown]: Engineering
What is the name of your organization?
[Unknown]: Ping Identity
What is the name of your City or Locality?
[Unknown]: Denver
What is the name of your State or Province?
[Unknown]: CO
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Andrew Fernandez, OU=Engineering, O=Ping Identity, L=Denver, ST=CO, C=US correct?
[no]: yes

Enter key password for
(RETURN if same as keystore password):


After this I verified what was in my keystore using this command:

>>>> : keytool -list -v -keystore tomcat.keystore

Since I didn't yet have the certificate from the federate side I then ran this command, making sure I had the *.crt file I needed to place in the keystore in the same directory:

>>>>> : keytool -import -trustcacerts -alias amf2 -file 111C353A88F.crt -keystore tomcat.keystore

Finally I use export the base certificate from Tomcat and import into my Federated server

>>>>> : keytool -exportcert -alias amf -file amfIDP -keystore tomcat.keystore

Where -alias is what the certificate goes by in the keystore file, -file is what I want to call the exported certifacate, and -keystore the actually keystore where I'll be getting the certifcate to export from.

Deletion is pretty straighforward:

>>>>> : keytool -delete -alias amf -keystore tomcat.keystore

Just specify -delete, -alias the certificate you want to delete, and the keystore you want to delete from

Mac OS X differences from Windows

Having started the new job at Ping Identity I now have a MacBook Pro with OS X.

I've had to get used to two notable differences:

1) Window resizing on the OS X is only on the lower right-hand corner versus Windows XP which can be on the bottom and sides too.

2) Copying and pasting in the Finder (which is the equivalent of Windows Explorer) is not like Windows. If I chose a file and copy it I cannot just highlight a new directory and choose paste. I actually have to enter into the directory and paste making sure the dialog title for the Finder lists the correct directory where I want to paste.

At least that's what works for me without any special changes to the OS.

Web services WSDLs and SOAP bindings

I've been testing web services for 4 years now.

Sometimes it's good to be reminded of the basics when you're explaining JAX-RPC or JAX-WS web services.

Ultimately, when you specify RPC or documental literal wrapped you're stating how the message will be translated to the SOAP envelope that is transmitted over the wire (AKA internet).

In the WSDL you specify the binding or what kind of translation you want in the binding node of the WSDL.

Then that style is used when the message is sent inside the SOAP envelope; specifically the SOAP body.

This IBM article states it well in the first paragraph.

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

Handler Chains: New schema namespace and root node

There's been a change in what is accepted for a handler chain XML file within OEPE, and possibly the WLS runtime libraries.

It used to be accepted to use http://www.bea.com/ns/weblogic/90" for the default namespace but you'll need to start using: java.sun.com/xml/ns/javaee

Also the root node needed for handler chain files needs to be: handler-chains instead of the old weblogic-wsee-clientHandlerChain.

Just to be clear here is an old example file:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-wsee-clientHandlerChain
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</weblogic-wsee-clientHandlerChain>


And the newer one:

<?xml version="1.0" encoding="UTF-8"?>
<handler-chains
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</handler-chains>

JAXB reference implementation and MOXy

JAXB is an important part of JAX-WS web services. It provides object to XML mapping and the reverse.

In OEPE, a wizard using WLS ant scripts has been used for the last two plus years to create JAXB types using Glassfish libraries. Glassfish is the reference implementation Java EE server (currently version 3).

The reference implementation (RI) for JAXB resides under Metro, the web services stack within Glassfish.

Since the JAXB RI under Metro provides great basic functionality for JAXB marshalling/unmarshalling of types and not a lot of add-on features/extensions, there are further implementations that can be used.

One resides under the EclipseLink persistent services framework and it's called MOXy.

MOXy provides support for mapping between schema and Java types, more specialized JPA mapping support and some better performance, to name a few features.

Here's a link below:

http://wiki.eclipse.org/EclipseLink/FAQ/WhatIsMOXy

JSF message bundles and locales

Java Server Faces supports localization or internationalization (I18N). You choose the term. I find them to be synonymous terms and will use them interchangeably.

If you want to split hairs go here:

http://www.w3.org/International/questions/qa-i18n

I18N allows you to accomodate your software to different languages whether it be English, German or Chinese; thereby supporting web clients around the world.

One easy way to make JSP localization work is use it in a JSF enabled dynamic web project inside an OEPE enabled Eclipse IDE.

You'll need to update the faces-config.xml file, adding properties files that you've made and locales that you support.

Here's a faces-config.xml file example:

<faces-config version="1.2">
<application>
<message-bundle>resources.application</message-bundle>
<message-bundle>resources.Greeting_fr</message-bundle>
<message-bundle>resources.Greeting_en</message-bundle>
<message-bundle>resources.Greeting_de</message-bundle>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>fr</supported-locale>
<supported-locale>de</supported-locale>
</locale-config>
</application>
</faces-config>

Each message-bundle element tag lists a language locale property file. In my case I put the properties files under src/resources. Note that the properties files listed inside the message-bundle tags don't come with *.properties file extension. It's implied.

Under locale-config I place supported languages. In my case I have English, French and German. My default is English.

The great thing about OEPE is the ability to add message-bundle and locale-config elements to the faces-config.xml file by using the Faces Configuration Editor. You can easily add new languages that are supported and browse for new language message bundles.

When I do want to use message bundles I can test it with the loadBundle tag and outputFormat tags inside a JSF enabled JSP page.

Here's an excerpt from the JSP page:

<f:loadBundle basename="resources.Greeting" var="greeting1" />
<h:outputFormat value="#{greeting1['login']}">
<f:param value="Joe"></f:param>
<f:param value="05/19/2010"></f:param>
</h:outputFormat>
<h:outputFormat value="#{greeting1['welcome']}"></h:outputFormat>

Note that I specify "resources.Greeting" for basename.

The first part before the dot is the folder and the second half means all the Greeting_*.properties files.

My properties files are:

1) Greeting_de.properties
2) Greeting_en.properties
3) Greeting_fr.properties.

I don't need to add the underscore.properties to basename since it's implied, meaning any file will be used for a localized message depending on the client preferred language.

The country will be figured out by what the browser passes to the server. In Internet Explorer I can change my preferred language and see a different message. This is done under Tools > Internet Preferences > General > Languages. I can easily add and rearrange the preferred languages within that Internet Explorer dialog and reload the web page to see the language change on the fly.

Importance of quality, time and features

In an ideal world quality, time and features should be given equal weight in the software development lifecycle. The ranking for most firms it seems is: 1) quality 2) time 3) features. Quality should always be given precedence. If things need to go, due to scheduling, etc..., you need to throw out features first, then time and always try to maintain quality standards. Makes sense and we practice that here too.