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

[Piotr Nowicki]

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.

@Stateless
public class MyTest {
     
     @Resource SessionContext ctx;
     
     public void doSmth() {
         ctx.isCallerInRole("test");
     }
}

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

2. No ejb-jar.xml.

@Stateless
@DeclareRoles("test")
public class MyTest {
     
     @Resource SessionContext ctx;
     
     public void doSmth() {
         ctx.isCallerInRole("test");
     }
}

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

3. With ejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee" version = "3.1" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"> <assembly-descriptor> <security-role> <role-name>test</role-name> </security-role> </assembly-descriptor> </ejb-jar>
and EJB:

@Stateless
public class MyTest {
     
     @Resource SessionContext ctx;
     
     public void doSmth() {
         ctx.isCallerInRole("test");
     }
}

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
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee" version = "3.1" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"> <enterprise-beans> <session> <ejb-name>MyTest</ejb-name> <security-role-ref> <role-name>test</role-name> <role-link>xxx</role-link> </security-role-ref> </session> </enterprise-beans> <assembly-descriptor> <security-role> <role-name>xxx</role-name> </security-role> </assembly-descriptor> </ejb-jar>
and EJB:

@Stateless
public class MyTest {
     
     @Resource SessionContext ctx;
     
     public void doSmth() {
         ctx.isCallerInRole("test");
     }
}

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!

[Jayr Motta]

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!

[Piotr Nowicki]

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]

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]

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]

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]

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]

Pedro,

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

[Piotr Nowicki]

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:

<?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee" version = "3.1" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"> <enterprise-beans> <session> <ejb-name> SecurityBean </ejb-name> <security-role-ref> <role-name>test</role-name> </security-role-ref> </session> </enterprise-beans> </ejb-jar>

Cheers!

[Vinay Kejriwal]

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,