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:
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,
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
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,
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):
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
And here is the secured SOAP message as it goes onto the wire:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
<saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
<KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
<SecurityTokenReference xmlns="http://schemas.xmlsoap.org/ws/2003/06/secext" wsu:Id="STR1">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
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.