2 Replies Latest reply on Dec 8, 2004 11:52 AM by Scott Stark

    jbossmq with CallerIdentityLoginModule

    Philippe C Newbie

      I am going to install this minimal configuration for JBoss 3.2.2RC3.
      Do I need to have Tomcat JBossWeb HTTP server or do I need to have integrated Jetty 4.2.11 instead of Tomcat or does it matter at all?
      Is the advice to have Jetty above actually an advice to have any Web/JBoss or should it be necessarily Jetty?
      And another question. Will I be able to deploy MBeans and invoke methods on them with this type of installation? Or is JMX-Console not enough for that?

        • 1. jbossmq with CallerIdentityLoginModule
          Philippe C Newbie

          I am trying to get jbossmq to use my EJB's Security information to create, write and read topics. I have 2 Security Domains:

          1. MyEJBSecurityDomain configured with an LdapLoginModule

          2. jbossmq configured with
          <application-policy name="jbossmq">
           <login-module code="com.brockhousecooper.tw.ejb.server.authentication.CallerIdentityLoginModule" flag="required">
           <module-option name = "managedConnectionFactoryName">jboss.jca:name=JmsXA,service=TxCM</module-option>

          I use this code to login from within an MBean and create a TopicConnection
          lc = new LoginContext("client-login", handler);
          log.info("principal before: " + SecurityAssociation.getPrincipal());
          connection = conFactory.createTopicConnection();

          the log prints "principal before: admin" before creating the topic, however, jbossmq's Security Interceptor reports:
          [ServerSecurityInterceptor] Autenticating user null/null
          and the calls GetPrincipalInfoAction.getPrincipal() and GetPrincipalInfoAction.getCredential() inside CallerIndentityLoginModule both return null.

          Are my login modules badly configured or is this a bug in CallerIdentityLoginModule?

          • 2. 3851001
            Scott Stark Master

            Ah, now I see what you're saying. Thanks.

            I suppose there'd be no good way to cluster the injected abort state without doing an mbean lookup on every call rather than injecting to a static field in the interceptor from the jmx manager, though. That's dealable with, however, since in a cluster we'll presumably know what node the problem thread is running on.