Anatomy of a SAML-Secured SOAP Message

As promised, here is a dissection of the SOAP message from yesterday’s post on the AM 7.1 Beta Secure Web Services Tutorial.

First, let’s take another look at the secured message in its entirety:

<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>

It’s pretty hard to see the wood from the trees here, particularly since there are two signatures in there. Here is a somewhat abstracted version:

Working from the inside out:

  • The SAML AuthenticationStatement contains data from a SAML authority concerning a subject – that is, the person/service/device/whatever whose identity is in question here. In the AuthenticationStatement we can see a Subject element containing a NameIdentifier (which we could use to refer to this subject in future exchanges with this SAML authority) and a SubjectConfirmation element. The ConfirmationMethod element tells us how the assertion is bound to the subject. In this case, it is Holder of Key, indicating that the SubjectConfirmation also carries a public key. Assuming we trust the SAML authority, we can be confident that anything we receive that is signed with the corresponding private key came from the subject. You can clearly see an RSA public key, with its modulus and exponent, in the KeyInfo element.
  • Moving down, immediately after the AuthenticationStatement is a Signature (white in the diagram). This is an enveloped signature over the parent Assertion. This signature binds the Assertion to the issuing SAML authority. It contains an X.509 certificate which we can use to verify the signature and decide if the assertion has come from a trusted SAML authority.
  • So, now we have an assertion that contains the public key of some subject known to a SAML authority. The next Signature element (blue in the diagram) is a detached signature of the SOAP Body. This signature binds the Body (and its payload – the actual stock request that the recipient is going to process) to the subject. This Signature does not contain an X.509 certificate. Instead, it has a KeyInfo element that references the earlier Assertion – the recipient is to use the public key in the Assertion to verify the signature.

The recipient thus has all the pieces it needs to verify that

  • The message was not tampered with in transit
  • The body was signed by some subject identified by a SAML authority identified by an X.509 certificate.

In this entry I’ve covered the stock request as it appears on the wire. Next time round I’ll look at how Access Manager 7.1’s JSR 196 provider makes all this happen in the web container (App Server) with no code in the required in your web service consumer or producer.

References

Quick Guide to Access Manager 7.0 Site Configuation

This came across the internal Access Manager mailing list today. It’s too good not to post. Many thanks to David, Beomsuk and Subash for compiling this.

Overview

Site configuration in AM 7.0 provides a facility that lets Access Manager clients communicate with load-balanced Access Manager instances. While this was possible in Access Manager 6.x, site configuration provides several advantages:

  • Access Manager instance URLs are not held in state by Access Manager clients
  • Configuration is far easier and less error-prone than with Access Manager 6.x
  • Site configuration supports deployments with multiple load balancers, and with firewalls around each site, with no changes required to firewall configuration

Access Manager 6.x Naming Table on Client Side

All Access Manager clients use a naming URL stored in the client configuration (usually AMAgent.properties) to retrieve a client-side naming table, which is held in state on the client. For 6.x clients, the client-side naming table holds the URLs of needed Access Manager services for each Access Manager instance. The URLs refer to the Access Manager instances. Thus, information about servers that are likely secured behind firewalls are held in client state, which is a potential security problem.

Client to Access Manager Instance Access in AM 6.x

When a 6.x Access Manager client accesses an Access Manager instance on behalf of a user attempting to access a web app, it accesses the instance directly (assuming the user has a valid SSO token). Depending on the Access Manager service required, the client dynamically build the URL for the service based on the instance ID stored in the session token and the URLs in the naming service table. A load balancer fronting the Access Manager instances is ignored in this scenario.

This works fine as long as there is not a firewall in between the client and Access Manager instances. In this case, the client is not able to get through the firewall to the required URL on the Access Manager.

So in the scenario in which multiple Access Manager instances are fronted by a load balancer, with a firewall somewhere in the mix, it is necessary for the Access Manager client to go to the load balancer instead of directly to the Access Manager instance.

You can force an Access Manager client to do this either by setting up the /etc/hosts file so that all the FQDNs of the Access Manager instances point to the IP address of the load balancer, or by setting the com.iplanet.am. naming.ignoreNamingService property to true.

Therefore, each client has to have this property set, and whether the property should be set or not is dependent on the location of firewalls and load balancers in the topology.

Access Manager 7.0 Naming Table on Client Side with Sites Defined on Access Manager

For 7.0 clients, if a site is defined in the platform service, the client-side naming table holds the URLs of needed Access Manager services for each Access Manager site. The URLs refer to the Access Manager sites – load balancers – and not instances. Thus, information about servers that are likely secured behind firewalls are not held in client state, eliminating the potential security problem from 6.x.

Client to Access Manager Instance Access in AM 7.0 with Sites Defined on Access Manager

When a 7.0 Access Manager client accesses an Access Manager instance on behalf of a user attempting to access a web app, it accesses the Access Manager site (assuming the user has a valid SSO token). Depending on the Access Manager service required, the client dynamically builds the URL for the service based on the site ID stored in the session token and the URLs in the naming service table. Therefore, all requests go through a load balancer.

If there is not a firewall in between the client and Access Manager instances, it is not a problem, because the client should be able to get to the load balancer.

There is no need for any special configuration on the client to make this all work. As long as the nameing URL points to the load balancer, all is well.

Multiple Site Support in 7.0

Consider the case where you have multiple sites. Suppose you have:

  • A Web Server in San Francisco with a protected URL
  • A Web Server in Tampa with a protected URL
  • An Access Manager site with a load balancer and multiple firewalled AM instances in San Francisco
  • An Access Manager site with a load balancer and multiple firewalled AM instances in Tampa

You want an end user who has authenticated with the San Francisco site to be able to access the protected URL in the Tampa without re-authenticating.

In 7.0, with sites configured in the Platform Service, an Access Manager instance in San Francisco is able to perform session validation on an Access Manager instance in Tampa by referencing the Tampa load balancer.

In 6.3, although enabling the com.iplanet.am. naming.ignoreNamingService property might let the San Francisco *agent* get to the Tampa load balancer, there is no way for an Access Manager instance in San Francisco to get to the Tampa load balancer for session validation. An Access Manager instance in San Francisco can only reference the Access Manager instances in Tampa defined in the platform service. So, if these instances are firewalled, the SFO AM instance cannot reach the Tampa instance.

Making a multiple site deployment work in 6.3 requires firewall configuration in ways that are likely to be unacceptable to users.

If No Sites Are Defined in 7.0

Access Manager should work identically to how it worked in 6.x. You can define configurations with multiple instances in the platform service, configure the fqdnMap, and add realm DNS aliases as needed. But if there is a firewall behind the load balancer, the deployment will fail.

Server-Side Configuration in Access Manager 7.0

To configure Access Manager 7.0 to support sites, you need only do the following:

  • Define the site and instance lists in the platform service
  • Add realm DNS aliases as required in the realm properties for the top-level realm

Server-Side Configuration in Access Manager 6.x

To configure Access Manager 6.x to support multiple instances, do the following:

  • Define instances in the Platform Service
  • Define the fqdnMap property in the AMConfig.properties file
  • Add realm DNS aliases as required in the realm properties for the top-level realm
  • Configure clients as necessary, depending on firewall locations

Summary

The 7.0 site configuration capability provides enhancements to Access Manager security and ease of configuration.

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 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):
  • <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>
    
  • 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">
    <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.

UPDATEhere is that next installment.

At Last – Penelope Trunk Blogs

I’ve been a long-time subscriber to Penelope Trunk‘s weekly career advice column – from way back when she was known only as ‘Brazen Careerist’ and wrote for Business 2.0 and then Bankrate.com. Penelope’s writing is always sharp, funny and thought-provoking.

So, I’m delighted to discover today, via her latest email column, appropriately titled “Blogging is Essential to a Standout Career“, that Penelope now blogs.

The reason that I’m so happy is that Penelope so often gives sound advice; I can now link to it and add my own commentary. This week’s piece, mentioned above, is no exception. If you’ve hesitated to start blogging, read it and take the plunge. In fact, I would add an ‘item 0’ (sorry, I’m a techie ) to Penelope’s list of 8 reasons to blog: Blogging sharpens your mind. I always find that explaining a topic to somebody else cements it in my own mind. Writing for a (potentially) large, unknown audience, forces me to get my own thinking straight.

Welcome to the blogosphere, Penelope!

May 26 2005 – UPDATE Penelope moved her blog to her own domain – penelopetrunk.com – I’ve updated the links above.

I see your Breezy Badger and raise you a Dapper Drake

Inspired by Mark Shuttleworth on stage last week at JavaOne, and Eric‘s recent blog entry (partly) on installing Ubuntu, I spent a few hours last weekend installing Dapper Drake, the latest, greatest (currently beta) Ubuntu release.

There are more tips and tricks on installing Ubuntu on the Ubuntu Wiki than I could ever hope to cover here, so I’ll just give my first impressions…

  • Installing from the Live CD – pretty painless. It’s at this point that I start to Google for Ubuntu’s lack of a root password. Cool – pretty much matches the way I work – never login as root, but keep root capability at arm’s length via sudo.
  • Login and… what’s this? An icon in the menu bar up top advising me of updated packages. 370-odd updated packages. OK – I’ll grab those. After all, it’s the weekend… Plenty of other stuff I can do for a while.
  • Now we have an up-to-date system. Time to install a few apps. Firefox and GAIM are already there, so I just copy in .firefox and .gaim from my backed up Suse home directory. So far so good – I see all my bookmarks and log into all my IM accounts.
  • I prefer Thunderbird to Ubuntu’s default Evolution, so I use Applications – Add/Remove to grab it. Cool – it just works. Copy over .thunderbird and… I can’t see my accounts or email folders. Hmmm. ls -latr. Oh – .mozilla-thunderbird. OK – I can live with that, a quick mv and I can see my email.
  • Ooh – NetworkManager – grab that, for definite. And… it just works. Cool! No VPN support in the Ubunutu version, though. Building NetworkManager from CVS could be pretty hairy – I know that Ubuntu tweaks the standard build. I’ll live with vpnc for now.
  • I love Synergy – the open source keyboard/mouse switcher. At the time I installed Dapper, the Synaptic Package Manager was listing some 1.2.x version, rather than the current 1.3.1, so I build Synergy from source. A quick Google, apt-get install build-essential and a few other bits and pieces and I’m away – sharing my mouse and keyboard between my home system and my laptop. I just checked, and Synaptic is reporting 1.3.1, Let’s make uninstall and grab the official one… Done.
  • Skype – grab the .deb from the Linux download page, copy in .Skype and we’re done.
  • UPDATE: For VMware, Google tells me I need the correct headers for my kernel… sudo apt-get install linux-headers-`uname -r` then sudo ./vmware-install.pl. I found the IP addresses I was using for vmnet1 and vmnet8 in my old (backed up) /etc/vmware/ directory. Copy over .vmware for my favourites and the license file and… it works!

More as I discover interesting stuff… See you later

JavaOne 2006 San Francisco – TS-6673 – Federated Web Services With Mobile Devices

Rajeev Angal and I will be presenting ‘Federated Web Services With Mobile Devices’ next week at JavaOne 2006 in San Francisco. Here’s the blurb from the session catalog at the JavaOne website:

Session ID: TS-6673

Session Title: Federated Web Services With Mobile Devices

Session Abstract: JSR 172, the Java™ Platform, Micro Edition (Java ME) Web Services Specification, is a key Java ME specification that defines APIs enabling mobile devices to invoke web services.

Mobile devices are becoming an ever more popular means of transacting business; at the same time carriers and service providers are looking to differentiate themselves from their competition and cater to the ever increasing demand to provide more services to their consumers. This session describes a means of securely providing access to web resources and web services using open standards such as OASIS SAML V2.0 and Liberty ID-WSF from a Java ME enabled mobile device.

Wireless carriers act as Identity Providers (IdPs) in business alliances known as ‘Circles of Trust’ (CoTs), authenticating customers and providing them secure access to a range of Service Providers (SPs). This federated model gives customers a seamless experience that is much more than the sum of its parts. For example, a wireless carrier could form a CoT with itself as IdP and SPs providing services such as email, calendar, mapping, weather, hotel reservations, travel information and ringtones. A customer authenticates at the wireless carrier – the carrier then provides secure single sign-on to each SP via signed assertions of the customer’s identity.

As we move from simple single sign-on to identity web services, this federated environment forms the basis for providing a portfolio of services to the customer. For instance, the wireless carrier could host a location service enabling SPs to provide value-added services such as weather and hotel reservations based on the customer’s current location.

The Liberty ID-WSF and OASIS SAML V2.0 standards provide the necessary security characteristics such as privacy, confidentiality, user consent and non-repudiation to make such interactions work in a federated environment. This session will show developers how a Java ME enabled mobile device can use JSR 172 to leverage ID-WSF and SAML V2.0 in accessing federated services and providing real value to customers.

Session Topic: JAVA ME

Session Type: Advanced How-Tos

Speaker/s & Speaker/s Company: Rajeev Angal, Sun Microsystems, Inc.; Pat Patterson, Sun Microsystems, Inc.

Date: Friday May 19 2006

Time: 2:30pm

Location: Moscone Center Esplanade 301

Join Rajeev and I next Friday and discover how to implement your own mobile federated web services. Or federated mobile web services. Anyway – see you next Friday.

links for 2006-05-10