Segunda SCBCD del día: RunAs y RollesAllowed

(Imagen: Henri Matisse - La Danza)

Given:

10. @Stateless

11. @RunAS("X")

12. public class SecureBean01 implements Secure01{

13. @EJB Secure02 secure02;

23. @RolesAllowed("A")

24. public void methodA(){

25. secure02.methodB();

26. }

}

10. @Stateless

11. public void SecureBean02 implements Secure02{

23. @RolesAllowed("A")

24. public void methodB(){

}

}

A user who us only in role A invokes Secure01.methodA. Assuming NO other security-related metadata, what is the expected result?

• An exception is thrown at Line 25
  
• An exception is thrown at Line 13
  
• methodA cannot be invoked by this user
  
• The code executes without raising an exception

Es posible especificar un rol runAs para un EJB como hemos hecho para nuestra instancia de SecureBean1. Mientras que con la anotación @RollesAllowed y los elementos especificamos que roles pueden acceder a los métodos del bean (por lo que el usuario de rol A puede acceder a method A, descartando la tercera), la anotación runAs especifica el rol bajo el cual el método se va a ejecutar. En cristiano, el rol runAs es utilizado como la identidad del EJB cuando trata de ejecutar métodos en otros beans,  y esta identidad no es necesariamente la misma que está accediendo al bean.

Recapitulando, nuestro usuario accede al método methodA dado que mediante RolesAllowed se le ha dado acceso al rol "A". Ahora, dentro de methodA el bean asume el rol "X", debido a RunAs y con ese rol intentamos ejecutar methodB en SecureBean02. Pero methodB solo permite el acceso a usuarios con el rol "A" (mediante RolesAllowed), por lo que no se permite el acceso a methodB, y una excepción es lanzada en la línea 25.

Entonces, nuestra respuesta es la primera.

Pregunta tomada de ExamWorx