Single Sign On for open source has been a product of interest at Sun Microsystems. Eric Leach, Sun Identity Management product line manager, shared his thoughts on OpenSSO with a writer for the Entiva Group Analyst Report.
One of the first questions put to Leach asked how OpenSSO fits into service-based architectures. Leach characterized the relationship as evolutionary in that it began with the establishment of a simple web SSO between a browser and a number of applications. Adding federation allowed the sharing of security assertions across domains, Leach explained, making it possible to supply an enriched identity context and to add a security layer to the web services.
It used to be the case, Leach continued, that web applications were treated in an ad-hoc fashion with web applications requiring a host of different log-on approaches. This was addressed with certain web SSO products that provided single, centralized authentication, a centralized means of establishing and managing sessions across large groups of web applications, as well as centralized policy decisions that can control access to web applications and a distributed capability to enforce those policies on web applications, Leach explained.
When the inadequacies of using a centralized LDAP directory to store credentials became apparent, Leach went on, the need for a better means of managing new user accounts, changing user roles, group memberships, plus anything else affecting access control privileges.
The need was met by developing products capable of interacting with web- and JavaTM technology based applications largely through domain cookies, using what amounted to giving the browser an SSO token based on user information, Leach reported. In a single domain, this arrangement is satisfactory, according to Leach, but it leaves much to be desired when third parties become involved because of outsourced functions, or when telcos offer content services and government agencies need to interact. The federation standards devised by the Liberty Alliance and OASIS SAML technical committees served to answer these shortcomings, Leach asserted.
Leach summarized his view of the OpenSSO to service-based architectures, saying it was a "natural progression for OpenSSO to protect web applications, extend that protection across domains through federation standards and protocols, and start pushing that browser-based identity context into web services."
Still, Leach cautioned, for all its versatility it is not the province of OpenSSO to address enterprise-wide authentication issues but rather to inform developers about using code that can security-enable their applications and services. OpenSSO's mature code base offers exactly the stable platform on which to build these security features.
As far as the antecedents of OpenSSO are concerned, Leach said, the code is based on JavaTM System Access Manager 7 2005Q4 Version 7, in effect the result of moving the CVS source tree into the public domain and making it available to users on java.net.
Another aspect of OpenSSO worthy of comment in Leach's view is domain independence. "The OpenSSO system should not place any restriction on the use of any specific underlying network technology, computer hardware, operating systems, programming languages or other hardware or software entities other than the expected operation involving the use of HTTP protocol in regular and secure forms," he asserted.
The long-term objective of the people behind OpenSSO, Leach announced, is to build a thriving community around the technology, which will involve appealing to the developer community using such solutions as NetBeansTM and the JavaTM Platform, Enterprise Edition (JavaTM EE). Toward that end, the aim is to provide as helpful a set of use case documents as can be produced to build the community's understanding of the solution's basic concepts and architecture.
Finally, Leach noted that users need to familiarize themselves with the terms of the open source license governing the particular open source code they may be using.
[...read more...]