Thanks Wolf,

When I add:

jndiProps.put(Context.SECURITY_PRINCIPAL, "foo");

jndiProps.put(Context.SECURITY_CREDENTIALS, "bar");

the code works properly. However, I do not want to specify the credentials in the hash table and want the context factory to use the credentials as set by my:

LoginContext lc = new LoginContext("client-login", new UsernamePasswordHandler(userName, password.toCharArray()));

lc.login();

From the link you provided, I do not see any references to JAAS. I still see username/password hardcodes as properties.

Excuse me for misstating the real issue. We do not care about the JNDI lookup not being hardcoded with  security details. We want the freedom to invoke the EJB using the ClientLoginModule. It looks like Sasl Client setup does not take the credentials as set by ClientLoginModule into account. Is this supported? This worked just fine in 4.x and 6.x. I saw remote.connection.default.callback.handler.class property but could not find a CallBackHandler to  simply read what was setup by ClientLoginModule. I must be missing something.

public class TestRemoteReference {
 
    public static void main(String[] args) {
        try {
           Properties jndiProps = new Properties();
           jndiProps.put(Context.PROVIDER_URL,"remote://localhost:4447");
 
           jndiProps.put(Context.SECURITY_PRINCIPAL,   "username");
           jndiProps.put(Context.SECURITY_CREDENTIALS, "password");                      
           jndiProps.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
 
           Context ctx = new InitialContext(jndiProps);
 
           Properties clientProp = new Properties();
           clientProp.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
           clientProp.put("remote.connections", "default");
           clientProp.put("remote.connection.default.port", "4447");
           clientProp.put("remote.connection.default.host", "localhost");
//           clientProp.put("remote.connection.default.username", "username");
//           clientProp.put("remote.connection.default.password", "password");
           clientProp.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
           clientProp.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
           clientProp.put("remote.connection.default.callback.handler.class", "org.jboss.security.auth.callback.JASPICallbackHandler");
 
 
           EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(clientProp);
           ContextSelector<EJBClientContext> selector = new ConfigBasedEJBClientContextSelector(cc);
           EJBClientContext.setSelector(selector);                                 
 
           Service service = (Service) ctx.lookup("XXX"); // No issues here
 
 
           // Local login as another user. Hoping that SASL will somehow pick these
           // credentials up before invocation
 
           // Client login module gets called and sets up the 
           // the correct principal in SecurityAssociationActions.
 
 
           LoginContext c = SecurityUtils.login("client-login", "username2", "password2");
 
           // Fails witht he dreaded "No EJB receiver available" but the real exception is a security 
           // Exception. If we uncomment the security info in the remote connection properties, it works fine
 
 
           Object result = service.doSomething()
        }
        catch(Throwable ex) {
            ex.printStackTrace();            
        }
    }
}
 
 
login.conf
client-login {
   org.jboss.security.ClientLoginModule  required
          ;
};
 

Hi Darran,

Will it be? What alternative methods do you suggest we use to achieve such a basic requirement?

Thanks

Darran,

Do you have an existing jira issure for the " re-authentication issue on an existing connection."?

Hi Wolf,

I would appreciate the example. This is a major rewrite in our application of what has been working for the past 8 years. A bit troublesome is that EJB authentication on the server side does work with the ClientLoginModule. 

With 7.x, there is now a big difference on how local vs remote ejb's are invoked. In local mode, security context can be propogated using ClientLoginModule. Unlike remote calls. EJB invocations should be consistent and they now feel worlds apart. While all the optimizations in the remoting layer are appreciated, taking away thread-set-credentials in remote calls will undeniably cause a lot of headaches for developers. Just my 2 cents.

Tarek

Hi Jaikiran,

I kind of worked around 1 but with a serious kludge which involved caching various InitialContexts based on credentials. Your method is most definitley more elegant. Thank you for putting the time in this. One thought that kept coming back is with the whole notion of "fixing" the credentials at connection establishment time and effectively do away with credential propogation at call time. I do see why to a certain extent and reworked our code to work with this model. You guys truly do a fantastic job. Please keep it up.