I read that there are some kinds of authentications available, like Kerberos, Spenego, NTLM and so on.

There are 3 networking protocols supported by Active Directory that may be used to implement authentication:

1. Kerberos - Kerberos provides Single Sign-On (SSO), delegation and scales well as servers do not need to communicate with AD and clients can cache their "tickets". To implement Kerberos SSO over HTTP, SPNEGO is also required (more on that later).

2. NTLM - When used in conjunction with IE and other browsers, NTLM can be used to implement SSO.

3. LDAP - An LDAP "simple bind" may be used to validate credentials. LDAP cannot be used to implement SSO with browsers.

Each protocol has it's pros and cons. MS services favor Kerberos because it is more efficient and supports delegation (delegation is when you automatically forward your credentials to the server so that the server can then use that credential to authenticate with other Kerberos protected services like AD, databases, other HTTP servers, etc). However, if the client and server do not both have accounts in the domain with current passwords, or if the client cannot communicate with a domain controller, Kerberos authentication cannot occur. In this case, NTLM must be used. Notice that NTLM is not obsoleted by Kerberos and provided NTLMv2 is used, it is just as secure.

When talking about Kerberos and NTLM in Windows, SPNEGO and IWA should also be mentioned. SPNEGO is used to negotiate Kerberos or NTLM. IWA is a simple term coined by MS to mean Kerberos, NTLM or SPNEGO to negotiate Kerberos or NTLM. In the context of web services, SPNEGO would be largely unimportant if it were not for the fact that IE only sends SPNEGO tokens so even though HTTP servers may only want or need to support Kerberos, they still must consume the SPNEGO envelope and extract the Kerberos part of the token.

Using LDAP has a make-shift authentication service has persisted because support for SPNEGO and NTLM (which are the two protocols IE uses to do SSO) has been weak to non-existant.

If you have a working solution, please... tell me all steps necessary to get it working here!

My environment is Java 5 and JBoss 4.0.5 running on MS Windows 2000. The AD is on a Windows 2003 Server machine.

There are several solutions available for doing HTTP SSO in Java.

1. Implement a Kerberos HTTP Servlet Filter using the org.ietf.jgss classes with a new enough version of Java that supports SPNEGO. I have not tried this myself so if someone has actually done this, please feel free to chime in with your experience. Another possibility is to implement the SPNEGO part as necessary to extract the enclosed Keberos token and feed it to GSSAPI as a raw Kerberos token - this I have done and it works. There are other implementations of SPNEGO available, some free - some not, but none are particularly nice to use for one reason or another. But if Java's builtin SPNEGO implementation works then I would say the other implementations are obsolete anyway.

2. There is a project called JCIFS which implements the CIFS protocol but, as a side project, they also have an NTLMv1 HTTP Filter that uses a CIFS connection to validate the NTLM hashes. This has been a fairly popular solution for many many years. However, it has problems. The most important issue is that it uses a man-in-the-middle technique that doesn't support NTLMv2 (NTLMv2 is slowly becoming required by domain security policy). For this reason and others, the NTLM HTTP Filter part of JCIFS will be removed (I can say that authoritatively because I wrote and still maintain JCIFS). The only proper way to authenticate NTLM clients is by using the NetrLogonSamLogon(Ex) DCERPC call over the NETLOGON service with Secure Channel encryption.

3. There is a product called "Jespa" (http://www.ioplex.com/jespa.html) that has an implementation of NTLM that is fully compatible with the Windows NTLM security support provider. Meaning it implements the aforementioned credential validation using the NETLOGON service over Secure Channel which enables authenticating Windows clients using NTLM. In fact, Jespa includes an HTTP Servlet Filter read-to-go (and JAAS Login Module, SASL server and client, JNDI binding for NTLM, and much more).

Another solution, IMO the easiest one, is to use Tomcat connector and let IIS perform NTLM/kerberos authentication. I have tried this solution successfully on a W2K3 box. One difficulty I faced is in java code it's not easy to retrieve authenticated domain and user name b/c they are encoded in authorization header. Although there is code snippet to decode NTLM header, I haven't found any to decode negotiate header. The trick is to add a ISAPI_REWRITE filter as documented in http://www.eggheadcafe.com/conversation.aspx?messageid=30994013&threadid=30994002 to save domain\username in a custom header.
Compare to Jespa, this solution elminated the need to create a fake service account and change DNS, which could be a demanding network reqirement.

If you can use Java 6 and want an existing AD SSO solution that just works, the servlet filter based on Java's builtin SPNEGO implementation from MapleSail ( [http://www.maplesail.com|http://www.maplesail.com] ) might be able to help you out.

I am running a resembling app. I do IE => Tomcat with WIA. The complete SPNEGO with Kerberos issue takes c. 100 lines of Java 6 code. More over I do have a Active Directory Realm in Tomcat in a few hundred lines.

Note that Java 5 does not know how to unpack SPNEGO token. I was used to base on a JCIFS solution but after some time it turned out to be crap just as jCIFS docs and non-existing build files.