Sun’s Open SSO - too little, too late?
Dana Blankenhorn from ZDNet wrote the following on Sun’s recent Open SSO announcement:
Sun has released its Single Sign On technology under the CDDL giving it the name Open Source Single Sign On (Open SSO), with a roadmap that would make it a federated identity solution across multiple sites.
The code is based on its Java System Access Manager.
The question I have is, could this be too little, too late for federated identity?
Dana continues with
The idea of having a single sign-on for multiple sites has been kicking around for over a decade. It was one of the first concepts I heard, once people started talking about requiring registration.
But it hasn’t happened.
Not that it hasn’t been tried. Remember Microsoft Passport? It’s now called Windows Live ID. Lots of Microsoft sites use it. No one else does. Or what about the Liberty Alliance? They are still around. Sun was one of the original sponsors. Have you used that lately? I haven’t. How about Ping Identity?
OUCH! Dana then goes on to critique the license …
The fact that this code is under the CDDL doesn’t give me a warm feeling, either. I think a key to getting some form of federated identity going would be to put it under the Apache project, which runs so many commercial Web servers, and (not being a lawyer) I don’t know if the CDDL is really compatible with the Apache license.
I agree whole heartily with this point. Developers are not going to want to figure out licensing, and why I often have selected the Apache license for code to be released under.
digg this
del.icio.us this
I addressed much of this in my comment on Dana's post .
On the licensing issue... CDDL is essentially the Mozilla Public License with a few bugfixes . The big delta between Apache and CDDL is that, under Apache, you can keep your changes to the core Apache code proprietary. CDDL says that you can extend the code with your own files, but any modifications to the licensed files must be contributed back to the community. IMHO, this is what makes CDDL a good compromise between re-usability in a commercial setting and maintenance of a commons.
I understand your points Pat. Does not change the fact that developers are most familiar with GPL, Apache and BSD licenses. Apache software has not had a problem with commercial use and maintenance of a commons, so not sure why you need a restricutive license.
In the short term, OpenSSO is focusing on solving the problem of a service provider with multiple applications, requiring single signon and authorization policies governing access to various resources.
Federation is still down the road, and in reality the question remains what technology, protocol stack, business practices will emerge to provide the holy gail of a single identity (with multiple personas).
Liberty won't be the only form of federation that OpenSSO will support down the road. Other federation and user-centric identity protocols (including WS-F, OpenID and DIX) will be supported too.
I suppose time will tell whether the CDDL licensing terms are acceptable to developers. This developer has accepted the terms.
I think Dana's point is that this would have been much more interesting a year or two ago, and it supported WS-F, OpenID and DIX now, that would make it interesting as well. It does neither.
http://www.brandonwhichard.com/2006/09/06/lin...
Think anyone may know the answer to this blog entry: http://duckdown.blogspot.com/2006/09/what-thought-leaders-arent-telling-you.html
Probably not. :-)
Federated identity is an interesting space in the healthcare sector. If you consider the disparate systems, complexity of directory information, what is acceptable across all participating organizations. Not to forget what information what information each organization has been collected. The ability to provide access to applications in a many to many environment is very complex from an identity and access management perspective.
Realistically the problem of identity management is a business process and policy issue that has to be agreed on by each organization. As we all know throwing huge amounts of technology at a business problem will not fix the problem. The goal each organization would like to achieve is the confidence that each organization have the appropriate process and procedures in place to provide identity assurance.
The technology is only one component which important piece of the puzzle, but not the total solution. Business architecture also needs to be considered in managing the end to end solution.
The Sun, IBM, Microsoft, Novell or any techology solution provider will not solve the end to end solution.
Agree technology is only one component, but I would point to how the world moved from leased lines and frame relay for moving data to the IP network of today that enables packets to move from any machine to any machine. Policy on accepting packets moved up the stack rather then being controlled at the physical or transport layer. I see the same happening with Identity data and standardization on what the identity data is. This will allow the business to focus on the business rules around the identity data as opposed to moving it around.