web services

Releasing a new product into one of the worst economic climates ever would generally be considered a bad move, but for SpringSource it may prove a master stroke. Recently they announced that early next year (Jan/Feb) version 1.0 of tc Server, a fully supported, business-friendly edition of Tomcat 6.0, will be available. For those in the Java world Tomcat is the first port of call when developing or deploying web applications. This is because it is free (open source), lightweight and relatively easy to use compared to the Java application server competition; JBoss, GlassFish, WebLogic and WebSphere.

Unfortunately when compared to alternatives Tomcat has never been as well supported in the role of mission critical, business server. JBoss does support Tomcat so that it can fulfill the role of servlet engine for their application server, but most will acknowledge the two are quite different beasts. Other companies ship Tomcat as part of their products, for example Novell and Alfresco, but in these cases support is of a token nature and generally extends only to how the company's own software runs within it. So in this cloudy support and economic environment it is easy to see why SpringSource is moving to offer a supported, business-friendly edition of Tomcat.

A few months ago I had a patch accepted by the JA-SIG CAS project to enable this single sign-on (SSO) service to automatically authenticate users who are part of an internal Novell network. The benefit of this is that once a user has logged into their corporate network they do not have to authenticate themselves when they use any of the company's web applications. CAS is a good choice for an SSO solution because it is free, fairly simple to setup and has libraries for integrating with Java and just about every other web language. Also, due to its relative simplicity, many popular web applications support CAS 'out of the box', so it pays to do some checking before reinventing the SSO wheel.

How exactly this transparent authentication mechanism works is a little complicated, but in practice it occurs in a fraction of a second without any intervention. Below is a diagram outlining the actions that take place and a brief description of what happens at each step.

1. The staff member logs in to the Novell network to gain access to their desktop.
2. Once logged in the user visits an internally hosted web application. (e.g. CRM, DMS, etc.)
3. Because the user is not logged in, the web application returns a CAS redirect command to the browser.
4. The user's browser is automatically redirected to the CAS web service for authentication.
5. The CAS service detects the incoming I.P. address and performs an LDAP search for this value in the eDirectory.
6. The LDAP search finds the user's I.P. address and returns their credentials.
7. CAS creates an authenticated session for the user and returns a one-time use ticket to the browser.
8. The browser automatically redirects back to the web application and presents the authentication ticket for validation.
9. The web application checks this ticket against the CAS service. If valid the user's credentials are returned.
10. The web application creates an authenticated session and returns the relevant HTML content to the browser.

Setting all this up is not too difficult, so long as you carefully follow my instructions on the CAS wiki. The key is understanding what is going on and how the CAS configuration files work to achieve this task. The added bonus is that because this technique uses information stored in eDirectory it works with (pretty much) any Internet browser without any extra client-side software.

 

If you have done any work with web services (especially SOAP) you will appreciate the value of a good TCP monitoring tool. Wireshark is arguably the best network monitoring tool available, but it is complicated and for monitoring plain old HTTP transactions is akin to hitting the proverbial nut with a sledgehammer. Fortunately Apache have TCPMon, a light-weight, Java-based TCP monitoring utility that lets you quickly see what TCP transactions are taking place between your computer and a server (be it local or remote).

TCPMon does not need to be installed, just download the latest version and execute the relevant startup script (.bat for Windows, .sh for OSX/Linux). There are very few options, but to monitor TCP traffic between your client and a server set the listen port to the local port you will be sending requests to and the target hostname/port to where you want the requests sent:

For example if you wanted to track TCP traffic between my browser and google.co.nz enter www.google.co.nz as the target hostname and port 80 as the target port. Then point your client (i.e. browser) to http://localhost:8888 (where 8888 is the listening port). TCPMon will take your inbound TCP request, forward it on to http://www.google.com:80 and record what gets returned. Whilst all this takes place you can sit back and inspect the TCP transactions. Okay completely useless to normal people, but for anyone that has had to debug a SOAP request quite invaluable.

 

The ProgrammableWeb has a great rundown on all the available Web Service API's available for such services as Google Maps, Flickr and everything else under the sun. It makes good use of tagging to get at the API's and is a useful resource for determining what is available out on the big, bad Internet.