A little bit less than one year ago, I wrote a blog about how to setup the Kerberos SSO on Liferay using Apache httpd as a front-end, Tomcat as a back-end and with auth_mod_kerb and mod_jk to transfer the information between these two components. Unfortunately, after some months, it seems that something changed either on the Liferay side or in the Apache side because the exact same configuration wasn’t working anymore. I solved this issue (or at least applied a workaround) two or three months ago because I needed a working environment for some tests but until now, I didn’t have the time to share my findings.

That’s why in this blog I will try to explain what was needed in my case to avoid an issue with the configuration I shared in my previous blog. I decided not to update my previous blog but rather to create a new one because my previous blog may still be working as expected with certain versions of Liferay!

 

I. The issue

In my case, after some months where everything was fine, the SSO suddenly wasn’t working anymore. The access to the Liferay welcome page took a looooooong time or even never ended (or rejected by Apache httpd depending on the configuration).

With the proper logging information or debugging steps, if you face the same issue, you should be able to see that in fact Liferay doesn’t understand anymore the information that Apache httpd provides and the result of that is an almost infinite loop in the login process.

From a debugging point of view, my previous blog post prevented an administrator to access Liferay without a valid Kerberos ticket. That’s why in this solution I also incorporated some lines of code to prevent such cases and to allow any users to still access Liferay even without a valid ticket. This can be easily removed for strict access requirements. Please be aware that this guess access is, by default, only valid for requests directly addresses to Tomcat (not the ones coming from Apache httpd)!

 

II. A possible solution

So the first thing that changed is the “KerberosAutoLogin” itself. I changed a few lines to get something cleaner and I added some others to handle the “guest” access in case a valid Kerberos ticket wasn’t found (line 64 to 77). The result is the following:

KerberosAutoLogin1.pngKerberosAutoLogin2.png

Please find at the end of this blog the squeleton of the HOOK I built for my dev environment. This is basically the same that in my previous blog except that I changed the code for you.

In this Java Class, I used the “LogFactoryUtil” for the logging to get something more standard but that requires you to configure the log level that you want. If you just want these logs for the debug phase, then you may want to replace all “logger.debug” or “logger.warn” with a simple “System.out.println”. That should redirect all elements that you want to log to the default catalina.out log file.

The second thing to do it to modify the Java Class named “AutoLoginFilter”. This Class is a kind of dispatcher for the login requests that are coming to Liferay. From what I saw, there is a little issue with this class that prevent our KerberosAutoLogin code to be executed properly or at all… Indeed in our case, the “REMOTE_USER” is set by Apache and when this method is executed, our KerberosAutoLogin which is one of the “_autoLogins” (see the code below) isn’t called because the “remoteUser” variable isn’t null!

To enable our KerberosAutoLogin to be executed even if the remoteUser isn’t null, you can modify the default code. You can find the Java Class at the following URL: the code is on grepcode. Please be aware that the code of this Java Class is version dependent, which means that the code for Liferay 6.0 may not exactly be the same that for Liferay 6.1… So be careful ;).

I highlighted the lines I added for this specific case. If you take a look at the code, I also added a variable “REALM” to compare the Kerberos REALM that came from Apache httpd to the one that should be used (your Active Directory or KDC). This check can be used to prevent a user from a different REALM to login to your Liferay. If you don’t want or don’t need this additional security, you can just remove this variable and also remove the “if” test that use it (remove line 25, 65 and 88).

AutoLoginFilter1.pngAutoLoginFilter2.png

Please find at the end of this blog the squeleton of the EXT I built for my dev environment. Please also be aware that the KerberosAutoLogin is defined in a hook (custom-hook if you followed my previous blog) but you can’t do the same for the AutoLoginFilter. Indeed, you will have to create your own EXT using the SDK, add this class in it and then deploy it to be able to see the updated version of the class loaded.

I only printed here the method “processFilter” because it’s the only thing that needs to be modified, at least in my Liferay version 6.1.1! If you compare this method to the one on grepcode you will see that I compacted the code quite a lot to take less space but I didn’t change the code that isn’t highlighted.

Once these two Java Classes are modified, you should be able to login properly to Liferay using Kerberos tickets. If not, then enable the logging and that should help you to find out where your issue is. Of course you can still post a comment below and I will do my best to help you. I also already saw some issues that were related to the new version of Apache… You may want to try the same thing with Apache 2.2 instead of 2.4! From my side, this was the first thing I tried to get the SSO working again and I still use Apache httpd 2.2 (instead of 2.4 as described in my previous blog). Another important thing to check is that your browser is properly setup for the SSO!

Squeleton of the EXT
Squeleton of the HOOK