Security Role

[Hendy Setyo Mulyo]

Hi All,

Currently I am still on preparing my way for SCBCD 5. Let say I have deployment descriptor in my application as following:

<enterprise-beans>
...
<session>
<ejb-name>EmployeeBean</ejb-name>
<ejb-class>com.hmulyo.employee.EmployeeBean</ejb-class>
...
<security-role-ref>
<description>
test
</description>
<role-name>manager</role-name>
</security-role-ref>
...
</session>
...
</enterprise-beans>

Also, here is the code in my application:

@DeclareRoles("employee")
@Stateless public class EmployeeBean implements Employee {

@Resource SessionContext ctx;
 
public void updateEmployeeInfo(EmplInfo info) {
                if (ctx.isCallerInRole("manager")) {
[B][I]// 1[/I][/B]
}
                if (ctx.isCallerInRole("employee")) {
[B][I]// 2[/I][/B]
}
        }

The question: which one either // 1 or // 2 will be executed? Considering I set the security role in my deployment descriptor and my code.
Thank you.
[ July 05, 2008: Message edited by: Hendy Setyo Mulyo ]

[Nikhil Jain]

//1 Would be executed.

<B>the xml always overrides annotations!!</B>

[Hendy Setyo Mulyo]

Thank you!

[J J Wright]

I think you're both completely missing the point here. You're asking which one will be executed right?

You have declared, via annotations and the deployment descriptor, that your bean code uses two role names; 'manager' and 'employee'. These then have to be linked to logical security roles defined in your application's security view.

The roles in your security view then have to be mapped to groups in the operational environment's security realm.

After all that has been done, which bit of code gets executed is entirely dependent on the role associated with the principal executing the code.

[J J Wright]

It may well be that if the principal executing the code is a manager, he will probably also be an emplyee, so you could end up with both A and B executing!

[Anish Mathur]

As per the specs section 17.3.1

The set of security roles used by the application is taken to be the aggregation of the security roles defined by the security role names used in the DeclareRoles and RolesAllowed annotations. The Bean Provider may augment the set of security roles defined for the application by annotations in this way by means of the security-role deployment descriptor element.

As per my understanding this means that the roles which are allowed to invoke a business method of a bean are
DeclaresRoles + RolesAllowed + security-role deployment descriptor.

[J J Wright]

You're confusing two different aspects of security here; programmatic (the use of isCallerInRole()) and declarative (method permissions).

When a Bean Provider writes a bean that uses programmatic security checks they must declare the role name(s) used in the code using DeclareRoles and/or security-role-ref. If they don�t, and the Application Assembler only has the bean byte code to work with, there�s no way of knowing how to use the bean.

The whole point of being able to write reusable components is that the bean may be used by many different applications/organisations. The Bean Provider has no idea what applications the bean may be used in so the Bean Provider uses arbitrary role name(s) in the bean code and declares them, along with a ddescription.

An Application Assembler from another organization can use this bean by linking the declared roles to actual roles used in their application. If no mapping is supplied the role names used in the code are assumed exist in the application.

DeclareRoles and/or security-role-ref have nothing to do with method permissions.

[Vinay Nath]

I agree with Anish, the question gives limited information to answer regarding annotation and DD roles aggregation concept.