I found an issue with the JndiLoginInitialContextFactory not creating a SecurityContext and hence not being propagated correctly by the org.jboss.ejb3.security.client.SecurityClientInterceptor. Looking at the SecurityClientInterceptor it seems the logic for creating a SecurityContext if one is not found should be updated to include the principal and credential: | // Get Principal and credentials | Principal principal = SecurityActions.getPrincipal(); | if (principal != null) invocation.getMetaData().addMetaData("security", "principal", principal); | | Object credential = SecurityActions.getCredential(); | if (credential != null) invocation.getMetaData().addMetaData("security", "credential", credential); | | //Get the security context | SecurityContext sc = SecurityActions.getSecurityContext(); | if(sc == null) | { | sc = SecurityActions.createSecurityContext(); | SecurityActions.setSecurityContext(sc); | } | The problem I saw was that the JndiLoginInitialContextFactory has set the principal and credential, but had not created a SecurityContext, and therefore an SC with a null principal and credential was sent over, effectively rendering the principal and credential metadata useless. Any other older code that is not creating a SecurityContext will also starting failing with the newer SecurityContext based logic. We need to be using the principal and credential when creating a SecurityContext. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236860#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...