The definition of Single sign-on is: SSO is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. But there is a problem with SSO because of this term is used sometimes to mean several different things. In my current project I needed to choose open source SSO solution, which best fits our needs. After some experiences with SSO implementations, I can write few words about this.
There exists only few open SSO solutions I could consider. Only three was functionally sufficient, and I focused my research on these systems.
OpenSSO
This should be our native choose, cause OpenSSO was informal Java standard, cause it was developed by Sun. Oracle afrer taking over Sun, actually abandoned project, but next it was revitalized by ForgeRock as
OpenAM. The problem with OpenSSO is only one. I don't like it :)
Regarding functionality: OpenAM offers open source authentication, authorization, entitlement and federation software. OpenAM gives you core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenAM provides the foundation for integrating diverse web applications that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers.
ESOE
Enterprices Single sign-on is Apache 2 licensed solution developed by University of Quensland. ESOE has been built utilizing open standards from OASIS such as SAML 2.0 and XACML 2.0 and provides core java security services like: integrated identity management, single sign on, authorization, federation and accountability for resource access across multiple platforms and technology stacks.
The solution looks very interesting, but some inactive in last two years.
CAS
CAS is a part of Jasig project. The solution provides own, specific single sign-on protocol. Till now CAS don't support SAML and from my perspective this is big defect of this system. But it has also one big advantage, built in integration with Java, ,NET, PHP, and Apache clients. Next advantage for me is documented integration path with Apache Shiro.
Additional option to consider
Preparing this review I consider Apache Shiro as SSO solution. In my opinion this security framework is't ready to fit SSO needs, but
other Shito functionalities are
worth the prevalence. Cause of this I wrote few words about this framework.
Apache Shiro
The first was Apache Shiro ( former
JSecurity) project. Shiro is a comprehensive java web security framework, which focuses on: authentication across one or more pluggable data sources, authorization based on roles or fine-grained permissions, also using pluggable data sources, and built-in POJO-based Enterprise Session Management. And this last element can be interesting for me.
Shiro session's are POJO based, they are easily stored in any data source, and they can be "shared"across applications if needed. This can be used to provide a simple sign-on experience since the shared session can retain authentication state.
Shiro provides one very nice function: Heterogeneous client session access. You are no longer forced to use only the HttpSession or Stateful Session Beans, which often unnecessarily tied applications to specific environments. Flash applets, C# applications, Java Web Start, and Web Applications, etc. can share session state regardless of deployment environment.
After this short review I need some testing and coding to check cited solution in real work.