GSSAPI authentication for remote EJB

[npabst]

Hello everyone,

I am having difficulties configuring GSSAPI to authenticate access to EJB for remote client.

I have configure my remote client to use GSSAPI for authentication, add GSSAPI as an allowed sasl mechanism in standalone.xml

and generate a Keytab for the principal remote/fqdn.

The client part seems to work: I am prompt for login and password to obtain a TGT then I get a TGS for remote/fqdn but then i get the following error :

Client Side

javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 01414655 to /192.168.201.187:4447]

    at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)

    at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:121)

    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)

    at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)

    at javax.naming.InitialContext.init(Unknown Source)

    at javax.naming.InitialContext.<init>(Unknown Source)

    at javax.naming.directory.InitialDirContext.<init>(Unknown Source)

    at org.jboss.as.quickstarts.ejb.remote.client.JndiAction.performJndiOperation(JndiAction.java:37)

    at org.jboss.as.quickstarts.ejb.remote.client.JndiAction.run(JndiAction.java:20)

    at java.security.AccessController.doPrivileged(Native Method)

    at javax.security.auth.Subject.doAs(Unknown Source)

    at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:51)

Caused by: java.lang.RuntimeException: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 01414655 to /192.168.201.187:4447

    at org.jboss.naming.remote.protocol.IoFutureHelper.get(IoFutureHelper.java:87)

    at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:56)

    at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateCachedNamingStore(InitialContextFactory.java:166)

    at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:139)

    at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:104)

    ... 10 more

Caused by: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 01414655 to /192.168.201.187:4447

    at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:540)

    at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:511)

    at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)

    at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)

    at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)

    at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)

    at org.xnio.nio.NioHandle.run(NioHandle.java:90)

    at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)

    at ...asynchronous invocation...(Unknown Source)

    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)

    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)

    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)

    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)

    at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)

    at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:55)

    ... 13 more

Server Side

08:36:59,191 TRACE [org.jboss.remoting.remote.server] (Remoting "server4" read-1) Added mechanism GSSAPI

08:36:59,218 TRACE [org.jboss.remoting.remote.connection] (Remoting "server4" read-1) Sent message java.nio.HeapByteBuffer[pos=21 lim=21 cap=8192] (direct)

08:36:59,221 TRACE [org.jboss.remoting.remote.connection] (Remoting "server4" read-1) Flushed channel (direct)

08:36:59,691 TRACE [org.jboss.remoting.remote.server] (Remoting "server4" read-1) Server received authentication request

08:36:59,785 TRACE [org.jboss.remoting.remote.connection] (Remoting "server4" read-1) Connection error detail: javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)]

    at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(GssKrb5Server.java:113) [rt.jar:1.6.0_22]

    at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(FactoryImpl.java:85) [rt.jar:1.6.0_22]

    at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial$1.run(ServerConnectionOpenListener.java:316) [jboss-remoting-3.2.3.GA.jar:3.2.3.GA]

    at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial$1.run(ServerConnectionOpenListener.java:313) [jboss-remoting-3.2.3.GA.jar:3.2.3.GA]

    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_22]

    at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:313) [jboss-remoting-3.2.3.GA.jar:3.2.3.GA]

    at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:121) [jboss-remoting-3.2.3.GA.jar:3.2.3.GA]

    at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA.jar:3.0.3.GA]

    at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA.jar:3.0.3.GA]

    at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA.jar:3.0.3.GA]

    at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA.jar:3.0.3.GA]

    at org.xnio.nio.NioHandle.run(NioHandle.java:90)

    at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)

Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

    at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:108) [rt.jar:1.6.0_22]

    at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:128) [rt.jar:1.6.0_22]

    at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:189) [rt.jar:1.6.0_22]

    at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:406) [rt.jar:1.6.0_22]

    at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:60) [rt.jar:1.6.0_22]

    at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:150) [rt.jjar:1.6.0_22]

    at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(GssKrb5Server.java:96) [rt.jar:1.6.0_22]

    ... 12 more

08:36:59,814 ERROR [org.jboss.remoting.remote.connection] (Remoting "server4" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)]

From my understanding "Failed to find any Kerberos Key" means that the server did not find his Keytab to validate user authentication.

How do I indicate jboss server where to find his Keytab ?

Is there any documentation about how configuring GSSAPI mechanism on Jboss 7 ?

Any help would be greatly appreciated.

Client Code

public class RemoteEJBClient {

    public static void main(String[] args) throws Exception {

    System.out.println("*** Krb5LoginModule ***");

    LoginContext lctest=new LoginContext("GSSAPI", new SampleCallbackHandler()); 

    lctest.login();

    Subject.doAs(lctest.getSubject(), new JndiAction(args));

    }

}

public class JndiAction implements java.security.PrivilegedAction {

    private String[] args;

    public JndiAction(String[] origArgs) {

    this.args = (String[])origArgs.clone();

    }

    public Object run() {

    performJndiOperation(args);

    return null;

    }

    private  void performJndiOperation(String[] args) {

        // Set up environment for creating initial context

        Hashtable jndiProperties = new Hashtable();

        jndiProperties.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");

        jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,"org.jboss.naming.remote.client.InitialContextFactory");

        jndiProperties.put(Context.PROVIDER_URL, "remote://192.168.201.187:4447");

        jndiProperties.put("jboss.naming.client.ejb.context", "true");   

        try {

            /* Create initial context */

            DirContext ctx = new InitialDirContext(jndiProperties);

            // do something useful with ctx

            RemoteCalculator rc = (RemoteCalculator) ctx.lookup("ejb:/jboss-as-ejb-remote-app//CalculatorBean!" + RemoteCalculator.class.getName());

            System.out.println("Obtained a remote stateless calculator for invocation");

            // invoke on the remote calculator

            int a = 204;

            int b = 340;

            System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server");   

            int sum = rc.add(a, b);

            System.out.println("Remote calculator returned sum = " + sum);

            // Close the context when we're done

            ctx.close();

        } catch (NamingException e) {

            e.printStackTrace();

        }

    }

}

jaas.conf

GSSAPI {

    com.sun.security.auth.module.Krb5LoginModule required client=true debug=true;

};

Standalone.xml

<subsystem xmlns="urn:jboss:domain:remoting:1.1">

  <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">

    <sasl>

      <include-mechanisms value="GSSAPI"/>

    </sasl>

  </connector>

</subsystem>

[dlofthouse]

GSSAPI is not currently supported - it is actually the task I am currently working on to first ensure JBoss Remoting is compatible and then add support across AS7.

[npabst]

Thank you for you quick answer.

Do you have an idea when GSSAPI will be implemented ?

[dlofthouse]

I am working on it as we speak, I already have the majority prototyped based on a previous version but other priorities took over.  Depending on discussions with other developers I would hope some of the commits to start going in within the next couple of weeks - the main discussions are going to be around Remoting but once that part is in the rest is ensuring integration with the core of AS7 and our various clients.

[npabst]

Very well.

Thank you again for your answers Darran.

[rodakr]

GSSAPI works for me on red hat 5 with AS 7

my configuration on server side is like this:

https://community.jboss.org/blogs/radoslaw.rodak/2011/12/19/configure-spnego-on-as-7x

P.S:

Only think I had to do to not get Exception on Client Side , was in addition to jboss-client.jar to add this jar from jboss modules jboss-jacc-api_1.4_specxxxxx.jar

[dlofthouse]

Radek, your example is for enabling SPNEGO for web applications - we are talking about adding GSSAPI to the remote EJB invocations which are over Remoting.

[rodakr]

Yes, the first part is about GSSAPI configuration on Server Side.

But what I mean is JAAS login on client side to ActiveDirectory, before calling lookup to remote ejb in PrivilegedAction ..  using jass.config like this:

com.sun.security.jgss.krb5.initiate {

              com.sun.security.auth.module.Krb5LoginModule  required

              doNotPrompt=false

              useTicketCache=true

              renewTGT=true;

};

com.sun.security.jgss.krb5.accept {

              com.sun.security.auth.module.Krb5LoginModule  required

              useTicketCache=true;

};

The Client is doing the jaas login using jaas krb5 Login Module  to Active directory and with autheticated subject execute mySubject.doAS(mySubject,PrivilegedExceptionAction)

            String callbackUser  = "auser";

            String callbackPwd ="apassword";

            // jaas collback might be needed for ticket refresh...

           LoginContext lc = new LoginContext("com.sun.security.jgss.krb5.initiate",new NamePasswordCallbackHandler2(callbackUser,callbackPwd ));         

           lc.login();

           Subject mySubject = lc.getSubject();

            PrivilegedExceptionAction<String> action = new GetAction( null, null  );

            //jaas call the service

            String aRet = (String)mySubject.doAs(mySubject, action);

inside of Privileged Action you do call to remote ejb ( I have here subject from jaas login which is to KRB5 and not to Jboss remote instance ...)

         final Hashtable jndiProperties = new Hashtable();

         jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

         final Context context = new InitialContext(jndiProperties);

         Class itfClass = Thread.currentThread().getContextClassLoader().loadClass(testEjbItf);

        TestServiceItf testService = (TestServiceItf)  ctx.lookup("ejb:/test//testSLEJB3Bean!com.test.ejb3.TestServiceItf);

        System.out.println("lookup testEjbJndi successful");

        System.out.println(" call unsecured Method permittAllMethod()");

        Subject asu = testService.protectedMethod(" calling secured");

This seams to work.... because on server side I see my principal from subject. It seams to me remoting3 propagets allready Subject ( or principals in subject ) to remote server.

If Autheticator in Domain can validate it, then authentication on server Side is passed...

I just have to check if security is "realy switched on " on server side..

[dlofthouse]

Are you saying that your EJB is in a remote process from your Priviledged action or are both running in the same Java process?

[rodakr]

I tested also such cases from Web Container with some custome made picketbox authenticators.... but not for krb5 authentication.

For krb5 I have stand alone client jvm calling remote AS7 Server in different JVM.

But login Names are same for krb5 and custom Authenticator... so I will check, if it was in same JVM or not.

In some AS 7.1 beta versions before 7.1 or 7.1.1  final I was also able to do jaas login on client side and call EJB Method on remote AS7 Instanz in different JVM...   and I was wondering why it works... because the caller was not permited to call method.. and principal was allways "Anonymous" until I figure out, remote-connector was not asssigned to security realm....

In this context I would have a question, which is not related to this thread... I'm wondering why im standalone.xml I have section for <security-realms><security-realm name="ApplicationRealm"> and then somwhere else section for <security-domain name="other" .. >.

Why I'm asking is, because It's confusing... It would be much better, just to have instead of <security-realms><security-realm name="ApplicationRealm">  another domain <security-domain name="ApplicationRealm" .. >

And if I would like to protect remoting-connector with custom jaas Login module, I could just give just security domain name to configuration like this:

   <connector name="remoting-connector" socket-binding="remoting" domain-name="ApplicationRealm"/>

[npabst]

I have tried what you described Radek but I can't get it work.

I try the two following methods :

     1/ I configure my remote connector to use a security-realm which is protect by a jaas module. In this case, the server try to authenticate my access using sasl mechanisms and fails.

javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed

     2/ I don't assign the remote connector to any security realm and as you said the principal is "Anonymous"

I also add in standalone.conf

     -Djavax.security.auth.useSubjectCredsOnly=false  -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/lib64/libgssapi_krb5.so.2.2

After doing that i stopped having the exception "Failed to find any Kerberos Key" but GSSAPI authentication still does not work (no error message).

[npabst]

Hello again,

Darran Lofthouse a écrit:

I am working on it as we speak, I already have the majority prototyped based on a previous version but other priorities took over.  Depending on discussions with other developers I would hope some of the commits to start going in within the next couple of weeks - the main discussions are going to be around Remoting but once that part is in the rest is ensuring integration with the core of AS7 and our various clients.

Darran, do you have any news regarding the developpement of GSSAPI ? Do you think it could be integrated with version 7.2 ?

Also, is there a way to do jaas authentication without using PLAIN mechanisms ? Or is there a way to disable SASL without disabling completely security ?

Thanks in advance.

[dlofthouse]

Darran, do you have any news regarding the developpement of GSSAPI ? Do you think it could be integrated with version 7.2 ?

As before this is the task I am currently working on and my expectation is inclusion in AS 7.2.

Also, is there a way to do jaas authentication without using PLAIN mechanisms ? Or is there a way to disable SASL without disabling completely security ?

No and No - This is the reason we use realm definitions instead of JAAS domains - when working with JAAS the LoginModules expect a username and password to be supplied which is why we need to use the PLAIN SASL mechanism so we are sent the plain text password to send to the login module - to support other mechanisms the LoginModules are no longer just accessing a user store but they start to contain transport specific checks which means a LoginModule would need to be upated to support all transports in use.  I don't really follow how you would disable SASL but still expect it to be secure, if you are talking about the apporach taken in previous AS versions where SASL was not used the username and password were just sent in the clean with the request invocation so was effectively using PLAIN.

[rodakr]

Hi Darran

Ok I tested my cases against. (  jboss-as-7-1.2.0.Alpha1-SNAPSHOT.zip ( from http://hudson.jboss.org/jenkins/view/JBoss%20AS/  5 Jun 2012 )

You were right using GSSAPI ( or KRB5 jaas ) from  Stansalone jboss Client over SASL doesn't work yet.

Interessting is looks realy close to be finished... because it looks like the handshake starts....

Ok Here my relevant config in standalone.xml ( Server side )

<management>

        <security-realms>

            <security-realm name="ManagementRealm">

                <authentication>

                    <local default-user="$local"/>

                    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>

                </authentication>

            </security-realm>

            <security-realm name="ApplicationRealm">

                <authentication>

                  <jaas name="other"/>

                </authentication>

            </security-realm>

        </security-realms>

        <management-interfaces>

            <native-interface security-realm="ManagementRealm">

                <socket-binding native="management-native"/>

            </native-interface>

            <http-interface security-realm="ManagementRealm">

                <socket-binding http="management-http"/>

            </http-interface>

        </management-interfaces>

    </management>

  <subsystem xmlns="urn:jboss:domain:security:1.2">

            <security-domains>

              <security-domain name="host" cache-type="default">

                   <authentication>

                           <login-module code="com.sun.security.auth.module.Krb5LoginModule"  flag="required">

                               <module-option name="debug" value="true"/>

                                <module-option name="principal"

                                                                                         value="HTTP/[e-mail]"/>

                              <module-option name="storeKey" value="true"/>

                             <module-option name="useKeyTab" value="true"/>

                              <module-option name="doNotPrompt" value="true"/>

                           <module-option name="keyTab" value="/etc/krb5.keytab"/>

                       </login-module>

               </authentication>

            </security-domain>

            <security-domain name="other" cache-type="default">

                    <authentication>

                        <login-module code="org.jboss.security.negotiation.spnego.SPNEGOLoginModule" flag="sufficient">

                            <module-option name="password-stacking" value="useFirstPass"/>

                            <module-option name="serverSecurityDomain" value="host"/>

                            <module-option name="removeRealmFromPrincipal" value="true"/>

                        </login-module>

                        <login-module code="Remoting" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                        <login-module code="RealmDirect" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                    </authentication>

                    <mapping>

                        <mapping-module code="org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider" type="role">

                             <module-option name="rolesProperties" value="file:${jboss.server.config.dir}/sl-user-roles.properties"/>

                        </mapping-module>

                     </mapping>

                </security-domain>

                <security-domain name="jboss-web-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

                <security-domain name="jboss-ejb-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

            </security-domains>

        </subsystem>

	<subsystem xmlns="urn:jboss:domain:remoting:1.1">
	<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
	</subsystem>

In addition I added some modules as global with:

<subsystem xmlns="urn:jboss:domain:ee:1.1">

                  <global-modules>

                      <module name="sun.jdk" slot="main"/>

                      <module name="javax.api" slot="main"/>

                      <module name="org.jboss.security.negotiation" slot="main"/>

                      <module name="org.picketbox" slot="main"/>

                   </global-modules>

            <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>

            <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement>

        </subsystem>

And you need also to add modul "org.jboss.security.negotiation"  to modul dependecies of  remoting module  ( in modules/org/jboss/as/remoting/main/module.xml )

Once Server side is ready ( I have tested if SPNEGO to web Application works, this is working ) I tried on Client Side JAAS login with LoginContext "com.sun.security.jgss.krb5.initiate".

And then from in Action executed in Subject.doAS(Subject,action) I do this to get Context:

private static Context getInitialContext() throws NamingException {

         final Hashtable jndiProperties = new Hashtable();

         jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

         jndiProperties.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");

         final Context context = new InitialContext(jndiProperties);

         return context;

        }

the lookup to ejb works ( just proxy.. )

Then when I execute call on remote EJB method:

        Context ctx = getInitialContext();

        Class itfClass = Thread.currentThread().getContextClassLoader().loadClass(testEjbItf);

        TestServiceItf testService = (TestServiceItf)  ctx.lookup(testEjbJndi);

        Subject asu = testService.permittAllMethod(" calling unsecured");

On Server Side I'm getting this exception:

11:19:29,744 INFO  [org.jboss.as.ejb3] (MSC service thread 1-4) JBAS014142: Started message driven bean 'TopicConsumerMDBean' with 'hornetq-ra' resource adapter

11:19:29,756 INFO  [org.jboss.as.ejb3] (MSC service thread 1-2) JBAS014142: Started message driven bean 'TesterMDBean' with 'hornetq-ra' resource adapter

11:19:29,817 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018210: Registering web context: /krb5

11:19:29,867 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 34) JBAS018559: Deployed "sl-securityTestEjb3.jar"

11:19:29,867 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 34) JBAS018559: Deployed "krb5.war"

11:19:29,890 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:9990

11:19:29,891 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 7579ms - Started 314 of 400 services (85 services are passive or on-demand)

11:19:41,052 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (Remoting "ux2084" task-1) Login failure: javax.security.auth.login.LoginException: No NegotiationContext and no usernamePasswordDomain defined.

        at org.jboss.security.negotiation.spnego.SPNEGOLoginModule.innerLogin(SPNEGOLoginModule.java:187) [jboss-negotiation-spnego-2.2.0.SP1.jar:2.2.0.SP1]

        at org.jboss.security.negotiation.spnego.SPNEGOLoginModule.login(SPNEGOLoginModule.java:137) [jboss-negotiation-spnego-2.2.0.SP1.jar:2.2.0.SP1]

        at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.6.0_21]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_21]

        at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_21]

        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) [rt.jar:1.6.0_21]

        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [rt.jar:1.6.0_21]

        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [rt.jar:1.6.0_21]

        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_21]

        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [rt.jar:1.6.0_21]

        at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [rt.jar:1.6.0_21]

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.9.Final.jar:4.0.9.Final]

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.9.Final.jar:4.0.9.Final]

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.9.Final.jar:4.0.9.Final]

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.9.Final.jar:4.0.9.Final]

        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:354) [jboss-as-security-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:324) [jboss-as-security-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:157) [jboss-as-domain-management-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:164) [jboss-as-domain-management-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.as.security.RealmDirectLoginModule.handle(RealmDirectLoginModule.java:168) [jboss-as-security-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.as.security.RealmDirectLoginModule.validatePassword(RealmDirectLoginModule.java:199) [jboss-as-security-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

        at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:290) [picketbox-4.0.9.Final.jar:4.0.9.Final]

What do you think... using org.jboss.security.negotiation.spnego.SPNEGOLoginModule will be the right way or not?

[dlofthouse]

Yes you are correct that it is very close, most of it we actually already get for free by using SASL as it is a standard mechanism - the part just completing is the compatibility with the threading model of JBoss Remoting.