Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack

If you’ve been following Eric Leach’s blog, you’ll know that, just before JavaOne, we released a beta version of Sun Java System Access Manager 7.1 via a couple of bundles:

• Java EE 5 Tools Bundle Beta
• NetBeans Enterprise Pack 5.5 Early Access

The former download is 132 MB, the latter 89 MB. The main difference between them seems to be that the Java EE 5 Tools Bundle includes NetBeans; NB EP 5.5 assumes you already have it.

Access Manager’s role in this bundle is to secure web services. If you’re thinking “Uh oh - this is that Liberty stuff they keep pushing at me; I’ve barely got my head around basic SAML assertions, let alone ID-WSF.”, well - relax. We did show Access Manager working with Java Studio Enterprise and JSR 196 (Java Authentication Service Provider Interface for Containers) to secure web services via Liberty ID-WSF at last year’s JavaOne (there’s also a technical article on the topic); since then we have implemented WS-I BSP to secure ‘plain vanilla’ web services.

Here are my notes from installing the Java EE 5 Tools Bundle Beta and working through the Securing Web Services tutorial. I’m running Ubuntu 6.06 ‘Dapper Drake’ Beta. Not an officially supported platform, but I like to surf the bleeding edge

• Let’s get started. I downloaded the Java EE 5 Tools Bundle Beta, chmod +x netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh; ./netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh and I’m into the installer. I need to tell the installer where I’ve put Java - it doesn’t seem to know. Fair enough - this is not a standard system - I have at least three versions of Java floating around.
• The installer prompts me for ports, passwords and trundles away for a while. On completion it reports that there were some warnings. I check /tmp/netbeans-5_5-installation-20060523143837.41310.log and it looks like the installer was not able to get to Access Manager (AM) at http://_myhostname_:8080/amserver/configurator.jsp. Ah - that’s probably because it likes your system to have a fully qualified domain name (FQDN), e.g. myhostname.mydomain.com and I don’t have a domain set. This is documented in the release notes - it doesn’t seem to be a big deal, and I can get to that URL in Firefox, so we’ll just carry on.
• OK - surf to http://_myhostname_:8080/amserver/configurator.jsp and I get a nice configuration page:
  
  Those are the 5 parameters you need to set to configure AM. I left everything as default and (as expected from the release notes) got a server error. Putting a dummy domain on the end of the hostname did the trick and I’m at an Access Manager login screen.
  
  Cool! The simplest ever AM install/config
• Login with the default amadmin/admin123 (we’ll have to change that - I hate default passwords. We should add ‘amadmin password’ to the 5 configuration parameters) and I’m in the now familiar AM 7.x admin UI:
  
• Ok - install and config done. On to the Securing Web Services tutorial. The tutorial notes are a little sketchy - I’ll fill in the gaps here as I go along.
• Grab the stockapp.zip sample source and put it somewhere sensible, as suggested in the tutorial. I get two directories, stockclient and stockservice. Cool.
• Tutorial step 2 is missing an initial steplet - you need to go to the App Server admin console at http://_myhostname_:4848/ and login as admin with whatever AS password you selected at install. Hmm - I don’t see a ‘Runtime’ tab, but I can see a running App Server (in fact, I already checked that it was running by browsing http://_myhostname_:8080/ and, of course, I wouldn’t have been able to configure AM if it wasn’t running. So, according to step 2c, I can safely skip forward to step 5 in the tutorial. Except that it seems like the next thing I have to do is in step 3.
• Tutorial step 3 - yes - done this already.
• Step 4 - ah - you will definitely want to do this - set AM to full message debug logging. On my system, the config file was at /home/pat/SUNWappserver/addons/amserver/AMConfig.properties. Beware - there is another AMConfig.properties file for the AM server - on my machine it’s at /home/pat/AMConfig.properties. If you set message debug logging at the AM server but not in the AS addons, you won’t get any of the diagnostic output described below. I know - I did exactly this first time round and spent several hours trying to figure out what was wrong. Change com.iplanet.services.debug.level to message and restart the App Server. Just go to _wherever_you_installed_it_/SUNWappserver/bin and do ./asadmin stop-domain; ./asadmin start-domain.
• Step 5 - Run NetBeans and disable proxies as directed in the tutorial, since we’ll be interacting with local services.
• OK - now for some secure web service action… Start NetBeans and… Oh. NetBeans just shows me a blank window. That’s not good. Google Google Google… Ah. I have XGL and Compiz eye candy installed. This forum post gives the answer - run the Xnest nested X server, the icewm window manager and then run NetBeans in the nested X session. Fair enough. Ubuntu recommends Xephyr rather than Xnest, so I grab that, icewm and.. great - we have NetBeans! [UPDATE: See this comment for a handy little script I wrote to run NetBeans in a nested X session.] Back to the tutorial…
• Open the two projects. Cool - Web Service Provider (WSP) Security Configuration property page. Enable security, select SAML-HolderOfKey, sign reponses. Don’t forget to change the password if you overrode the default AS ‘adminadmin’ password. Ooh - we’ll have to fix that password entry field. This is beta, don’t forget.

• We can go look in the keystore, just to check that we are supplying the right password here, and that the s1as cert is there:

  ``` pat@patlinux:~/SUNWappserver/domains/domain1/config$ keytool -list -keystore ./keystore.jks -storepass password Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry s1as, May 23, 2006, keyEntry,

*   Now to the client... Web Service Client (WSC) Security Configuration, enable security, SAML-HolderOfKey, verify response. Check that password again. And we're ready to run. Build and deploy stockservice as described in the tutorial. Build and run stockclient and we have a JSP ready for input. I had to copy the URL into the browser in my main X session, since Firefox wasn't happy running a second instance in the nested X session. I also had to change 'localhost' in the URL to my real hostname.
*   Now I just press enter to get a quote for SUNW and... I get a page of canned price data. It works!!! On my machine, `ClientModule` and `ServerModule` are in `/tmp/amserver/`, I can see real, honest to goodness WS-I BSP SOAP messages with SAML assertions in the headers. I've indented for clarity and elided most of the base 64 encoded signature and key info.
*   Here's the raw SOAP message as it leaves the client code (don't forget, the whole point of this is to abstract the security stuff out of the client/server code):

SUNW

*   And here is the secured SOAP message as it goes onto the wire:

wsc urn:oasis:names:tc:SAML:1.0:cm:holder-of-key CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US AIE1oq... AQAB zdCY/1iqOMUJq/RvxsaDPWM4+7c= ApcX/D... MIICmj... Sccy9a3A7Ps27f3pf9adkRWuGvU= aE9vKM... s69f7e258e30da2b9b9f5799d4eb0c548782432bf SUNW

```

So - in the next thrilling installment, we’ll walk through that secure SOAP message and see what each bit actually does.

UPDATE - here is that next installment.