About Question enthuware.oce-ejbd.v6.2.594 :

Moderator: admin

Post Reply
rkbansal83
Posts: 33
Joined: Sat Nov 24, 2012 8:52 am
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by rkbansal83 »

I think , it's second option which is correct but not the first option. Please confirm ?

when you say that (excerpt from EJB spec)
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
This means that absence of <role-link> element inside the <security-role-ref> element (not the element security-role-ref itself ) . So we must have <security-role-ref> <role-name> element in the DD or @DeclareRoles annotation in the bean code if we want to use isCallerInRole in the bean.

like this

Code: Select all

<enterprise-beans>  
    <session>  
        <ejb-name>  
            SecurityBean  
        </ejb-name>  
        <security-role-ref>  
            <role-name>test</role-name>      
        </security-role-ref>  
        </session>  
    </enterprise-beans>

See this link

http://www.coderanch.com/t/547984/java- ... ty-role-wo

From the above thread , it seems that even glassfish verifies this behavior.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by admin »

The whole security-role-ref is the linking piece. It is possible to not specify this, in which case the role name used in the code will be assumed to be the actual role name (if available).

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

fred flintstone
Posts: 2
Joined: Sat Jun 22, 2013 12:43 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by fred flintstone »

I agree with "rkbansal83". The EJB 3.1 specification states
The Bean Provider is responsible for using the DeclareRoles annotation or the security-role-ref elements of the deployment descriptor to declare all the security role names used in the enterprise bean code. […] If the DeclareRoles annotation is not used, the Bean Provider must use the security-role-ref elements of the deployment descriptor to declare the security roles referenced in the code.
That means, if the Bean Provider checks a role with isCallerInRole("customer") he must declare that role whith the @DeclareRoles annotation or with the security-role-ref-element (it's not optional, even if the @RolesAllowed("customer") annotation is present at method level). If the Bean Provider doesn't do this, it's an error, but the EJB 3.1 specification doesn't tell how to handle this case.

Glassfish 3.1 throws an IllegalStateException("No mapping available for role reference customer") in this case. So in my opinion the answer "StockEJB cannot use programmatic security model." should be correct.

Greetings
Fred

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by admin »

As per Section 17.2.5.3:
The Bean Provider is responsible for using the DeclareRoles annotation or the security-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 annotated 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 application.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.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by himaiMinh »

Regarding to option 1, in order to apply programmatic security, the ejb-jar.xml in this
the question should specify
<security-role-ref>user</security-role-ref>
<role-link>customer</customer>
In this case, isCallerInRole("user") works.

However, without <role-link>,
<security-role-ref>customer</security-role-ref>
as I test with GlassFish, the method can be accessed by the role customer, the getCallerPrincipal returns the authenticated user's principal of the customer, but isCallerInRole("customer") returns an exception.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by admin »

GlassFish is not following the specification. Please see the quote from the specification given in explanation to option 1.
If you like our products and services, please help us by posting your review here.

adriano.jesus
Posts: 4
Joined: Fri Dec 04, 2015 2:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.594 :

Post by adriano.jesus »

About options 1 and 2: I understood that I can use the programmatic security using the "customer" role in StocksEJB, even though, it is already configured in deployment descriptor for StocksEJB;

But, as the role "customer" is already configured to handle the security for StocksEJB, I did not figure out what would be a good reason to do it in a programmatic security way as well.

I know the purpose of the question, what you can do and what you cannot do, but is there any reason for do it?
I would make this question, but, I think a good reason to do that, it is in case of the absence of declarative security.

As I already have written this question, I decided to submit it, just for sharing this thinking;

Let me know if I run out of this portal's scope questions;

Best regards.

Post Reply

Who is online

Users browsing this forum: No registered users and 28 guests