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.
You forgot Shibboleth (SAML) and OxAuth (OpenID Connect 1.0)
ReplyDeleteOh sorry, I must improve my homework :) Regarding Shibboleth, this software is not native Java based stuff, so I must check if there are integration limitations and whether they are acceptable. The similar problem in even greater extent concerns OAuth.
ReplyDeleteI assume that best solution should be as compatible as possible with commercial JEE SSO solutions
SSO is a misused term.
ReplyDeleteFirst of all you must be clear if your aim is Internet SSO or Intranet SSO. Most frameworks are not clear on which of those goals they target. Without saying so directly most frameworks you can find only target the Internet SSO use case or at least this is what is best documented. The Intranet SSO use case is all about corporate environments. I'm deeply frustrated how little emphasis there is on this use case with the available Java frameworks. The reason is of course that most volunteers on these frameworks are not corporate developers and they do not have easy access to corporate authentication mechanisms, notably Microsoft's Active Directory.
The second thing (when talking about SSO) is to be specific about what form of SSO you are aiming at: the promptless one the one that will prompt you for credentials every time you try to access a new resource. Of course there's no such thing as a promptless SSO - at one time in the past you need to have manually provided your credentials - but in the promptless world the idea is that once should be enough.
I've found that what users in the corporate world are expecting is really the promptless flavour. Corporate world to a large extent means Active Directory. (forget about trying to convince the organization to put in stuff like a CAS server just for the sake of making your application work). Corporate users are already authenticated against Active Directory so they expect that your application should take advantage of that. It just so happens that Active Directory is a fully standards compliant LDAP server and a fully standards compliant Kerberos KDC. That sounds good right? Java should play nicely with such standards right.
The LDAP-against-Active-Directory-option has two problems: it doesn't support the promptless flavour and because of that it requires your application to prompt for username/password. Some corporate organizations will not allow that because they don't know what your nice little applications do with that information. You could be storing it, re-using it for malicious purposes, etc. Organizations view (rightly so) their user's Active Directory credentials similar to the keys to front door of their HQ building.
As for the promptless version you should be looking for words like NTLM or SPNEGO.
NTLM is a proprietary protocol by Microsoft. Contrary to what people think it is fully documented by Microsoft. It comes in different flavours: NTLMv1 and NTLMv2 which are not compatible with each other. NTLM v1 is deprecated for security reasons and no longer supported in Microsoft products unless you explicitly enable it in Active Directory. Most sane corporate AD administrators will not allow that, so forget about NTLMv1. Unfortunately many Java frameworks mention NTLM without being specific as to which version they support. You should always refer to them as NTLMv1 and NTLMv2, never simply as NTLM. If the Java framework you are working with says it is supporting NTLM you can be almost certain that they mean NTLMv1 which is means it is close to useless. NTLMv2 is not deprecated in Windows products, it will still work and is secure (enough). However for quite some time now Microsoft has been phasing out NTLM (both variants) in favour of pure Kerberos based solutions.
I'll deal with SPNEGO in next posting.
(continued from above)
ReplyDeleteEnter SPNEGO.
SPNEGO is what Microsoft calls "Integrated Windows Authentication" and SPNEGO-over-HTTP is available in all browsers (IE, Chrome, Firefox, etc). It is not really an authentication mechanism in itself rather it relies on either NTLMv2 or Kerberos underneath. It gives you promptless SSO and there's never any collection or exchange of credentials going on in your application. Bingo!. This solution will be approved by the corporation that is supposed to buy and install your application. It also doesn't require you to use any Microsoft platform what so ever, neither as the server platform of your application, nor as the client platform, however if the corporation is Active Directory based it is likely that all their workstations use Windows. (you can't imagine how many websites out there will tell you that SSO integration against Active Directory requires that your server application runs on Windows. It is a lie!)
So SPNEGO is the way to go. Look for that in your Java framework.
There's one caveat. You would want the underlying authentication mechanism to be Kerberos, rather than NTLMv2. Suppose your client is a pure-Java application (e.g a Java swing application or the like). JDK actually has a fully functioning pure-Java implementation of a Kerberos client. However Microsoft has changed the way a session can get access to the session key. For security reasons it can now only be done via their own SSPI API. For a pure-Java application to gain access to that you need to set a registry key on all workstations (allowtgtsessionkey=true) and there's simply no way that a corporate security manager will allow that ... just for the sake of your little application. But hey, wait a minute, the browser can do it (without setting this registry key), so why can't a pure Java client app do the same? The reason is that unlike what the browsers do the Sun/Oracle JDK on Windows does not take advantage of Windows' SSPI API because it instead uses a pure-Java Kerberos client implementation. There's an RFE for that (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6722928) but no traction on it from Sun/Oracle).
The conclusion is that SPNEGO is the way to go for Intranet SSO (aka corporate SSO) ... as long as your application only needs to be accessed from a browser.
My ramblings where supposed to highlight the fact that more or less none of the Java frameworks you mention actually cater for the corporate SSO case.
ReplyDeleteSSO provides benefits services through an single login which would help you to access an environment which would help to access multiple applications through single login.
ReplyDeleteIdentity Provider Saml
Nice Information. Thanks for sharing.
ReplyDeleteNetworking Institues in Chennai
Wow!! Great article you ave beautifully explained the concept of open source single sign on solutions in a simple and easy manner.
ReplyDelete