File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes SessionContext#isCallerInRole(-) /w <security-role> but /wo @DeclareRoles Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "SessionContext#isCallerInRole(-) /w <security-role> but /wo @DeclareRoles" Watch "SessionContext#isCallerInRole(-) /w <security-role> but /wo @DeclareRoles" New topic
Author

SessionContext#isCallerInRole(-) /w <security-role> but /wo @DeclareRoles

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Ranchers!

Should I be able to execute Principal#isCallerInRole("test") without @DeclareRoles if I have a <security-role> defined in my ejb-jar.xml file?

Just take a look at these examples:

1. No ejb-jar.xml.


Exception - I can't use isCallerInRole(-) if I didn't use @DeclareRoles.

2. No ejb-jar.xml.


Ok - works fine - I've declared "test" role and can use isCallerInRole("test").

3. With ejb-jar.xml

and EJB:

Exception - just like in first case. What's different - now I have a security role "test" defined in my DD. I don't want to use @DeclareRoles once more. Should I be able to achieve it?

4. With ejb-jar.xml

and EJB:

Works fine! It works when I explicitly define a security-role-link, but I doesn't work with just the security-role defined.

I'm surprised
I've always thought that if there is no security-role-link, the container will try to find the role with the exact name as looked.

Is this the desired behaviour?

Thanks in advance!

Cheers!


OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
Jayr Motta
Ranch Hand

Joined: Jul 30, 2010
Posts: 110

Pedro,

According to the section 17.2.5.2 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
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thanks for rapid answer Jayr! :-)

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?

Thanks in advance!

Cheers!
Jayr Motta
Ranch Hand

Joined: Jul 30, 2010
Posts: 110

Pedro,

Sorry, I should've observed the XML heh! :P

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).
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Jayr,

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 :-)

Cheers!
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Just to make sure we know what we're talking about - take a look at the application I prepared (http://www.2shared.com/file/ANg9AuAg/securityTest.html).

Should it work in this form? Should it "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. " ?

Thanks in advance!

Cheers!
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

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.

I hope it makes it clear.

Thanks Jayr for your time and help!

Cheers!
Jayr Motta
Ranch Hand

Joined: Jul 30, 2010
Posts: 110

Pedro,

But it worked without the link? I mean, directly by the name.

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Yup,

on Glassfish it works even if there is no <security-role> defined for given <role-name>. In other words, without @DeclareRoles the code works fine with this DD:



Cheers!
Vinay Kejriwal
Greenhorn

Joined: Mar 15, 2012
Posts: 5
Excellent explanation.

Basically it means that withouth @DeclaredRoles or <security-role-ref>, it is not possible to invoke ctx.isCallerInRole("role") in the bean code.

Explanation given here by enthuware seems to be confusing.
http://enthuware.com/forum/viewtopic.php?f=4&t=417


Thanks,
 
Don't get me started about those stupid light bulbs.
 
subject: SessionContext#isCallerInRole(-) /w <security-role> but /wo @DeclareRoles
 
Similar Threads
security DD tags..
Need help on Glassfish and EJB lookup
@DeclareRoles vs @RolesAllowed
MDB: problem using group as principal name when using @RunAs annotation
Security Role