MDB authentication: run-as appears to be ignored
chewitty Mar 11, 2002 7:14 AMHi,
I am having some difficulty with JAAS authentication and my MDBs. I have setup all the JAAS authentication configuration as per the documentation. I am using ClientLoginModule (client-side) and DatabaseServerLoginModule (server-side). I am using Jboss2.4.4-Tomcat4.0.1 bundle.
The only way I could get JBoss to pickup the ClientLoginModule instead of the default UsersRolesLoginModule was to use a security_policy.xml file:
<?xml version = "1.0" encoding = "UTF-8"?>
<application-policy name = "client-login">
<login-module code="org.jboss.security.ClientLoginModule" flag="required">
</login-module>
</application-policy>
<application-policy name = "mysecurity_auth">
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="principalsQuery"><![CDATA[SELECT PASSWORD FROM users WHERE PRIM_EMAIL=?]]></module-option>
<module-option name="rolesQuery"><![CDATA[SELECT NAME, RGROUP FROM roles WHERE USERID=?]]></module-option>
<module-option name="dsJndiName">java:/jdbc/myDBPool</module-option>
<module-option name="unauthenticatedIdentity">nobody</module-option>
</login-module>
</application-policy>
I am using FORM-based authentication and everything is working just fine but for my MDBs.
Problems:
[1] First I couldn't even post messages to a topic successfully because the SecurityInterceptor kept throwing a security exception on attempting the corresponding MDB onMessage() method. I would have thought that MDB don't expect to enforce security at this point given that the client has no direct interaction with it. The only way I could resolve this problem was to turn-off the SecurityInterceptor for MDBs in standardjboss.xml. I have to admit that I have not fully understood what the implications of doing this would be - has someone else found out something further???
[2] The other MDB problem is that when calling a method on one f my secured session/entity EJB - it is of course expected to appropriately authenticated. In my deployment descriptor the MDB attributes are appropriately set using the <run-as> element tags in <security-identity>. However, it appears that the container is failing to (a) pick this up or (b) failing to enforce this. Consequently, it is impossible to call a method on a secured EJB. Has anyone been able to fully resolve this issue such that they can enlighten me as well? I have checked and doubled checked he mailing lists and forums and even checked the test example (RunAsMDB) sited on one occasion by Scott but I am still unable to resolve this issue. Please Scott, can you help here??
This is a typical MDB ejb-jar entry:
<message-driven id="AdminOrdersMDB">
<![CDATA[Monitors messages on the AdminOrdersTopic and updates the admin_orders table accordingly]]>
<ejb-name>AdminOrdersMDB</ejb-name>
<ejb-class>com.sampel.ejb.AdminOrdersMDBean</ejb-class>
<transaction-type>Container</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
<ejb-ref>
<ejb-ref-name>ejb/OrderManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
com.sampel.ejb.OrderManagerHome
com.sampel.ejb.OrderManager
<ejb-link>OrderManagerBean</ejb-link>
</ejb-ref>
<security-identity>
<run-as>
<role-name>nobody</role-name>
</run-as>
</security-identity>
<resource-ref>
<res-ref-name>mail/Mail</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</message-driven>
All the appropriate roles, including 'nobody' above have been properly setup and tested to be working elsewhere - apart from MDBs. It is also important to add that with security everything works just fine. I also have picked up the fact that I may choose to separate the MDBs into a separate jar - which may be unsecured (as per jboss.xml) - however, why shouldn't I be able to package MDBs in a secured jar normally??
Any feedback that can help to move this further would be most appreciated.
Best regards,
Ferdinand