About Question enthuware.ocejws.v6.2.224 :

All the posts and topics that contain only an error report will be moved here after the error is corrected. This is to ensure that when users view a question in ETS Viewer, the "Discuss" button will not indicate the presence of a discussion that adds no value to the question.

Moderators: Site Manager, fjwalraven

Post Reply
MichaelZett
Posts: 20
Joined: Wed Dec 10, 2014 8:28 am
Contact:

About Question enthuware.ocejws.v6.2.224 :

Post by MichaelZett » Thu Dec 11, 2014 10:58 am

If I'm not mistaken, the answers 2 and 4 are the same. Answer 2 with a correct explanation why it is wrong and answer 4 with a wrong explanantion.

fjwalraven
Posts: 429
Joined: Tue Jul 24, 2012 2:43 am
Contact:

Re: About Question enthuware.ocejws.v6.2.224 :

Post by fjwalraven » Thu Dec 11, 2014 4:08 pm

There is a subtle difference here with respect to the double quotes:

Answer 2 @RolesAllowed("student", "teacher") => defines two roles, but not in an array
Answer 4 @RolesAllowed("student, teacher") => defines one role only

When looking at the overrides @RolesAllowed("student") on the method level you would expect the answers 2 and 4 to be the same, however testing this code on glassfish tells me otherwise. I am trying to come up with a logical explanation but I haven't found one so far.

To make it more interesting (or confusing): if I put @RolesAllowed("teacher") on the class level and @RolesAllowed("student") on the method, the it won't allow me as a student to execute the method.

It will only override if I have at least the student role defined on the class level: @RolesAllowed({"student", "teacher"}), and the @RolesAllowed("student") on the method. (allowing students, but not teachers -> as expected)

Let me come back to you on this one!
Frits

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

Re: About Question enthuware.ocejws.v6.2.224 :

Post by admin » Thu Dec 11, 2014 8:31 pm

Since RolesAllowed annotation takes in an array of Strings, you can specify it as @RolesAllowed("student", "teacher") or @RolesAllowed({"student", "teacher"}) but not @RolesAllowed("student, teacher").

The first one will work because the annotation has only one parameter named values. If it had multiple parameters, then you would have to do something like: @RolesAllowed(values={"student", "teacher"}, param2="something")

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

fjwalraven
Posts: 429
Joined: Tue Jul 24, 2012 2:43 am
Contact:

Re: About Question enthuware.ocejws.v6.2.224 :

Post by fjwalraven » Sun Dec 14, 2014 3:52 am

I did some further research and there are a couple of interesting findings. Just to update you with the question details:
There is a RESTful Web Service that adds two numbers. We want to secure this Web Service in order to only allow users in the role "student". What is the correct JAX-RS root resource class to implement this requirement? Assume that there is a security constraint in the web deployment descriptor that allows "student" and "teacher" to access the URL.
There are 5 options given and only one is correct (according to the current setup: "None of the above")

Answer 1:

Code: Select all

@ApplicationPath("jax")
@Path("rs")
@Stateless
@RolesAllowed("student")
public class AdditionService extends Application {
   @GET
   @RolesAllowed("teacher")
   @Path("/add/{num1}/{num2}")
   public String addp(@PathParam("num1") int num, @PathParam("num2") int num2){
      return "" + (num+num2);
   }
}
No problem here: only teachers are allowed to execute the method -> answer is not correct

Answer 2:

Code: Select all

@ApplicationPath("jax")
@Path("rs")
@Stateless
@RolesAllowed("student", "teacher")
public class AdditionService extends Application {
   @RolesAllowed("student")
   @GET
   @Path("/add/{num1}/{num2}")
   public String addp(@PathParam("num1") int num, @PathParam("num2") int num2){
      return "" + (num+num2);
   }
}
No problem here: @RolesAllowed("student", "teacher") is not allowed giving a compilation error -> answer is not correct

Answer 3:

Code: Select all

@ApplicationPath("jax")
@Path("rs")
@Stateless
@RolesAllowed("teacher")
public class AdditionService extends Application {
   @GET
   @Path("/add/{num1}/{num2}")
   public String addp(@PathParam("num1") int num, @PathParam("num2") int num2){
      return "" + (num+num2);
   }
}
No problem here: only teachers are allowed to execute the method -> answer is not correct

Answer 4:

Code: Select all

@ApplicationPath("jax")
@Path("rs")
@Stateless
@RolesAllowed("student, teacher")
public class AdditionService extends Application {
   @RolesAllowed("student")
   @GET
   @Path("/add/{num1}/{num2}")
   public String addp(@PathParam("num1") int num, @PathParam("num2") int num2){
      return "" + (num+num2);
   }
}
There is problem with this answer as there are different interpretations of the EJB specification for the @RolesAllowed annotation.
JBoss AS 7.x => method allowed for students
Glassfish 3.1.x => method disallowed for students

... continued in next post ...

fjwalraven
Posts: 429
Joined: Tue Jul 24, 2012 2:43 am
Contact:

Re: About Question enthuware.ocejws.v6.2.224 :

Post by fjwalraven » Sun Dec 14, 2014 4:12 am

... continuation of previous post ...

The official API explanation:
Specifies the list of roles permitted to access method(s) in an application. The value of the RolesAllowed annotation is a list of security role names. This annotation can be specified on a class or on method(s). Specifying it at a class level means that it applies to all the methods in the class. Specifying it on a method means that it is applicable to that method only. If applied at both the class and methods level , the method value overrides the class value if the two conflict.
Note that @RolesAllowed("student, teacher") defines one role of "student, teacher"

JBoss' interpretation: there is a conflict between class and method annotation: the method annotation @RolesAllowed("student") overrides the class annotation @RolesAllowed("student, teacher")

Glassfish's interpretation: there is no conflict between class and method annotation. The class annotation is the one that is being used: disallowing Principals in the role of "student" to execute the method. In Glassfish's implementation there is only a conflict it at least one of the roles is defined in both class and method annotations. As soon as we remove the

Code: Select all

@RolesAllowed({"student, teacher"})
from the class and add:

Code: Select all

@RolesAllowed({"student, teacher", "student"})
the method annotation overrides the class annotation (there is a conflict for "student" role) and Principals in the role of "student" are allowed execute the method.

I guess for both interpretations of the specification there are valid arguments.

To make a long story short: I will change this option.

Regards,
Frits

MichaelZett
Posts: 20
Joined: Wed Dec 10, 2014 8:28 am
Contact:

Re: About Question enthuware.ocejws.v6.2.224 :

Post by MichaelZett » Mon Dec 15, 2014 7:39 am

Thank you very much for your explanation.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests