Hi,
I have the following doubt regarding SecurityManager on JMS queues. Suppose i have queue as follows:

<mbean code="org.jboss.mq.server.jmx.Queue"
 name="jboss.mq.destination:service=Queue,name=MySampleQueue">
 <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
 </mbean>

I havent specified and SecurityManager over this queue. So the default SecurityManager will be used. This default SecurityManager is defined in
jbossmq-service.xml as follows:

<mbean code="org.jboss.mq.security.SecurityManager" name="jboss.mq:service=SecurityManager">
 <attribute name="DefaultSecurityConfig">
 <security>
 <role name="guest" read="true" write="true" create="true"/>
 </security>
 </attribute>
 <attribute name="SecurityDomain">jbossmq</attribute>
 <depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends>
 </mbean>

Please note the SecurityDomain that is being used: jbossmq.
This security domain has the following setting in login-config.xml:

<!-- Security domain for JBossMQ -->
 <application-policy name = "jbossmq">
 <authentication>
 <login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
 flag = "required">
 <module-option name = "unauthenticatedIdentity">guest</module-option>
 <module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
 </login-module>
 </authentication>
 </application-policy>

Note the "unauthenticatedIdentity" option here.

Now suppose i have a MDB which listens on this queue, then whenever a message is sent to this queue, then the jbossmq login-module will be used to login. Now, since :

When an MDB services a JMS message there is no "caller," so there is no security context to be obtained from the caller. Remember that JMS is asynchronous and doesn't propagate the sender's security context to the receiver

The "unauthenticatedIdentity" i.e. guest is used to login. Now once this accomplished, suppose i invoke a secure stateless session bean from the MDB, then wont the same security context(i.e. guest) be used
for accessing the bean, or will there be one more login carried out for accessing the stateless session bean. If suppose, one more login is carried out, then which login module will be used, is it the "other" login-module that will be used:

<!-- The default login configuration used by any security domain that
 does not have a application-policy entry with a matching name
 -->
 <application-policy name = "other">
 <!-- A simple server login module, which can be used when the number
 of users is relatively small. It uses two properties files:
 users.properties, which holds users (key) and their password (value).
 roles.properties, which holds users (key) and a comma-separated list of
 their roles (value).
 The unauthenticatedIdentity property defines the name of the principal
 that will be used when a null username and password are presented as is
 the case for an unuathenticated web client or MDB. If you want to
 allow such users to be authenticated add the property, e.g.,
 unauthenticatedIdentity="nobody"
 -->
 <authentication>
 <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
 flag = "required" >
 </login-module>
 </authentication>
 </application-policy>

The reason why i am asking this is, if i invoke a Secure Stateless session bean from MDB, i get Authentication Exception saying principal = null.
If i add the following line to the "other" login module then everything works fine:

<module-option name = "unauthenticatedIdentity">guest</module-option>

I wanted to know, how, why and when does this "other" login module coming into picture, in the above scenario.

Thank you.