Robert Brendler <robert.brendler(a)gmail.com&gt; wrote, in response to Robert Brendler: I could only achieve my intended result by adding an additional if ( ctx.isCallerInRole("user") && !ctx.isCallerInRole("guest") ) { // needs to explicitly exclude all other roles return principal.toString(); } else { // throw new EJBAccessException("Username '"+principal.toString()+"' does NOT have role 'user'"); return null; // for the lazy ones } this is far from desireable ... IP address: 87.139.232.83 Link to comment: http://redirect.disqus.com/url?url=http%3A%2F%2Fjboss.org%2Fjdf%2Fquickst... Robert Brendler wrote: I am not sure if this is valid usage of ejb security but when I add another possible role in @ServletSecurity, lets simply call it "user". Role "user" does not include rights of "guest" and vice versa, so when I annotate a second method in the SecuredEjb like the following I expect that it is forbidden for "guest". @RolesAllowed({"user"}) public String getSecurityInfoUser() I log in as "guest" and in the Servlet's doGet() method make a call to both methods, both return the same result. This leads me to the conclusion that all security annotations in SecuredEjb are rather useless, because the actual authorization happens via the authentication in the Servlet via @ServletSecurity. Basically this means I will have to create a separate Servlet for every role and duplicate code or... ----- Options: You can moderate through email. Respond in the body with "Delete". Reply with "Like" to like this comment, or respond with anything else to approve this comment and post your message as a reply comment. Or use the moderate panel: http://jdf.disqus.com/admin/moderate/#/pending To turn off notifications, go to: http://disqus.com/account/