Friday Mar 13, 2009

OpenSSO Tab Sweep - Mar 13 2009

Lots of news over the last couple of weeks from the world of OpenSSO. Events in New York, new Fedlet innovations and more; read on...

That wraps things up for this week. Don't forget, if you're planning to attend the European Identity Conference 2009 in May, the second OpenSSO Community Day will be there on the Tuesday, May 5 2009. Register at Meetup and you can pick up a discount code for 20% off the cost of your EIC registration. Bargain!

Friday Feb 27, 2009

XACML and SAML - a Match Made in... 2005

Over at NetworkWorld's Security: Identity Management Alert, Dave Kearns weighs in on the ongoing federated provisioning debate with Federated provisioning could exist. While Dave is right to highlight the promise of the Liberty Alliance's Identity Governance Framework (IGF), he is way off the mark regarding XACML and SAML. Dave writes:

Some have suggested that XACML (eXtensible Access Control Markup Language) might be the answer. But it [...] suffers from the same problem as SPML (no interaction with SAML) [...]

This is patently not true! Four years ago, OASIS defined the interaction between XACML and SAML in SAML 2.0 profile of XACML v2.0 [PDF], part of the XACML 2.0 specification set. Since then, SAML/XACML has been implemented in a range of products, including Sun OpenSSO Enterprise, with interoperability between seven vendors' products demonstrated at the OASIS XACML Interop Demo (held at the RSA Conference, April 2008).

XACML and SAML, best buddies since February 2005

Wednesday Apr 16, 2008

RSA Conference Interoperability Roundup - OSIS/XACML

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




« February 2016