There are three authentication protocols that can be used to authenticate between Java and Active Directory on Linux or on any other platform (and they are not only specific to HTTP services):
Kerberos - Kerberos provides Single Sign-On (SSO) and delegation, but web servers also need SPNEGO support to accept SSO through IE.
NTLM - NTLM supports SSO through IE (and other browsers, if configured correctly).
LDAP - LDAP binding can be used to easily verify the account name and password.
There is also something called “ADFS” that provides SSO for sites using SAML that invoke Windows SSP, so in practice it is basically a roundabout way of using one of the other protocols listed above.
Each protocol has its own advantages, but as a rule, for maximum compatibility, you usually try to "do what Windows does." So what does Windows do?
First, authentication between two Windows machines favors Kerberos because servers do not need to communicate with DCs and clients can cache Kerberos tickets, which reduces the load on DCs (and because Kerberos supports delegation).
But if the authenticating parties do not have domain accounts or if the client cannot contact the DC, NTLM is required. Thus, Kerberos and NTLM are not mutually exclusive, and NTLM does not expire Kerberos. In fact, in a way, NTLM is better than Kerberos. Note that when mentioning Kerberos and NTLM in one go, I should also mention SPENGO and Integrated Windows Authentication (IWA). IWA is a simple term that basically means Kerberos or NTLM or SPNEGO for Kerberos or NTLM negotiation.
Using LDAP binding as a way to verify credentials is inefficient and requires SSL. But until recently, the implementation of Kerberos and NTLM was difficult, so the use of LDAP as a shift-shift authentication service has been preserved. But at this point it should generally be avoided. LDAP is an information directory, not an authentication service. Use it as intended.
So, how do you implement Kerberos or NTLM in Java and in the context of web applications in particular?
There are many large companies, such as Quest Software and Centrify, which have solutions specifically mentioning Java. I can’t comment on them, because they are “identity management solutions” for the whole company, therefore, looking at the marketing on my website, it is difficult to say exactly which protocols are used and how. You will need to contact them for more information.
Implementing Kerberos in Java is not terribly difficult because the standard Java libraries support Kerberos through the org.ietf.gssapi classes. However, until recently, there was a serious obstacle - IE does not send raw Kerberos tokens, it sends SPNEGO tokens. But with Java 6, SPNEGO was implemented. Theoretically, you should write GSSAPI code that IE clients can authenticate. But I have not tried. The Sun Kerberos implementation has been a comedy of mistakes for many years, so based on Sun's record in this area, I would not have made any promises about their implementation of SPENGO until you have this bird.
For NTLM, there is a free OSS project called JCIFS that installs the NTLM HTTP authentication servlet filter. However, it uses a man-in-the-middle method to verify credentials with an SMB server that does not work with NTLMv2 (which is gradually becoming a necessary domain security policy). For this reason and others, part of the JCIFS HTTP filter is planned to be removed. Note that there are a number of side effects that use JCIFS to implement the same technique. Therefore, if you see other projects that claim to support SSO NTLM, check the small print.
The only correct way to verify NTLM credentials with Active Directory is to call NetRLogonSamLogon DCERPC through NETLOGON with the Secure Channel. Is there such a thing in Java? Yes. There he is:
http://www.ioplex.com/jespa.html
Jespa is a 100% Java NTLM implementation that supports NTLMv2, NTLMv1, full integrity and privacy settings, and the aforementioned NETLOGON authentication. And it includes an HTTP SSO Filter, a JAAS LoginModule, an HTTP client, a SASL client and server (with JNDI binding), a common "security provider" for creating custom NTLM services, etc.
Mike