En muchas ocasiones usamos JSF como framework de capa de presentación y normalmente JAAS nos cubre nuestras necesidades de seguridad básicas. Ahora bien hay situaciones que tienen tratamientos especiales. Una de ellas es cuando queremos controlar la seguridad no a nivel de carpeta sino a nivel de página ya que disponemos de un recurso que dos roles comparten.
En este caso podemos encontrarnos con la situación de que cada uno de los roles tiene que ver una información distinta de la página . Por ejemplo en el caso de usar un DataTable un rol ve solo un subconjunto de columnas mientras que el otro rol ve todo.
En esta casuística podemos proteger el recurso para que los dos roles tengan acceso via web.xml .
<security-constraint> <web-resource-collection> <web-resource-name>comun</web-resource-name> <url-pattern> *.xhtml </url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>ROLEA</role-name> <role-name>ROLEB</role-name> </auth-constraint> </security-constraint>
Ahora bien eso no impedirá a los dos roles acceder a la información de la tabla de la misma manera. Si nosotros deseamos limitar el acceso a esta información. Deberemos apoyarnos en los atributos rendered que vimos hace unos post y en las capacidades que tiene JSF 2 y Expression languaje para invocar métodos desde páginas JSF.
<h:dataTable value="#{beanFactura.listaFacturas}" var="factura">
<h:column>
#{factura.concepto}
</h:column>
<h:column rendered="#{request.isUserInRole('ROLEA')}">
#{factura.importe}
</h:column>
</h:dataTable>
De esta forma el usuario con el ROLE A verá la tabla completa.
Mientras que el usuario con el ROLE B verá
Buenas, una consulta.
Imaginen que se está utilizando una base de datos con permisos (arquitectura RBAC).
Si disponemos de métodos del tipo isAllowed(Rol rol, Permiso permiso), ¿a qué nivel sería conveniente el uso del filtro de seguridad: en los propios métodos CRUD (acción final), en la vista (bloqueando los botones de acción) o en ambos casos?
Saludos!
Yo optaría por ambos casos ya que lo otro obliga al usuario a realizar muchas operaciones para las cuales igual luego no tiene permisos
Hola y gracias por el aporte cómo haría en jsf para que si un usario no se auténtico no le deje pasar a otras urls. Gracias de antemano
eso no lo harías con jsf lo harias con JAAS https://www.arquitecturajava.com/seguridad-y-jaas/
Saludos …Soy novato con los temas de programación web y hace rato andaba buscando algo así, lo que no podido entender es el código que esta adentro del metodo request.isUserInRole(‘ROLEA’) cuando se le envía el parámetro, no he podido encontrar como hace las validaciones con el web.xml, de casualidad tienes un post donde expliques este método o podrías suministrar un ejemplo por medio de este post, la verdad seria de infinita utilidad, muchas gracias por tus post’s estan ree buenos… saludos
Ese código es expressión languaje de JSTL y simplemente imprime los valores que tienes almacenados en factura
Cordial saludo Cecilio,
Muy bueno el post, quisiera saber si quisiera aplicar esta validación a un menú, que configuración adicional debería llevar en el ??
Disculpas, en el security-constraint ?
no en el security constrains no haría falta mas
En principio se puede aplicar a cualquier control de JSF que soporte el atributo
Muchas gracias por la información, sera de gran utilidad.
De nada 🙂
Excelente post
gracias 🙂
Buenos dias, por favor podrías hablar algo sobre spring security y ACL
Intentare en proximos articulos cubrir algún tema de spring
Saludos. Ya he trabajado con Java y ahora estoy empezando con JEE. El blog me parece una tremenda iniciativa que agradezco porque no soy un autodidacta muy bueno que digamos, pero, estos posts y principalmente el libro de arquitectura java me estan siendo utiles en mis inicios en JEE.