Superpatterns

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

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