After 11 months of waiting and planning, Rae and I are finally on our way to Austin. I've never before felt the mix of emotions that I felt on Sunday as we frantically caught up with people before we left. It's a strange and unsettling mix of nerves, excitement, sadness and fear. Once the last-minute dash into West End to see my close friends from UQ basketball was done, all those emotions gave way to a strange zen-like calm as we did the final pack.

I'm writing this from LAX as Rae sleeps beside me; the flight from Brisbane has left her exhausted and we have another two and a half hours before our next flight. I'm glad we left ourselves so much time between flights, as the line at the domestic security checkpoint was obscenely long. For those that know Terminal 4 the line was out the door next to the escalator and a good 50 metres down the drop-off lane, which is easily the worst I've ever seen it.

The flight over was with V Australia, instead of the usual Qantas for business travel, and I can highly recommend them. It was a newer plane (Boeing 777) with a better fit-out, it had wide-screen monitors (albeit with a smaller selection of movies), the food selection was good and the hostess was really helpful in calming Rae's travel nerves. To be honest, I don't know why anyone would choose Qantas for the economy-class BNE to LAX trip any more.

Immigration was painless too, which has been my experience on my last two trips. The upgrades at Tom Bradley International Terminal have really helped bring the lines down, as has the simple math of adding more immigration officers. Ours was extremely helpful, even going out of his way to see if he could stamp Rachel's passport for a 12-month entry on her B2 visa instead of the usual 6 months. Turns out he can, and he did; he also had some good advice about what to do when we need to get it re-stamped in a year's time.

So... one more flight to go. Next stop -- Austin, TX!

Overview

The XSPA technical committee defines profiles of OASIS open standards to enable secure, cross-enterprise exchange of personal healthcare data. Built on XACML, SAML and WS-Trust the XSPA defined profiles enable healthcare staff to access a patient's data at their "primary care provider" in a manner that is secure, respects the patient's privacy wishes and enforces access control based on organisational constraints.

This year at RSA 2010 OASIS put together a demonstration booth with three separate interop events -- XSPA being one of them. IBM participated in this event, along with Oracle (using Sun technology) and Jericho Systems. As has been the case in previous XSPA demonstrations, Veteran's Affairs (VA) provided the client and server applications that call out to the various vendors' components.

This year the focus was on showing support for the new WS-Trust profile, with IBM and Sun/Oracle providing interchangeable WS-Trust endpoints for the client domain's STS. The infrastructure built for previous interop events for the XACML profile is still in place -- in this event IBM's XACML PDP was used for the client domain, and Jericho's XACML PDP was used for the service provider domain.

A number of use cases were demonstrated at the event:

1. Data masking: allowing a patient to mask parts of their medical history based on role or specific subject identifier;

2. Emergency override: if a user is unable to perform a cross-enterprise search under the course of a normal healthcare treatment, they can declare an emergency over-ride and access the data. This is still under the control of organisational policy -- the user must have the correct HL7 permissions to declare emergencies.

3. Genomic risk marker filtering -- The genome of some patients have been analysed and markers for being "at-risk" of certain health issues (such as schizophrenia) have been identified. The patient can choose to hide some of these at-risk markers to protect their privacy.

XSPA using IBM Tivoli Security solutions

IBM participated in this event using a solution built entirely on IBM products. Tivoli Security Policy Manager (TSPM) provided the runtime WS-Trust, SAML and XACML capabilities; Tivoli Access Manager (TAM) and Tivoli Directory Server (TDS) stored the user credentials and attributes for the use case at hand; and of course the whole solution is hosted on WebSphere Application Server (WAS).

TSPM contains a number of runtime security services. The ones used in this scenario are the identity service, which is the Security Token Service (STS) for the WS-Trust component, and the authorisation service, which is the XACML PDP.

The STS component is provided by the Tivoli Federated Identity Manager (TFIM) product. When a customer purchases TSPM a license to use this component of TFIM is included; however the configuration of the STS is still done via the TFIM console. The configuration instructions below include references to TFIM for this reason.

In order for the STS to issue SAML 2.0 tokens containing the XSPA-defined attributes, the LDAP server must be populated with the correct attributes.

Rather than defining a new LDAP schema, the following attributes were used to store the XSPA attributes:

• urn:oasis:names:tic:xacml:1.0:subject:subject-id = cn
• urn:oasis:names:tic:spa:1.0:subject:nip = uniqueIdentifier
• urn:oasis:names:tic:spa:1.0:subject:organisation = organizationName
• urn:oasis:names:tic:spa:1.0:subject:organization-id = organizationalUnit
• urn:oasis:names:tic:xacml:2.0:subject:role = businessCategory
• urn:oasis:names:tic:spa:1.0:subject:hl7:permission = mail

In a production environment we'd most likely make the effort to clearly define a new schema, however for the purpose of this demonstration overloading existing attributes sufficed.

The following attributes for the two users in the use case were used:

Doctor Bob:

• uid = drbob
• CN = Doctor,Bob
• uniqueIdentifier = 100035
• organizationName = Healthcare Domain A
• organizationalUnit = 1.0.0.0.0.1
• businessCategory = MD/Allopath
• mail = PRD-003, PRD-005, PRD-006, PRD-009, PRD-010, PRD-012, PRD-017

Nurse Alice:

• uid = nursealice
• CN = Nurse,Alice
• uniqueIdentifier = 100040
• organizationName = Healthcare Domain A
• organizationalUnit = 1.0.0.0.0.1
• businessCategory = Registered Nurse (RN)
• mail = PEA-001, PRD-006

A custom TFIM mapping module was written to extract all the attributes for a given user from the LDAP into the STSUU. This custom module searches for the Principal name (using a configured attribute, for example 'id') under a configured base DN and extracts all the attribute values. An XSLT mapping rule then maps the required subset of these LDAP attributes to XSPA attribute identifiers as per above.

The XSLT mapping rule also extracts any passed Claims in the XSPA namespace and places them into the returned SAML assertion. Claims are passed in the form:

<trust:Claims Dialect="urn:oasis:names:tc:xspa:1.0:claims">
    <xspa:ClaimType xmlns:xspa="urn:oasis:names:tc:xspa:1.0:claims" 
        Uri="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse">
        <xspa:Value>Emergency Treatment</xspa:Value>
    </xspa:ClaimType>
</trust:Claims>

This feature of the profile allows the client application to insert dynamic values into the SAML assertion, which the service provider may or may not use when authorising the request. The example given above is specifying the "purpose of use" as "Emergency Treatment"; this might allow otherwise unauthorised users access to data in order to effectively treat the patient.

The trust chain is then configured as follows:

• UsernameToken (validate, authenticate using TAM)
• LDAP attribute extraction (map)
• Default mapping module (map)
• SAML 2.0 (issue, with signature)

The SAML assertion is signed with the same key that is used for the SSL endpoint (TFIM is configured with WebSEAL as the point-of-contact in the VM we used).

For this interop, RTSS was only used for the client side's internal authorisation. The default policy was used, imported straight into the RTSS Storage Service. No modification was required. However, the service provider's policy could be modelled in TSPM if desired.

Further Reading

A number of times during the expo I was asked to email links where people can find more information about the IBM products used in the interop. As usual, the IBM Redbooks and Redpapers are the best source of information:

• Federated Identity Management and Web Services Security with IBM Tivoli Security Solutions [link]
• Understanding SOA Security Design and Implementation [link]
• IBM Tivoli Security Policy Manager [link]. I was involved in the writing of this Redpaper.

Feel free to leave me a comment if you have questions as well, and I'll do my best to answer them.

There's something sublime about flying, even if it is in a noisy 747 with a few hundred other people. The cramped conditions, uncomfortable seats and average food are all made worthwhile by one always present yet everchanging thing.

The horizon.

Sometimes it's a hard line; separating two equally blue halves of the world, ocean and late-Summer sky, with my single-serving friends and I suspended somewhere in the middle.

Sometimes it's lost in the greyish whiteness of the clouds that start just off the port wingtip and continue unchanged until well past where the horizon should be.

Sometimes it's providing the platform for a deep orange sunrise to use as leverage to overcome the cold, black night. Cold and serene; yet giving rise to the same day I've seen before on the other side of the world.

It's peaceful up there, isolated from the world. Isolated from checking Facebook or Twitter every minute; isolated with my thoughts about what the journey ahead will bring. It fills my head with ideas on which I am unable to act upon until I have returned to civilisation.

I think that's where the creative bursts I get when I travel come from -- this period of enforced isolation away distractions. It fills me with purpose, and energy, and the excitement of discovery.

It's wonderful.

One of the advantages of using a statically generated website through a system such as Jekyll is that you always have a local, working copy of your website. Of course, to make this seamless you should use relative URLs -- that way when testing locally everything is loaded from local files, not remote files.

However, if your posts contain relative URLs then your generated RSS or Atom feed does too. This can be a problem when integrating with a third-party feed management system like FeedBurner. Any relative URLs in your feed become relative to FeedBurner's domain; not your domain like they should be.

The easiest way I found to solve this was to use the unix utility sed (short for stream editor). Sed allows you to find and replace content from the command line. Integrated into my "build and publish" script, it allows me to detect relative URLs in my generated atom.xml file and replace them with static ones before publishing to my web host.

I place the following lines in a file called 'absolute_urls.sed':

# Replace 'href="/' with 'href="http://www.slightlytallerthanaverageman.com/'

s/ href=\"\// href=\"http:\/\/www.slightlytallerthanaverageman.com\//g
s/ src=\"\// src=\"http:\/\/www.slightlytallerthanaverageman.com\//g

Remember that relative URLs are indicated by a "/" at the start. This uses the 's' command to find all instances of href="/ and replace it with href="http://www.slightlytallerthanaverageman.com/.

Sed is then called as follows:

#Replace relative URLs with absolute ones in the feed
sed -f _scripts/absolute_urls.sed _site/atom.xml > /tmp/atom.xml
mv /tmp/atom.xml _site/atom.xml

Magic!

The time has finally come when moving to the US is starting to feel "real." This weekend Rachel and I moved out of our apartment and into our friend Phil's place; marking the second tangible step along the way to getting to the US.

The first step, of course, was having our big garage sale. Even after this sale the amount of stuff we ended up moving out to Phil's garage was more than expected. A lot of this stuff is going to either of our parent's place for storage, or being given to various friends as gifts, but it still feels like we have a lot of extra stuff to get rid of in one way or another.

I honestly thought I'd be a lot sadder about moving out of the apartment that I've been at for over four years. It'd really become my home, evolving with me along the changes in my life. I've changed from a nervous, single graduate to a confident professional engineer with a fantastic girlfriend / co-pilot; and in many ways my home had changed with me.

Long gone are the inherited couch, tables and bed from my grandparent's estate. They served me well during my share-house days, and over the years they had been replaced with a smattering of Ikea, a self-constructed TV cabinet, and Rachel's refurbished vintage chairs. Now those too are gone, sold to the lovely girl who has taken over our lease.

Yet I don't mourn the loss of these possessions -- after all, they are only things and have been willingly sold or donated to charity.

What I expect to miss, though, is the sense of having a home furnished with the combined tastes of it's tenants. That sense of having somewhere that you belong, where you control the environment and are free to do what you wish within it. That feeling will return once we find a place in Austin, I'm sure, and in the meantime we get to enjoy the company of friends and the excitement of change.