According to the section 18.104.22.168 of the EJB 3.1 specification:
The Bean Provider is responsible for using the DeclareRoles annotation or the secu-
rity-role-ref elements of the deployment descriptor to declare all the security role names used in
the enterprise bean code. The DeclareRoles annotation is specified on a bean class, where it serves
to declare roles that may be tested by calling isCallerInRole from within the methods of the anno-
tated class. Declaring the security roles allows the Bean Provider, Application Assembler, or Deployer
to link these security role names used in the code to the security roles defined for an assembled applica-
tion. In the absence of this linking step, any security role name as used in the code will be assumed to
correspond to a security role of the same name.
You haven't said which version of EJB are you relying, and I don't know the expected behavior of previous versions of the specification.
But assuming that you're using EJB 3.1, the only explanation could be that your implementation enforce the feature of multiple logical roles per bean(<security-role-ref>/@DeclareRoles) for each logical role(per application: <security-role>) by making it obligatory to describe at DD / annotation level.
I've seen some vendors not obeying some characteristics of the specification in order to improve reliability of the softwares written on top of it.
Hope this helps!
Feel free to ask me anything!
www.BlackBeltFactory.com/ui#!/ref=jmotta, SCJP 6, OCWCD JEE5, OCE EJB JEE6
You're right - I forgot to mention that I use EJB 3.1 (ejb-jar version = "3.1" in the posted ejb-jar.xml's).
I use the Java EE 6 RI - Glassfish 3.1.
I don't quite follow the idea of "not obeying to specification in order to improve reliability". Not obeying a specification is making the software less portable...
What AS do you mean and do you remember in what cases they didn't follow the specs?
Is there a possibility that you could test the code I posted on the AS you use, in order to see if this is a repeatable error?
What I've said about "not obeying to specification in order to improve reliability", I agree with you about portability, but I've some examples where the specification is too flexible where it should be more strict. If you read the specification you'll see that the expert group let a lot of spots for specific vendor features. I think this maybe could be some kind of strategy to improve competitivity among vendors while implementing more sofisticated and reliable software, but I'm just speculating.
I have some annotations that I've make on my notebook used to study EJB, can I send you the examples tonight(It's 14h right now where I live hehe)? If it's ok for you, I could also send you the result of the same test on JBoss (that's the one I use).
Yup, I've read the specification and the blind spots are left for vendor specific implementation. It's exactly for vendors' competition. The idea is that they should compete by providing the best, most efficient and easiest way to develop, configure, deploy and run your application; they should not compete about the core principals which the specification is very strict about.
Nevertheless, I'm interested if I misunderstood something from the spec (most likely!), or it is an inappropriate behaviour :-)
Ok, so for all the people who have the same problem with understanding of this part of the specification, here is my explanation:
@DeclareRoles is the same as <security-role-ref> and it affects the particular EJB roles (defined by the Bean Provider).
The specification (part cited by Jayr) says about "linking step". This "linking step" is not about the presence of <security-role-ref> element, but about the <role-link> element inside the <security-role-ref>.
The purpose of the <security-role-ref> is to define what roles does the Bean Provider use (<role-name>) and to what <security-role> element this role should be linked to <role-link>.
The "absence of this linking step" is the absence of <role-link> element in which case the <security-role-ref>'s <role-name> will be matched directly with the <security-role>'s name value.