I’m sitting in seat 20A of Delta flight 101 from Atlanta to Buenos Aires, catching up with the blogging backlog that built up during the RSA Conference. I usually compose my blog entries directly in Roller‘s web UI, but, since there bain’t be no Interweb up here, I’m using Flock‘s built-in blog editor, and a very comfortable experience it is. I can type up the bulk of the text in the ‘Editor’ view, tweak formatting in ‘Source’ view and get a pretty good idea of how it will look in ‘Preview’, fiipping back and forth as I go.
While this is very convenient, what is really cool is that I have Flock in ‘offline’ mode, but it allows me to load pages from its cache, so, since most everything I’ve looked at lately is cached, I can just go to a URL, and I see it exactly as if I was connected. This lets me look up links, check references, even view source to remind myself of the formatting I use when posting over at The Aquarium. In fact, it’s probably more productive than being connected, since there’s no email to distract me
At RSA this year, as well as the Project Concordia workshop I covered last week, there were OSIS and XACML interoperability events.
The information card (aka InfoCard, aka CardSpace) portion of the OSIS event focused on testing 17 identity provider security token services (IP/STS) against 39 relying parties (RP) plus specific feature tests (note – right now, a bug in the wiki software means that both the IdP and RP feature results tables are shown under the RP heading). Last time I looked, OpenSSO worked with 11 of the identity providers and 19 relying parties. Of the remainder, many (shown as N/A in the table) were not tested due to incompatible policies – for example, it’s impossible to test an IP/STS against an RP that only accepts self-issued cards. Some others (shown as Not Tested in OpenSSO’s results) are not yet online. Of the outright failures, many on the RP side seem to be due to the assumption that the token MUST be encrypted by the IP/STS. This is somewhat ambiguous in the specification (section 8.3), which clearly states that self-issued cards SHOULD be encrypted, but leaves the question open for managed cards. I’ll let you into a secret – I inadvertently configured the OpenSSO IP/STS to not encrypt tokens; a lucky mistake in that it exposed this nit.
Meanwhile, over on the expo floor, OpenSSO was also well represented in the OASIS XACML interop event (press release). Where the OSIS event focused on basic on-the-wire compatibility, the XACML interop covered quite an elaborate use case from the U.S. Department of Veterans Affairs featuring role-based access control (RBAC), privacy protections, structured and functional roles, consent codes, emergency overrides and filtering of sensitive data. I ducked out of the OSIS interop to go take a look (and say ‘Hi’ to Bina and Dilli from the OpenSSO team) and was blown away – 7 vendors supplied policy decision points (PDPs), while OpenSSO was also the policy evaluation point (PEP) for the client side of the demo app. Actually, demo app doesn’t begin to do it justice – the application showed how a patient could set policy to control access to medical records, down through controls on individual physicians seeing your records to physician + resource (e.g. Dr Bob isn’t allowed to see my radiography results) and more. There was even an emergency ‘break glass’ override included to allow a physician (duly authenticated, of course) to get access to any of your notes via a specific affirmation that an emergency is in progress. Very cool stuff – it seems like XACML is coming of age!
More coverage by Phil, Anil and Craig
A packed schedule over the next few months – I’ll be spreading the OpenSSO gospel on three continents:
I’ll also be at the Liberty Alliance plenary meeting in Stockholm, Sweden from July 8-10. Then I’ll be taking a much-needed vacation!
Tech author Marina Sum over at Sun Developer Network continues her series of interviews; this time in the hot seat is Daniel Raskin, senior product line manager for access and federation management at Sun.
In the interview, Daniel lifts the lid on some of the cool new features coming up in Sun Federated Access Manager 8.0 (and, of course, available NOW in OpenSSO), including Fedlets, Virtual Federation, the Federation Validator and more. Exciting stuff!
Number three in an occasional series.
As I mentioned in the previous entry, I was at a SEED event this morning, up at our Menlo Park campus. As we broke for lunch I got talking to Scott Fehrman and Whitfield Diffie, and accompanied them to a very nice lunch. Of course, I couldn’t let the occasion pass without whipping out the iPhone and asking Scott to do the honors now, could I? 🙂
A few days ago I was IMing with a guy that works for one of the large systems integrators. They have an opportunity to deploy OpenSSO with a large customer. They particularly want OpenSSO, rather than, say Sun Java System Access Manager 7.1, as they need some of the new features developed over the last few months, in advance of the upcoming Federated Access Manager 8.0 release. The SI discovered OpenSSO, found that it met the needs of their prospective customer, evaluated it for the specific requirement and decided that it was the right solution.
My correspondent mentioned something quite disturbing to me… “[sales person] told me it was ‘forbidden’ to use OpenSSO in commercial environment”. Well, of course, nothing could be further from the truth! If you read my blog, The Aquarium, Jonathan Schwartz’s blog, or just about any other channel of information from Sun, you’ll know that our open source software (and in fact, most of our closed source software) is free for download, evaluation and deployment in any fashion that you see fit. We welcome folks deploying OpenSSO, Glassfish and even Solaris on their production systems, the point being that they often get in touch afterwards saying “We’ve evaluated and deployed X, now we’d like support, so how do we give you some money for that” (this actually really does happen!).
I mention this today because I was in a SEED meeting this morning where Jonathan was speaking (I was going to say that he was the star turn, but he’d be the first to disagree with me on that!). I told the above story to him, and his answer was to blog about it. Oh, and to email a couple of people in Sun on the need to educate our sales force. So here we are, dear reader. OpenSSO – available for deployment wherever, whenever it’s needed.
If you’re wondering where I’ve been lately, I was holed up preparing our interoperability demo for the Project Concordia workshop at RSA 2008 today, showing SAML 2.0/WS-Federation single sign-on from a service provider to an identity provider, the identity provider authenticating the user via a managed information card and sending claims from the card to the service provider as SAML 2.0 attributes. Note – if you clicking around there, not every combination of SAML 2.0/WS-Federation SP, IdP and Information Card STS completely works, but enough that the approach was proven. As promised, Here are the slides from my presentation today.
So… Tomorrow and Wednesday are OSIS I3 Interop, in Purple Room 220/222. Come along, say hi and check out how we’re doing on those interoperability matrices…
It seems like only two minutes since Build 3, back in February, but OpenSSO v1 Build 4 was released today. Binaries are available at the OpenSSO download page, here are the release notes.
So, what have we been working on?
- New OpenSSO configurator – let us know what you think about the new configuration UI (mailing lists are here).
- WS-Trust Security Token Service (STS) is available on Glassfish, Sun Application Server, Sun Web Server, Geronimo, Tomcat and WebSphere – we’ve done a lot of trickery with classloaders to get this working across a wide range of containers. We’re still working on support in Oracle Application Server, JBoss and WebLogic Server.
- Simplified STS client sample
- Configuration and/or user store replication across multiple OpenSSO instances where the embedded instance of OpenDS is in use.
- Security/SSL related fixes
- General bug fixes in all areas
Here’s a full list of the more than 200 fixes in build 4. Go update your CVS or grab the binaries now and see how it works for you – and please, read the release notes for container-specific installation instructions – in particular if you’re using Tomcat. There are some changes to Tomcat’s cookie handling in releases 5.5.26 and 6.0.16 that cause problems for this build of OpenSSO.