JSF: ¿cómo controlar el acceso y los derechos en JSF?

Me gustaría controlar el acceso después de que el usuario inicie sesión en mi sistema.

Por ejemplo:

administrator : can add, delete and give rights to employee employee : fill forms only ... 

Entonces, después de saber qué derecho tiene el usuario, al registrar la base de datos, me gustaría restringir lo que este usuario puede ver y hacer. Hay una manera simple de hacer eso?

EDITAR

 @WebFilter("/integra/user/*") public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException { HttpServletRequest req = (HttpServletRequest) request; Authorization authorization = (Authorization) req.getSession().getAttribute("authorization"); if (authorization != null && authorization.isLoggedIn()) { // User is logged in, so just continue request. chain.doFilter(request, response); } else { // User is not logged in, so redirect to index. HttpServletResponse res = (HttpServletResponse) response; res.sendRedirect(req.getContextPath() + "/integra/login.xhtml"); } } // You need to override init() and destroy() as well, but they can be kept empty. @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void destroy() { } } 

Bueno, este es un tema bastante amplio. Como está comenzando con la autenticación de elaboración casera, apuntaré a la respuesta sobre autorización casera.


La verificación de roles en Java / JSF es relativamente simple si el modelo está diseñado con sensatez. Asumiendo que un solo usuario puede tener múltiples roles (como suele ser el caso en las aplicaciones del mundo real), en última instancia, te gustaría terminar teniendo algo como:

 public class User { private List roles; // ... public boolean hasRole(Role role) { return roles.contains(role); } } 
 public enum Role { EMPLOYEE, MANAGER, ADMIN; } 

para que pueda verificarlo de la siguiente manera en sus vistas JSF:

    
  

y en tu filtro:

 String path = req.getRequestURI().substring(req.getContextPath().length()); if (path.startsWith("/integra/user/admin/") && !user.hasRole(Role.ADMIN)) { res.sendError(HttpServletResponse.SC_UNAUTHORIZED); } 

La parte más difícil es traducir este modelo de Java a un modelo de base de datos sane. Hay varias maneras diferentes que dependen de los requisitos comerciales concretos, cada uno con sus (des) ventajas. ¿O tal vez ya tiene un modelo de base de datos en el que tiene que basar su modelo de Java (por lo tanto, debe diseñar de abajo hacia arriba)?

De todos modos, suponiendo que esté utilizando JPA 2.0 (al menos su historial de preguntas lo confirma) y que puede diseñar de arriba hacia abajo, una de las maneras más sencillas sería asignar la propiedad de roles como @ElementCollection a una tabla user_roles . Como estamos usando una enumeración de Role , no es necesaria una segunda tabla de role . De nuevo, eso depende de los requisitos funcionales y comerciales concretos.

En términos generics de SQL, la tabla user_roles puede verse así:

 CREATE TABLE user_roles ( user_id BIGINT REFERENCES user(id), role VARCHAR(16) NOT NULL, PRIMARY KEY(user_id, role) ) 

Que se debe mapear de la siguiente manera:

 @ElementCollection(targetClass=Role.class, fetch=FetchType.EAGER) @Enumerated(EnumType.STRING) @CollectionTable(name="user_roles", joinColumns={@JoinColumn(name="user_id")}) @Column(name="role") private List roles; 

Eso es básicamente todo lo que necesitarías cambiar en tu entidad de User .


Junto a la autenticación de j_security_check HttpServletRequest#login() (inicio de sesión / cierre de sesión) y la autorización (comprobación de j_security_check ), también hay autenticación administrada de contenedor proporcionada por Java EE con la que puede iniciar sesión mediante j_security_check o HttpServletRequest#login() , filtrar las solicitudes HTTP por en web.xml , compruebe el usuario registrado por #{request.remoteUser} y sus roles mediante #{request.isUserInRole('ADMIN')} , etc.

Luego hay varios frameworks de terceros como PicketLink , Spring Security , Apache Shiro , etc. Pero todo esto está fuera de cuestión 🙂

Intereting Posts