Briefly, the demo shows a wine merchant site using a Java applet to gather identity data supporting a wine purchase – age, shipping address and payment details. In the demo, the user authenticates to a financial institution, which acts as identity provider, referencing attribute providers that actually manage the different (intersecting) sets of user data.
This brings us to a classic trade-off – Hubert’s demo could equally have been implemented with identity and attribute providers running on the user’s own machine – there is nothing in the Liberty protocols that constrains the location of these functions. Having your financial institution (or wireless operator or employer or…) be your provider allows you to leverage their infrastructure from wherever in the world you happen to be. On the other hand, having providers running locally on your own machine gives you more control over your data, but only from one machine. Pick the most appropriate model for your situation – the important thing is that you have a choice.
It was Tom’s fourth birthday soon after Christmas. One of his friends gave him a Planet Frog habitat – pictured. We sent off for the live tadpoles (Leopard Frog tadpoles, apparently), put them in the habitat with spring water and we’re now feeding them regularly, waiting excitedly for any sign of legs. I’ll keep you posted…
Warning – for mature audiences only. The following post contains material of a juvenile nature and should not be viewed by anyone lacking a sense of humour.
If you’re really quick, you’ll catch a P1 documentation bug in Sun Java System Directory Editor just before it’s fixed. Here’s a cap in case the real page is gone by the time you read this (click to enlarge):
Now, that first entry under ‘People’ really shouldn’t be there… The screenshot was taken of a ‘development’ directory – I’m guessing the engineer was testing a quoted multi-word field in ‘firstname’ and just typed in the first thing that came to mind…
Anyway, some context, for the non-British English speakers out there:
- Bollocks = testicles
- Dog’s bollocks = excellent, as in “This beer is the dog’s bollocks, mate!”
- Directory Editor = A J2EE-based web application that enables you to quickly and easily manage directory data. Ships as part of Sun Java System Directory Server Enterprise Edition.
- Ezra Simeloff = Top developer, now in the Sun Identity Manager team. Truly, Ez is the dog’s bollocks when it comes to Java programming.
So – a lesson to us all – carefully proofread screenshots before they go live.
As both Eve Maler and Robin Wilton mentioned the other day, Robin, Eve and I recently co-wrote an article for the new EDS Agility Alliance magazine synnovation. The article explores the changing nature of digital identity as we leave the ‘information age’ (the Internet as the ‘great database in the sky’) and enter the ‘participation age’ (participants contributing to the read/write web). The magazine is aimed at the CxO, so we go easy on technical details, focusing instead on the social and business implications of the evolution of digital identity.
Note that the online magazine requires a free viewer. As this viewer is currently only available for Windows and Mac, the synnovation people kindly supplied me with a PDF for those of us who use more – uh – ‘Unixy’ desktop operating systems. Many thanks to EDS for their permission to post this document.
Give it a read, and feel free to leave comments here.
Back in prehistory (1998), when I was working for the tiny startup company in London that would be acquired by Sun in 2000, we were building a smartcard demo to be shown on the Sun stand at Cartes 98 – a major smartcard conference in Paris. We built a demo that ran on 5 JavaStations (remember those?) showing an ‘ATM’ that moved cash from your back account to the card, then you went to the travel agent machine and bought an airline ticket with that cash, the ticket being stored on the card. The you went to the checkin at the airport and, you guessed it, exchanged the ticket for a boarding card. Finally you went to the gate and the boarding card was removed from the smartcard. The fifth machine was a home banking terminal that showed you what was on the card at any stage in the demo, so you could see that it was all real – no smoke or mirrors.
Anyway – we spent weeks building this thing. Then, less than two days before the Sun guy arrived from California to do the acceptance test, we had a break in. They stole the server running the demo. Arse.
Luckily, the server had an external SCSI disk pack that was left intact. We waited ALL DAY for a replacement ‘pizza box’ and worked through the night to re-install Oracle (the runtimes were on the root partition of the stolen box, but the tables were on the disk pack) and get everything working.
Sun guy arrived the next day (Hi Eric M!) and did the acceptance test about 30 minutes after we finished rebuilding the demo. It worked great! Then, with the project manager clucking around like a chicken, insisting we make a backup, and with no sleep for 28 hours, I messed up a zip command and zipped each file in the root file system in place. Solaris REALLY doesn’t like it when you do that, especially when you hit directories like /etc.
I’m not ashamed to say that I was in tears. This was Friday morning – we were taking the server to Paris on Sunday. I went home, slept for a bit. One of the office heros reinstalled Solaris onto the root partition, so that night I dialled in from home, installing Oracle again and rebuilding the demo. I was getting pretty good at this by now 🙂
So – we got it all working again, got the train to Paris and worked another night ‘polishing’ the now-functional demo. Three overnights in one week. Best week of my professional life, worst week of my professional life 🙂
[…] OpenSSO … from the same blog … Web SSO, Of Course. You knew that.It’s a centrally controlled service that creates and mainains a verifiable user session and creates an audit trail. Applications use the central service to verify that the user is in session and to report audit events [from the architecture document).
Let’s see, you have to modify every app to use the service, like that’s going to happen, and you’re going to introduce another single point of failure server.
If you read a little more of the linked architecture document, you will discover that OpenSSO uses agents to SSO enable web containers. The agent is essentially a filter that refers to the central service to determine the user’s identity and whether she should be given access to the requested resource. Section 4 of the architecture describes this in the context of OpenSSO. The reference to ‘applications’ as well as agents recognizes that any application accessed via HTTP can participate in SSO. So yes, if you have a custom HTTP app, you’ll have to do some enabling. If your app runs in a web container you just have to deploy and configure an agent. Access Manager (OpenSSO’s ‘parent product’) provides agents for a huge variety of containers. We will be releasing the code for a couple of agents into OpenSSO in March.
Marty goes on to say
Under Limited scope of SSO we find “web applications that are hosted on servers that do not reside in the domain of OpenSSO services deployment will not be able to participate in SSO” …. a small and probably disqualifying limitation. Children and their toys.
I would hardly describe OpenSSO as a toy – it is based on Sun’s Java System Access Manager. OpenSSO provides SSO across systems in a single domain, so you could SSO across www.example.com, www.subdomain.example.com, hr.example.com etc. This limitation is a consequence of the cookie-based implementation that OpenSSO uses – cookies only work within a single internet domain. To cross domains to, say, www.partner.com, you need federation. Federation capability is not currently in the OpenSSO roadmap.
One of the upsides of transatlantic flight is that you get a chance to catch up on your reading. I’m in Rome this week for a Liberty Alliance Project plenary meeting, so I had about 12 hours airtime to read Digital Identity, by Phillip Windley. Windley blogs on identity management, and the cover blurb tells us that he was CTO of iMall Inc., VP of product development for Excite@Home and CIO in Governor Michael Leavitt’s administration in Utah. Windley is now an Associate Professor of Computer Science at Brigham Young University.
Windley writes authoritatively and lucidly on the ‘big picture’ issues of identity management, although the book is marred by numerous distracting typographical errors (‘security breeches’ – now where can I buy me some of those???).
Digital Identity‘s 226 pages can be divided into two sections. The first 12 chapters present an overview of digital identity and identity management. This part of the book is somewhat of a mixed bag. Chapter 9, on ‘Names and Directories’ is as good an introduction to the topic as I have seen anywhere. Windley explains why naming is critical, what a directory is and, perhaps most importantly, why it is different from a general purpose relational database. He even covers aggregation of identity data into metadirectories and virtual directories, giving the reader an understanding of the trade offs inherent between the two approaches. Similarly, I was delighted to read chapter 12 on ‘Federating Identity’. Starting from the ‘Mirage of Centralized Efficiency’, Windley uses an analogy to the evolution of the Visa credit card system to show how digital identity is evolving through four phases:
No federation – the user has separate credentials for each organization.
Consumer has separate credit relationships with individual merchants.
Ad-hoc federation – organizations link with individual business partners to achieve specific goals.
Bank of America launches BankAmericard in 1958, acting as a clearinghouse for credit between its customers and participating merchants.
Hub-and-Spoke federation – archipelagos of ad-hoc federation coalesce into clusters around powerful central players – the hubs. Hubs dictate operating rules and technical standards; spokes are left at a disadvantage.
Bank of America franchises its card to other banks nationwide in 1966, but licensees grow dissatisfied as Bank of America sets the terms of the relationship and struggles under the technical and operational burdens of maintaining the system.
Identity Network – independent entities are formed with the sole purpose of federating identities. Member organizations fund the identity networks through subscription.
In 1970, Bank of America and its licensees form National BankAmericard, later known as Visa, creating a new network with shared governance, a common purpose and a new vision.
Unfortunately, when it comes down to technical details, Windley is less sure-footed. Chapter 6 – ‘Integrity, Non-Repudiation and Confidentiality’ is very muddled on the topic of serializing digital certificates, claiming “The certificate, being a data structure, is binary data”, then going on to explain how the Distinguished Encoding Rules (DER) allow certificates to be serialized into a string of octets. Well, binary data is a string of octets. In fact, digital certificates in the X.509 standard are abstract data structures expressed using Abstract Syntax Notation 1 (ASN.1). It is from this abstract representation that DER gives us an unambiguous binary encoding.
Similarly, in Chapter 11, Windley’s otherwise excellent coverage of SAML is let down by his reference to ‘SAML authentication assertions‘, ‘SAML attribute assertions‘ and ‘SAML authorization assertions‘ as three distinct assertion types. In fact, there is only one kind of SAML Assertion, which may contain one or more statements. Each statement may be an authentication statement, an attribute statement or an authorization statement, so, crucially, a SAML authority can tell you that Alice was authenticated with a smartcard, she is in the engineering department and that she is allowed to read the file at http://foo.com/bar all in the same assertion. Windley then goes on to describe the web browser single sign-on use case of SAML in terms of the ‘pull profile‘ and ‘push profile‘. These are nicely descriptive names, but would be confusing for a reader who then turned to the SAML 1.1 Bindings and Profiles Specification and found the definition of the ‘browser/artifact’ and ‘browser/POST’ profiles (renamed to ‘HTTP artifact’ and ‘HTTP POST’ bindings in SAML 2.0).
The following 8 chapters present Windley’s approach to creating an ‘identity management architecture’ (IMA), which he describes as
"[…] a coherent set of standards, policies, certifications and management activities […] aimed at providing a context for implementing a digital identity infrastructure that meets the current goals and objectives of the business, and is capable of evolving to meet future goals and objectives."
Here, Windley writes from his experience as a CTO and CIO, presenting a realistic approach to creating an IMA with the emphasis on iterative processes – limiting the initial effort if necessary and using feedback to improve the architecture rather than trying to create the perfect architecture in one ‘big bang’. Working from a foundation of establishing governance for identity management, Windley covers business modelling (what’s out there, rather than what should be!), documenting processes, analyzing identity data, creating an interoperability framework, building a policy stack and, finally, creating the reference architecture for the enterprise and then individual systems. Along the way, we are introduced to an ‘Identity Maturity Model’ – uncomfortable reading if you recognize aspects of your organization’s identity management practice in the ‘ad hoc’ Level 1. Throughout, Windley focuses on building consensus throughout the organization on the business benefits of an IMA, rather than the imposition of rules from the IT department – a recipe for avoidance and non-compliance.
Overall, I would recommend this book to enterprise architects looking to build your own identity management architecture. If you can look past the typos, and refer to source material for the technical minutiae, you will find a valuable approach to deciding what ‘best practice’ for your organization, and moving towards it. A corrected second edition could become ‘the’ introductory text to identity management in the enterprise.
We hit another OpenSSO milestone earlier this week, opening up the Authentication Service (announcement and instructions for getting it). A good place to start is probably the Authentication Service Architecture document, but who ever reads the docs first? Download the source, build it, run the demo, think about how you can bend it to your needs.
Here’s an exclusive snippet from an internal email from one of our QA engineers today (Hi Indira!). By the way, these are really hard guys to impress…
I have just validated the SSO token created by the opensso server using the demo app. It works just GREAT!! right now I have only good things to say
- Compiled just in 49 secs on solaris 10 sparc
- Docs are pretty good
- Used 2 physical hosts
- Client and Server both are deployed on tomcat 5.5
Great work !!
If you haven’t already got a java.net ID, here’s a handy link to the registration page. If you already have an ID on java.net, you’ll need to join the project to post in the forums. (Thanks, cmort, for pointing out that this last constraint isn’t entirely obvious on the site).