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

Moderator: admin

Post Reply
deadlock_gr
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by deadlock_gr »

Shouldn't there be additional <security-role> elements for USER and ADMIN?

Code: Select all

<assembly-descriptor>
   <security-role>
       <role-name>CUSTOMER</role-name>
   </security-role>
   <security-role>
       <role-name>USER</role-name>
   </security-role>
   <security-role>
       <role-name>ADMIN</role-name>
   </security-role>
</assembly-descriptor>
or at least

Code: Select all

<assembly-descriptor>
   <security-role>
       <role-name>CUSTOMER</role-name>
   </security-role>
   ...
</assembly-descriptor>

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

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

Post by admin »

I don't think that is necessary because as per section 17.4.2, "The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined by means of the DeclareRoles and RolesAllowed metadata annotations and/or security-role elements of the deployment descriptor."

So the roles defined in the annotations do not need to be included in the deployment descriptor.

thank you,
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.603 :

Post by himaiMinh »

Session 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 the way by means of the security-role deployment descriptor elements.
So, based on this quote, the deployer is expected to map the principals or groups to all of these three roles.

However, if method permission is defined for CUSTOMER in the deployment descriptor, the deployer only needs to map the principals or groups to CUSTOMER. It is because the deployment descriptor overrides the roles specified by the annotations in the bean class.
Compare this question with anther question ejbd.v6.2.616:

Code: Select all

@Stateless public class EnthuBean implements Enthu {   
  @RolesAllowed("user")    
  public void doStuff(){ }      
   public void doMoreStuff(){ } } 
 Further, the following snippet exists in the deployment descriptor ...  
<method-permission>    
         <role-name>customer</role-name>    
         <method>      
            <ejb-name>EnthuBean</ejb-name>      
          <method-name>doStuff</method-name>    
           </method> 
   </method-permission>
In this case, the deployment descriptor overrides the roles allowed for doStuff method. So, the deployer only needs to map principals/groups to customer roles.
It is optional for the deployer to map principals/groups to user roles.

Correct me if I am wrong.

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

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

Post by admin »

Can you please point me to where the specification says the roles in the deployment descriptor override the roles in annotations? As per 17.3.1, they are all additive.
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.603 :

Post by himaiMinh »

Let me fix my post by saying "deployment descriptor overrides the role defined by annotation."

I don't want to mislead other readers. :D

It should be method permission defined in deployment descriptor overrides the method permission defined by annotation in the bean class.

For example, in deployment descriptor, the method permission specifies CUSTOMER to access doStuff method. But in @RolesAllow within the bean class, it specifies USER to access doStuff method.

In this case, which role can access doStuff ? The answer is CUSTOMER.

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

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

Post by admin »

himaiMinh wrote:
It should be method permission defined in deployment descriptor overrides the method permission defined by annotation in the bean class.

For example, in deployment descriptor, the method permission specifies CUSTOMER to access doStuff method. But in @RolesAllow within the bean class, it specifies USER to access doStuff method.

In this case, which role can access doStuff ? The answer is CUSTOMER.
Where in the specification did you see a rule that implies this?
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.603 :

Post by himaiMinh »

I am using ejbd.v6.2.612 as an example.
In this example, @RolesAllowed ("user") is specified for doStuff method in the bean class. But in the deployment descriptor, doStuff is accessible by customer.
So, this doStuff is accessible by customer role, not user role.

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

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

Post by admin »

No, that is not what the explanation to 612 says. Explanation says that only customer role has access to both the method, which is correct.
The explanation should also say that user in "user" role may still doStuff(String ). This has now been added.
-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.603 :

Post by himaiMinh »

To answer this question:
Where in the specification did you see a rule that implies this?
But the spec says on p.484
"The application assembler can define , augment or override the method permissions using the deployment descriptor"
and
p.495
Any values explicitly specified in the deployment descriptor override any values specified in annotations.
So, I think <method-permission> can override the role allowed defined in the bean code?

This is demonstrated in ejbd.v6.2.616:
The doStuff() method is annotated by @RolesAllowed ("user"). But the deployment descriptor
defines <role-name>customer</role-name> for doStuff.
The explanation "Deployment descriptor values always override annotation values...."

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

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

Post by admin »

I am trying to find where in the spec it shows how to actually do these three things i.e. define, augment and override. Define is ok but I don't see how to make a distinction between augment and override.

It looks like the two statements are contradictory. In one place it says "Deployment descriptor values always override annotation values...." and in another it says, "The application assembler can define , augment or override the method permissions using the deployment descriptor".

-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.603 :

Post by himaiMinh »

I am not sure if that will be on the exam.

The JEE tutorial says at http://docs.oracle.com/javaee/5/tutorial/doc/bnbyl.html
Defining Security Roles
....
You can augment the set of security roles defined for the application by annotations using the security-role deployment descriptor element to define security roles, where you use the role-name element to define the name of the security role.
However, the specification says the method permission overrides the annotations.

As the example shown in my previous post, I use GlassFish 3.1.2 to implement the question in ejbd.v6.2.616.
The dd defines customer as the role to access the two doStuff methods.
In one of the doStuff() method, it is annotated as @RolesAllowed("user").
As I tried, a user role is not allowed to access doStuff() as the dd overrides the role by customer.

I wonder this feature may be application server specific. Maybe, GlassFish uses dd to override annotations. Maybe, other servers uses dd to augment annotations.

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

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

Post by admin »

himaiMinh wrote:I wonder this feature may be application server specific. Maybe, GlassFish uses dd to override annotations. Maybe, other servers uses dd to augment annotations.
Yes, that is possible.
If you like our products and services, please help us by posting your review here.

henrid
Posts: 31
Joined: Sun Oct 13, 2013 1:20 pm
Contact:

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

Post by henrid »

One thing is still not clear to me.
If a class has @RolesAllowed("USER") and @DeclareRoles("ADMIN"), does only USER has access to its methods, or also ADMIN?
Thus does @DeclareRoles imply @RolesAllowed implicitly or not?
Otherwise I would expect:
@RolesAllowed("USER","ADMIN") and @DeclareRoles("ADMIN") in order to make using ADMIN available for isCallerInRole()
If @DeclareRoles in itself does not allow a role for the method, it should be duplicated in @RolesAllowed

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

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

Post by admin »

@RolesAllowed determines which roles can access the method , while @DeclareRoles determines the result of the method call isUserInRole . ( https://docs.oracle.com/cd/E19316-01/81 ... index.html )

In your example only USER is allowed in to invoke the method isUserInRole("ADMIN") will return false. So yes, I think the roles declared in @DeclareRoles should be present in @RolesAllowed.
If you like our products and services, please help us by posting your review here.

henrid
Posts: 31
Joined: Sun Oct 13, 2013 1:20 pm
Contact:

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

Post by henrid »

Thanks. That what I was thinking too. Because what's the point of checking a user in the role, when it cannot propagate into the method either.
At least, the source code calls it "CrazyBean" :lol:

JOHNATHON
Posts: 1
Joined: Wed Apr 17, 2019 7:01 am
Contact:

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

Post by JOHNATHON »

Crazy Bean :lol: :lol:

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests