Thursday Dec 18, 2008

Finishing 2008 with OpenSSO's Java EE Policy Agents

I mentioned part 1 of 'Protecting Applications With Jave EE Policy Agents' at the beginning of this month; this week sees part 2, with Hua Cui joining Sean and Marina to give more detail on how to deploy OpenSSO's Java EE Policy Agents for single sign-on within a single DNS domain, configuring several sample Java EE Web applications and having OpenSSO provide single sign-on between them.

And, with that, I'm taking a break until 2009. It's been an amazing year for OpenSSO - we shipped our first Express release in July, and our first fully supported commercial release, OpenSSO Enterprise 8.0, in November. We've seen integrations with systems from ActivIdentity 4TRESS to YubiKey (YubiKey was the closest I could get to 'Z' ) and deployments from ACA/Telenet to Yota. Dang it! Isn't there anything OpenSSO-related that begins with 'Z'?

Meanwhile, on the community side, the number of registered project members has risen from about 550 at the start of 2008 to over 900 today, while the monthly traffic on the OpenSSO Users mailing list has gone up from around 200 messages a month to nearly a thousand. Even the IRC channel is buzzing now, with contributors from Minsk to Shanghai talking OpenSSO around the clock. If you haven't yet dipped your toes in the OpenSSO water, perhaps now's the time to get started?

Tuesday Apr 01, 2008

links for 2008-04-01

Friday Mar 09, 2007

Welcome, Mrudul!

A big shout down the corridor to Mrudul Uchil, lead engineer on Web services security and Java EE SDK/NetBeans Enterprise Pack integration in the Access Manager team. Mrudul just started blogging - anyone working with the new Web services security features in Access Manager 7.1 or looking forward to this technology appearing in OpenSSO needs to subscribe to Mrudul's blog.

Tuesday May 23, 2006

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:

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; ./ 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. 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 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/ Beware - there is another file for the AM server - on my machine it's at /home/pat/ 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 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):
  • <env:Envelope xmlns:env="" xmlns:enc="" xmlns:ns0="" xmlns:xsd="" xmlns:xsi="">
  • And here is the secured SOAP message as it goes onto the wire:
  • <env:Envelope xmlns:env="" xmlns:enc="" xmlns:ns0="" xmlns:wsu="" xmlns:xsd="" xmlns:xsi="">
        <wsse:Security xmlns:wsse="">
          <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">
                  <KeyInfo xmlns="">
                    <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
            <Signature xmlns="">
                <CanonicalizationMethod Algorithm=""/>
                <SignatureMethod Algorithm=""/>
                <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
                    <Transform Algorithm=""/>
                    <Transform Algorithm=""/>
                  <DigestMethod Algorithm=""/>
          <Signature xmlns="">
              <CanonicalizationMethod Algorithm=""/>
              <SignatureMethod Algorithm=""/>
              <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
                  <Transform Algorithm=""/>
                <DigestMethod Algorithm=""/>
              <SecurityTokenReference xmlns="" wsu:Id="STR1">
                <KeyIdentifier ValueType="" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
      <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">

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.




« July 2016