La pregunta SCBCD del día: Seguridad

(Imagen: Claude Monet -  Mujer en el jardín)

Retomando el blog, después de un prolongado descanso; me propongo a comenzar una seguidilla de preguntas sobre el SCBCD 5 (o sea .. full EJB 3.0), de modo que me mantenga publicando constantemente y de paso me vaya preparando. Ahí va la primera:

**A developer implements a Session Bean with a method doStuff which behaves differently depending on the caller's security role. Only users in security roles "USER" and "ADMIN"  are allowed to call the method. Asume that there is no security related metadata in the deployment descriptor. Which two, taken in combination, are appropiate to acomplish this? (Choose two)

1. Anotate method doStuff with @PermitAll
2. Anotate method doStuff with @RolesAllowed ({"ADMIN", "USER"})
3. If EJBContext.getCallerPrincipal returns "ADMIN", implement the behavior for users in role ADMIN
4. If EJBContext.isCallerInRole ("ADMIN") returns true, implement the behavior for users in role ADMIN
   

A ver, la pregunta establece que sólamente deben acceder al método doStuff (wow... que creativos) los usuario en los roles "USER " y "ADMIN", así que usar la anotación @PermitAll sería un poco contraproducente (cualquier usuario autenticado puede acceder al método, como su nombre lo sugiere).

Por el contrario, mediante la anotación @RolesAllowed ({"ADMIN", "USER"}), establecemos que los roles lógicos que pueden acceder al método son "ADMIN" y "USER". Por ende, la segunda opción iría.

Ahora, debemos hacer que el método se comporte de una u otra manera dependiendo del rol del usuario conectado. Para esto, es bastante conveniente el método isCallerInRole("aqui va el rol") , que nos determina si es que el usuario está asociado al rol que le pasamos como parámetro. Entonces, la cuarta opción también sería seleccionada.

Concluyendo, las correctas serían la segunda y la tercera opción.

PS: Para que no queden dudas, el método getCallerPrincipal  nos devuelve un objeto de tipo javax.security.Principal , que nos representa al usuario que está invocando al EJB, por lo que no devolvería "ADMIN", como sugiere la tercera opción. 

Pregunta tomada de ExamWorx