I wanted to post an interesting observation. I have a custom LoginModule implementation that I was using. In the login module I was not using the SimplePrincipal and the SimpleGroups implementations provided by JBoss. I was using custom implementation of the java.security.Principal and java.security.acl.Group interfaces.

This seems to work fine for authentication of the web side but seemed to fail for the EJB. Both the web and EJBs were secured using the same domain that used my custom login module.

See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=67345 for my prior post.

When I did a small walk through of the JBoss source code (thank heavens its open source) I found that on the web container side, the roles are checked by getting the individual principals out of the Group as Strings (using the members() method first on the group and then the getName() on each Principal in the enumeration). Basically the security interceptor gets all the roles the user belongs to as strings and then checks to see if the desired role is present or not.

However, on the EJB side of things, the security interceptor directly calls the isMember() method on the Group named "Roles" found in the Subject. The argument passed to the isMember() method is of type org.jboss.security.SimplePrincipal. I was directly checking this against the Principals in my group. However, since the class of my principals were different the == was not working and I was getting SecurityExceptions thrown back during the EJB calls.

I understand that my impl of the isMember() method can be seen as flawed but why does JBoss have to have confilicting mechanisms to check roles on the Web and EJB fronts?

Any thoughts?