Hi there,

I am in the process of migrating our app from JBoss 7.2 / EAP 6.3 to Wildfly 10 (and future EAP versions)

I am coming across strange behaviour with remote EJB calls from a standalone client which hopefully someone can help with.

First of all here is how our app is assembled.

We have an EJB layer which has a defined security domain of "app-server" (specified in jboss-ejb3.xml).

Our app-server security domain consists of a single login module which is a simple subclass of AbstractServerLoginModule. In this class we override getRolesets to retrieve the subject from SecurityContextAssociation and then retrieve the principals that are Groups, returning the result.

We have a servlet client (bundled in the same ear) which uses the "app-client" security domain (as specified in jboss-web.xml).  This consists of 2 login modules.  The first is our own for authentication, the second is an instance of ClientLoginModule which is populating SecurityAssociationActions via setPrincipalInfo

For remote EJB calls the remoting Subsystem is using the ApplicationRealm, where the authentication is set to JAAS "app-client" (i.e. same as what the web client does).

The behaviour we are seeing is as follows.

Logging in through web app (which works)

* hit our login module which correctly authenticates

* hit ClientLoginModule which calls SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject);

* perform ejb method

* hit our server login module which extracts the Subject from SecurityContextAssociation - all roles are present

Logging in from a remote EJB client (standalone application)

* hit our login module which correctly authenticates

* hit ClientLoginModule which calls SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject);

* perform ejb method

* hit our server login module which extracts the Subject from SecurityContextAssociation - subject is null  <-- UNEXPECTED <-- call fails. Note the subject that was passed into the login module contains the correct principal name, just no roles, and SecurityContextAssociation seems to have no subject.  It's as if something is clearing the subject before our code can run.

So coming in through the remoting connector is doing something differently than undertow is.

It's a bit confusing as it worked OK in JBoss 7.2 / EAP 6.3, and in wildfly (tested in 9.02, 10CR5) it only affects remoting connections, not the web client.

Hopefully someone can shed some light on this.

Thanks

Ian

EDIT: Some more info

I think I've traced the behaviour to the JaasCallBackHandler

Within JaasCallBackHandler.handle() it calls securityManager.push() which takes note of the current security context (which is null) and pushes it onto a stack.  It then creates its own SecurityContext and sets that as current (via SecurityContextAssociation.setSecurityContext)

JaasCallBackHandler then calls securityManager.authenticate() which hits my login module, and the client login module creates its security context and sets it current (however this does not manipulate the SimpleSecurityManager context stack).

JaasCallBackHandler then calls securityManager.pop() which replaces the current security context (my one with the info from the client login module) with the version on the stack (which is null) hence my security context is gone.

At least that's what I think is going on.

So now I just have to work out if I can configure round this or something!