@Mark: We have implemented a KerberosLoginModule for JBoss, that can be used in a fat client szenario. How is works: 1. The client part of the LoginModule creates with the GSS-API a Kerberos Service Token for the Service Principal of the server. To get the Service Token, the GSS-API needs the Ticket-Granting-Ticket (TGT) of the user. The Standard Krb5LoginModule can be configured to get the TGT from cache - that is what you typically want. 2. The client part of the LoginModule encodes the Service Ticket in base64 and put the ticket into the credentials of the SecurityAssociation of JBoss - like a password. 3. The server part of the LoginModule decodes the Service Ticket. 4. The server part of the LoginModule validates the Service Ticket with the GSS-API. To validate the ticket, the GSS-API needs the private Service Key of the server. That is typically deployed in a keytab. The Standard Krb5LoginModule can be configured to obtain the Service Key from the keytab. All that GSS-API and Kerberos stuff is well documented: http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/index.html @JBoss: What is about the SPNEGO/Kerberos support. I have not seen any production ready LoginModule yet. I am VERY interested in such an LoginModule for Tomcat and JBoss AppSrv. Why do you investigate so much time in getting role / group informations from the active directory? In an enterprise context the active directory is an out-sourced infrastructure service. That is not the right place to define roles (other than infrastructure roles) for thousands of users and houndreds of applications! I think it would be enough to autenticate a user with Kerberos and get the application roles from another (application specific) LoginModule - without authentication. So why should we make things more complicated? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130343#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...