We now also provide a filter and valve for integration with SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) to negotiate with the client and use either Kerberos or NTLM as fallback. This way a non-interactive login is possible, which takes the user logged in to the operating system running the browser.
Such a secure solution is especially interesting for intranets running with Windows servers. This document describes how to configure such an environment.
Tomcat 6.0.19 or later (otherwise negotiation with the client will not work, when also using custom error pages for 401 errors in web.xml). If your Jahia release is shipped with an older Tomcat, then you will have to manually upgrade to the required version.
If using Windows Server 2008, then at least Service Pack 2 needs to be installed (otherwise only simple Kerberos user logons (e.g. via CAS) work, but checks against a Service Principle Name (SPN) will not work, as this one contains slashes (see Microsoft KB article: 951191)).
For this guide we assume that you are using Windows Active Directory server. If you want to use Kerberos, then all clients and servers need to be joined in the same AD domain. If this requirement is not met, then SPNEGO will fall back to NTLM. It should also be possible to use other directory servers supporting Kerberos and you can take this guide to perhaps get some useful information also relevant for alternative environments.
In the guide all terms in angle brackets <> should be replaced by terms fitting your environment or your choice. Notice also that realm names are case-sensitive and recommended to be used in UPPER CASE. Also with Kerberos you will not be able to use IP addresses or localhost but rather you will have to use the server name (DNS must be properly set up).
Now in Windows server 2008 there is an extra step, which is not required in Windows server 2003:
setspn -a http/<your.jahia.server.name> <your-spn-account> The Keytab file enables a trust link between the Jahia server and the Key Distribution Center (KDC). This file contains a cryptographic key. The ktpass tool, which comes from the Windows Resource Kit, is used to generate this file (in Windows Server 2008 the tool is already part of the product).
In a console, enter the command:
ktpass.exe /out <your-spn-account>.keytab /princ HTTP/<your.jahia.server.name>@<YOUR.AD.REALM> /pass * /mapuser <your-spn-account> /ptype krb5_nt_principal /crypto rc4-hmac-nt
This command will generate the <your-spn-account>.keytab file, which has to be copied to a secret place on the Jahia server, which only the Jahia server application could read.
set JAVA_OPTS=%JAVA_OPTS% -Djava.security.krb5.conf=<path>\krb5.conf
Here is an example:
<YOUR.REALM> is the same as the domain in caps.
[libdefaults]
ticket_lifetime = 24000
default_realm = <YOUR.REALM>
default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
[realms]
<YOUR.REALM> = {
kdc = <hostname.of.your.kdc>.<your.domain>
}
[domain_realm]
.<your.domain> = <YOUR.REALM>
<your.domain> = <YOUR.REALM>
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
set JAVA_OPTS=%JAVA_OPTS% -Djava.security.auth.login.config=<path>\jaas-login.conf
set JAVA_OPTS=%JAVA_OPTS% -Djavax.security.auth.useSubjectCredsOnly=false
Here is an example of the content:
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule
required
storeKey=true
keyTab="<path>/<your-spn-account>.keytab"
doNotPrompt=true
useKeyTab=true
principal="HTTP/<your.jahia.server.name>@<YOUR.REALM>"
isInitiator=false
debug=false;
};
In order to have those tests work, you have to copy your krb5.conf file in your windows system directory and rename it krb5.ini (most often c:\windows\krb5.ini)
Verify that your are able to read the keytab file:
%JAVA_HOME%/bin/klist -k FILE:<path>/<your-spn-account>.keytab
Then verify that your are able to read the keytab file :
%JAVA_HOME%/bin/kinit -k -t FILE:<path>/<your-spn-account>.keytab HTTP/<your.jahia.server.name>@<YOUR.REALM>%JAVA_HOME%/bin/klist
<filter>
<filter-name>SpnegoHttpFilter</filter-name>
<filter-class>org.jahia.bin.filters.spnego.SpnegoHttpFilter</filter-class>
</filter>
and
<filter-mapping>
<filter-name>SpnegoHttpFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Then you also need to edit the WEB-INF\etc\spring\applicationcontext-pipelines.xml file and add the SpnegoAuthValveImpl as the first entry in the authPipeline, like this:
<bean id="authPipeline" class="org.jahia.pipelines.impl.GenericPipeline">
<property name="name" value="authPipeline" />
<property name="valves">
<list>
<bean class="org.jahia.params.valves.SpnegoAuthValveImpl" />
<bean class="org.jahia.params.valves.TokenAuthValveImpl" />
...
You also need to configure WEB-INF\etc\spring\applicationcontext-services.xml to connect the users and group LDAP to your active directory, so that the users there will be known to Jahia.
After making these changes, you need to restart the server to make them effective.
Kerberos with Java Troubleshooting
Advanced Security Programming in Java SE ... Single Sign-On
Developing with Kerberos in Java
Kerberos Authentication problems – Service Principal Name (SPN) issues
This Article shows how to resolve common errors
This error means that the kerberos authentification is not done on the client browser.
Resolution :
Check your kerberos configuration with klist and kinit tools.
Look at support.microsoft.com/default.aspx to activate kerberos event loging
This error occurs when there is more than 5 minutes between kerberos domain controler and jahia server times.
Check time and time zone.