[dlofthouse]

Just quickly running a test to confirm but I think I see where this specific failure would be ocurring.

[danjee]

I was wrong, not the lookup is failing

The error appears on:

final Context context = new InitialContext(jndiProperties);

It's not reaching the the lookup. I will try to trim the application to a simple ear with one EJB and the embedded login module to check if problem persists.

[dlofthouse]

TBH I think I can reproduce without any deployment at all - should be a simple property on the env passed to the InitialContext so I am just verifying that.

[dlofthouse]

Try adding the following property in your client: -

jndiProperties.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

When moving to integrate with a JAAS login module we need the username and password to be available to pass into the login module for authentication so we need to configure the client to allow the passing of the password as plain - without this the client is trying to only use digest authentication.

[danjee]

I will give it a try tommorow morning. I've already left the office and I do not have any remote access there. Thank you for your time and interest

[danjee]

No changes after adding the NO_PLAIN_TEXT to false.

I've attached a stripped down ear with the login module embedded in it and a standalone.xml configuration.

This is my client code:

public class JndiTest {
          public static void main(String[] args) throws NamingException,
                              AppException, RemoteException {
                    final Hashtable<String, Object> jndiProperties = new Hashtable<String, Object>();


                    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://localhost:4447");
                    jndiProperties.put(Context.SECURITY_PRINCIPAL, "daniel");
                    jndiProperties.put(Context.SECURITY_CREDENTIALS,
                                        "c4ca4238a0b923820dcc509a6f75849b");
                    jndiProperties.put("jboss.naming.client.ejb.context", true);
                    jndiProperties
                                        .put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT",
                                                            false);
                    final Context context = new InitialContext(jndiProperties);
                    final String appName = "myear";
                    final String moduleName = "myejb3";
                    final String distinctName = "";
                    final String beanName = "CalculatorBean";
                    final String viewClassName = RemoteCalculator.class.getName();
                    String lookup = "ejb:" + appName + "/" + moduleName + "/"
                                        + distinctName + "/" + beanName + "!" + viewClassName;
                    System.out.println("lookup name: " + lookup);
                    RemoteCalculator facade = (RemoteCalculator) context.lookup(lookup);
                    System.out.println(facade);
                    System.out.println("test: " + facade.add(2, 2));
            }
}

[dlofthouse]

Daniel, can you try settiing the false to a String instead of boolean i.e. "false" - I need to check the intention but for some reason we are only passing on properties if the type is a String.

[danjee]

Hello, sorry for my late answer. I've tried it in both ways and I got the same result.

[danjee]

Hello,

I've tried different combinations for security-realms and login-module. I think that remoting with a realm configured only works when using application-users.properties (at least it was the only time I got clear username and correctly encoded password) but in the login module that is getting called when looking up the EJB I still got the random passwords. Anyway this is a combination that won't be used because users cannot be added to that properties file.

If no security is used for remoting I only get random password in my custom login module.

I've also tried with and jboss-ejb-client.properties file with this entries with no success also:

endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port = 4447
remote.connection.default.username=daniel
remote.connection.default.password=c4ca4238a0b923820dcc509a6f75849b
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

I update the attachments from a previous note to log out the username and password received by login module. I hope all this problems will be reduced to a missconfiguration

[dlofthouse]

Anyway this is a combination that won't be used because users cannot be added to that properties file.

Not really sure what you mean here - the point of the properties files is that users can be added to them.

If no security is used for remoting I only get random password in my custom login module.

Yes that is correct, if you disable security for remoting there is no username or password that can be sent to the login module.

In your config I see the following line: -

remote.connection.default.password=c4ca4238a0b923820dcc509a6f75849b

What is this password?  This property need to be the plain text password - not the pre-hashed password from the properties.

[danjee]

Darran Lofthouse wrote:

Anyway this is a combination that won't be used because users cannot be added to that properties file.

Not really sure what you mean here - the point of the properties files is that users can be added to them.

The users and passwords that will use the application should be managed in users database table not in a properties file held on application server.

In your config I see the following line: -

remote.connection.default.password=c4ca4238a0b923820dcc509a6f75849b

What is this password?  This property need to be the plain text password - not the pre-hashed password from the properties.

The password is hashed with md5 when saving user credentials. So it will be hashed when looking up the EJB to work like this: md5(users_password_from_password_field) = database_stored_password according to the login module

[dlofthouse]

Actually I think I see one more SASL option missing, for the JNDI lookup you also need to set the following: -

jndiProperties.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");

We have been considering if we need to be able to disable the local mechanism server side - I think the issues being encountered here are adding real justification that the answer is yes we do need that to be possible to be disabled for the realm used by apps at the very least.

[danjee]

I finally got it to work. The issue was the loading of custom security jar. It seems that putting it in the ear is not a solution (or at least not sufficient)

I added it on the jboss_install_dir/modules/org/jboss/as/remoting/main and modified the module.xml file at the same path to also use that resource.

I worked with or without the jndiProperties.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");

Thank you very much for your assistance, Darran

Daniel

[dlofthouse]

You're welcome Daniel - it has been very useful to see the kind of issues users are encountering to get this working so I can follow up on useability for the next releases.

In the meantime could I please ask you to raise a jira for the classloading issue - it shouldn't be over complicated for an end user to add custom modules so that probably also deserves a review.

[danjee]

I've raised an JIRA issue with this problem

https://issues.jboss.org/browse/AS7-3888