Negotiated Authentication w/kerberos as client

[aelyx]

I am using trying to use LoginContext to connect to a remote server (from our Jboss AS7.1 web application) via Negotiated authentication.

When running in a test environment, (not in jboss,) the code executes perfectly.  However, when deployed in JBoss we are getting a failed authentication exception.

I was tracing the network traffic with wireshark but it appears that the difference is in the call stack.  In our test environment, LoginContext makes use of the com.sun.security.auth.module.Krb5LoginModule class.  However, when running the same code In jboss the LoginContext makes use of the org.jboss.security.auth.spi.UsernamePasswordLoginModule class.

How can I get our application running on Jboss to use the Krb5LoginModule?  I've done a lot of reading, but it seems most everything is concerned with running jboss as the server instead of acting as the client.  Thanks.

Test Call Stack

     com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication()

     com.sun.security.auth.module.Krb5LoginModule.login()

     sun.reflect.NativeMethodAccessorImpl.invoke0()

     sun.reflect.NativeMethodAccessorImpl.invoke()

     sun.reflect.DelegatingMethodAccessorImpl.invoke()

     java.lang.reflect.Method.invoke()

     javax.security.auth.login.LoginContext.invoke()

JBoss Call Stack

     org.jboss.security.auth.spi.UsernamePasswordLoginModule:login()

     org.jboss.security.auth.spi.UsersRolesLoginModule:login()

     sun.reflect.NativeMethodAccessorImpl:invoke0()

     sun.reflect.NativeMethodAccessorImpl:invoke()

     sun.reflect.DelegatingMethodAccessorImpl:invoke()

     java.lang.reflect.Method:invoke()

     javax.security.auth.login.LoginContext:invoke()

[dlofthouse]

How are you configuring the login modules?  This sounds more a case of falling back to using the 'other' security domain rather than the module being substituted.

[jeffery.powell]

Thanks for your fast response.

You were right, the system was defaulting to 'others' security-domain.  We created a second domain with the Krb5LoginModule and that got the app running.  Anyway, now we have a new issue with the kdc token length; it's being truncated in our http requests, so all we get a 401s.  I'm trying to figure out if this is AD's fault or we have to set specific eTypes via supported_enctypes in the krb5.conf and kdc.conf.  But I assume that's a question for another time on a different forum and thread.

Sorry for the extremely delayed response.  I'm a full time student studying for a PhD in BioMed Tech while working full time as a system dev for my present company.  Anyway, the project was put on hold for a bit and now it's being lazarethed.