Sunday, December 24, 2006


Closing Thoughts on Federated Identity and Authorization...

This will be my last post this year on the topic of Federated Identity and Authorization and I would like to thank Pat Patterson, Shekhar Jha and Conor Cahill for jumping in and providing their perspectives. Sadly, I didn't get a response from Kim Cameron, Kapil Sachdeva, Andre Durand, Johannes Ernst, Radovan Janecek or Dick Hardt but I am still hopeful. Anyway, here are some additional considerations that folks thinking on identity need to noodle?

Pat Patterson pointed me towards the Liberty People Service which allows you to understand the relationship between two identities but stops short of one of the business use cases in that only knowing relationship is sufficient in a consumer social networking scenario but won't work for businesses as relationships also need authorization. For example, just because I am the father of my daughter doesn't automatically give me the right to see her medical records when she decides to have an abortion next week (NOTE: I don't have a daughter).

Hopefully, Johannes and Kim can tell me if Cardspace as a user interface and open ID as a protocol will be extended in the future to support authorization or should some other standards body start a similar initiative. Of course being able to specify via Cardspace the relationship between me and my daughter and whether I can see her medical records would be cool. I would assume that OpenID would support carrying XACML?

To date, the discussion and more importantly the reference implementations have all been done in either Java or .NET. Should Ruby on Rails and Smalltalk become second-class citizens in this regard? Anyone have thoughts on how federated identity should work against RACF?

So, the community has been successful in demonstrating how federated identity works and has even shown us enterprisey folks on how to write better code but ignores one truth. Enterprises nowadays have a preference to buy vs build. So this begs the question of whom in the identity space is working with small software vendors in the ECM space (e.g. Documentum, Alfresco, Filenet), in the BPM space (e.g. Intalio, Lombardi, Pega), in the CRM space (e.g. Salesforce, SugarCRM, Siebel), in the portal space (e.g. Liferay, BEA, Oracle), in the ESB Space (e.g. CapeClear, Sonic, ServiceMix, JBoss) and so on? Or are we hoping that they will take their own initiative to get it themselves and simply build in?

How should federated identity be thought of in a provisioning context? Do specifications such as SPML and/or WS-Provisioning still matter? What other security specifications should federated identity connect to that hasn't already happened?

Anyone ever discuss how SAML needs to support identity propogation? For example, if I have Cardspace running via Firefox and it submits identity to Liferay Enterprise Portal who is running on JBoss talking to a SQL Server Database, would'nt it be great if SQL Server understood not only SAML but could understand all of the attributes of a user without breaking current J2EE pooling mechanisms?

I would love to know if anyone has a real implementation where they have converged federated identity with technology traditionally used in the physical world. There is an emerging trend of converging logical and physical access whereby if I log onto my PC at work but haven't badged into the building then alerts are triggered. What if I were to take my Citigroup Employee ID and as a pre-registered guest could automatically enter the building of United Healthcare?

Is it possible for a NON-Sun employee to tell the world why anyone would want to join Liberty Alliance if your primary business model isn't technology? It seems as if those whose primary business model isn't technology is outnumbered by at least twenty to one. Even the industry analysts no longer talk about the Liberty Alliance which hints that it is no longer relevant...

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?