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.shand 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.logand 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.jspand 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.propertiesfile 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
messageand restart the App Server. Just go to
./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,
/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"> <env:Body> <ns0:QuoteRequest> <Symbol>SUNW</Symbol> </ns0:QuoteRequest> </env:Body> </env:Envelope>
<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"> <env:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd"> <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"> <saml:Subject> <saml:NameIdentifier>wsc</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName> <KeyValue> <RSAKeyValue> <Modulus>AIE1oq...</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </KeyValue> </KeyInfo> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>zdCY/1iqOMUJq/RvxsaDPWM4+7c=</DigestValue> </Reference> </SignedInfo> <SignatureValue>ApcX/D...</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIICmj...</X509Certificate> </X509Data> </KeyInfo> </Signature> </saml:Assertion> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>Sccy9a3A7Ps27f3pf9adkRWuGvU=</DigestValue> </Reference> </SignedInfo> <SignatureValue>aE9vKM...</SignatureValue> <KeyInfo> <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> </SecurityTokenReference> </KeyInfo> </Signature> </wsse:Security> </env:Header> <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a"> <ns0:QuoteRequest> <Symbol>SUNW</Symbol> </ns0:QuoteRequest> </env:Body> </env:Envelope>
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.