Due to the security flaw presented in my previous post, it is hardly a workable solution for anyone interested. Here is the consideration to address the issue.
The security flaw was introduced by a shortcut implementation with the authentication plug-in where every user reaching it would be authenticated. It was a very big assumption. As Deniel Nguyen pointed out in his comment, actually a specific prefix (DM_PLUGIN=<plug-in identifier>/) in the user password will direct the authentication towards to the authentication plug-in (although users have no way to provide the compromised password in a SSO enabled Webtop setup, for Webtop instances that do not have SSO enabled, users can easily provide the fake password to bypass the authentication). In this case, the prefix would act as an universal key for someone who knows the trick and the id of the authentication plug-in.
In order to fill the security hole, the authentication plug-in has to be doing something. Intuitively, it should verify the SPNEGO token as what the SPNEGO filter does for Webtop. In other words, the authentication plug-in has to be Kerberized.
Overall, there are several aspects that should be taken into account.
Utilize the existing authentication framework
Even we could devise a totally different authentication scheme (it’s better leaving that to EMC Documentum team), there are many benefits with the current authentication plug-in framework. From the docbase log sample in my previous post, the current Documentum authentication framework has done more than just verifying users’ credentials. Although it is not done by the authentication plug-in itself, the authentication framework checks if the user has valid account in the repository and the user status in the repository. By relying on the authentication framework, we could take advantage of those features that are already provided by the Content Server.
Kerberization of the authentication plug-in
The plug-in has to be kerberized to achieve the authentication where SPNEGO token is passed. Many literatures outline steps about how to utilize Kerberos protocol to authentication users with intended services. Overall, the plug-in needs to run under a service principal that is known to KDC. When a client who is requesting authentication passes a SPNEGO token, the plug-in will verify the token to find out the client is indeed who the client claimed to be.
Kerberos double hops
Once the authentication plug-in is Kerberized, the authentication process becomes a double-hop journey. First the client is authenticated by Webtop server via SPNEGO Filter, which also initiates the SPNEGO process between client browser and Webtop server. Then the second authentication process happens with the plug-in itself to make sure the request from the Webtop server is legitimate. Initially we thought the SPNEGO token obtained from user browser should be authenticated against the authentication plug-in as well. Actually due to the replay checking, it would be rejected by the right-now-kerberized authentication plug-in. In order to address the issue, the Webtop server needs to impersonate the users and obtain a new ticket from KDC for the authentication plug-in to consume. The topic from SPNEGO authentication and credential delegation with Java gives a great example about how to implement the impersonation within JGSS.
Mixed environment setup
Things get further complicated due to the mixed the environments. Users could launch browser from any platform, such as Windows, Linux using IE or Firefox. The Webtop server could be installed on a Windows server box, or any other *NIX platform. The Content Server with which the plug-in is running can also be residing on many platforms, such as Windows Server, Linux, or IBM AIX box.
In order to simplify the discussion and setup, I have always assumed that KDC is provided by Windows AD (it is not necessarily a mandatory requirement for the SSO setup though). If the Webtop server or Content Server is running on platforms other than Windows, it would involve an issue to join the Webtop and/or Content Server to AD realm. Thanks to the availability of JGSS and SpnegoHttpFilter, the implementation on the Webtop server is effectively taken care of. For Content Server, we need to select which Kerberos implementation to utilize in order to build the authentication plug-in.
Implementation of the authentication plug-in
As discussed before, the revised authentication plug-in needs to authenticate the user access request in the form of the new SPNEGO token created via the impersonation by Webtop server. There are several open source projects to achieve similar feat that can be used as implementation reference. Kerberos module for Apache is one of the popular ones that have been used by many people. The implementation I will present is largely derived from this module.
In the coming post, I will detail the steps to setup kerberized authentication plug-in and its implementation. If you have any thoughts on this, please share it via comments.
References
Understanding Kerberos double hop
Security Briefs: Credentials and Delegation
SPNEGO authentication and credential delegation with Java
Windows 2000 Kerberos Interoperability
Kerberos Module for Apache
Apache Kerberos/SPNEGO module
Apache Authentication
SPNEGO For nginx – a start, at least
Documentum DAA 