1 2 3 4 Previous Next 52 Replies Latest reply on Aug 7, 2013 9:52 AM by massassa Go to original post
      • 15. Re: Custom jdbc login module for remoting
        dlofthouse

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

        • 16. Re: Custom jdbc login module for remoting
          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.

          • 17. Re: Custom jdbc login module for remoting
            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.

            • 18. Re: Custom jdbc login module for remoting
              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.

              • 19. Re: Custom jdbc login module for remoting
                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

                • 20. Re: Custom jdbc login module for remoting
                  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));
                              }
                  }
                  
                  
                  • 21. Re: Custom jdbc login module for remoting
                    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.

                    • 22. Re: Custom jdbc login module for remoting
                      danjee

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

                      • 23. Re: Custom jdbc login module for remoting
                        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

                        • 24. Re: Custom jdbc login module for remoting
                          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.

                          • 25. Re: Custom jdbc login module for remoting
                            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

                            • 26. Re: Custom jdbc login module for remoting
                              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.

                              • 27. Re: Custom jdbc login module for remoting
                                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


                                • 28. Re: Custom jdbc login module for remoting
                                  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.

                                  • 29. Re: Custom jdbc login module for remoting
                                    danjee

                                    I've raised an JIRA issue with this problem

                                     

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