7 Replies Latest reply on Aug 18, 2006 11:11 AM by acoliver

    Feature Request - I'll do the work!

    sappenin
    sappenin Jul 28, 2006 5:17 PM

      Sorry if this has been addressed. If so, please point me in the right direction.

      I would like to be able to lock down the JMS queues that JBCS uses (like localmail, remotemail, etc). I don't want a random application to be able to place messages into those queues without authenticating.

      Currently, the JMSMailListener doesn't authenticate when it connects to the JMS queues to "put" messages on them (i.e., the "unauthenticated user" identity is used). In JMSMailListener.putMessage(...), there should be an option to authenticate as a given user (i.e., a "system" or "admin" user, for example).

      I would be willing to add the code necessary to get the "putMessage" function to authenticate as some pre-specified user, but I'm wondering what is the best way to do get userid/password information for such a "system" user.

      Does it make sense to have "system"/"admin" userid and password attributes in the jboss-service.xml Listener definitions (and tweak the Mbean code as well)? That way, a given listener would be able to query what the "system" userid/password is.

      Unfortunately, If it were designed this way, then every listener would need to define an authentication userid/password, which isn't exactly pretty.

      Is there a better way to accomplish this?

      Thanks!

      David

      • 28334 Views
      • Tags:
        • 1. Re: Feature Request - I'll do the work!
          acoliver
          acoliver Jul 28, 2006 8:23 PM (in response to sappenin)

          I just remove all the invokers except for the JVM invoker. I don't see the type of security you mention to be generically useful enough to incorporate it as it would complicate security pretty dramatically. Besides you'd have to store the user/password for the mail listener locally anyway and if anyone has the abillity to deploy an app then they presumably have the abillity to get at that password. I'm not 100% against it if you can demonstrate it in a non-invasive generically useful way...but this seems like a special requirement and I don't see a great deal of non-perception-only security added by it... Maybe I'm wrong...but I don't see it.

            • Actions
          • 2. Re: Feature Request - I'll do the work!
            aronsogor Jul 29, 2006 1:08 AM (in response to sappenin)

            I remember playing with something like this..

            Semi-Simple:
            The other way around would be to configure the JMS (Destination Mngr)to protected by the same realm as JBCS. This way the user would have an authernticated, and have authorization to publish.

            More advanced:
            That I partially know( and there was some beer in the conversation) to configure the some realm hierarchy, and make the JMS accept JBCS realm authenticaed users.

            In both case I think this would be:
            - invasive and complex.
            - but still much more elegant than usernames/passwords all over config files.

            The main idea is that if you have access to the publish codebase why not use the JAAS that is already there vs trick with semi-secret passwords.
            + password maintance would be really painfull.

            Aron

              • Actions
            • 3. Re: Feature Request - I'll do the work!
              sappenin
              sappenin Jul 31, 2006 10:19 AM (in response to sappenin)

              I agree that the "username/password" in a config file is intrusive and non-elegant.

              I like the idea of disabling the invokers. The only downside is that a system may indeed WANT to have a separate machine publish to a remote queue on the JBCS machine. Disabling the invoker would prevent this. Even so, one may make the argument that if there's going to be 2 servers communicating stuff between them (like, "send this message"), then a web-services interface might be a better service interface than a remote, password-protected queue.

              Just in case, though (directed at AronSogor), how would the "JAAS semi-simple" solution work? I was thinking yesterday about the way EJB's have a "runas" annotation, directing the bean to "Run As" a given user role. Is there a way to get MBeans to do something like this, since (for example) the JMSMaillistener is the one submitting to the mail queue.

              If the JMS is protected by JAAS (in your semi-simple solution), then what is the mechanism for becoming the role that you want to use when publishing to the queue?

              Thanks!

              David




                • Actions
              • 4. Re: Feature Request - I'll do the work!
                aronsogor Aug 2, 2006 1:22 AM (in response to sappenin)

                I think you do not want to runas the MBean. There should be context established when the user authenticates via SMTP/POP/IMAP.

                Use the users's realm.

                  • Actions
                • 5. Re: Feature Request - I'll do the work!
                  sappenin
                  sappenin Aug 2, 2006 10:08 AM (in response to sappenin)

                  How do you access the JAAS user context out of an mBean (e.g., inside of JMSMailListener)?

                    • Actions
                  • 6. Re: Feature Request - I'll do the work!
                    sappenin
                    sappenin Aug 17, 2006 5:59 PM (in response to sappenin)

                    Aron or Anyone....can you point me in the right direction on this one?

                    Thanks!

                    David

                      • Actions
                    • 7. Re: Feature Request - I'll do the work!
                      acoliver
                      acoliver Aug 18, 2006 11:11 AM (in response to sappenin)

                      look at the APOP stuff.

                        • Actions