¿El modelo de seguridad Java EE es compatible con ACL?

Question

He utilizado Java EE 6 con Glassfish v3.0.1, y me pregunto si el modelo de seguridad Java EE admite ACL, y si es así, ¿qué tan preciso es?

EDITADO
implemento de seguridad utilizando reino JDBC a través de GlassFish v3, que el reino ante la mirada de ejecución en USUARIO tabla dentro de la base de datos para comprobar la autenticación, mirando el campo password y autorización mirando el campo role . El campo de roles solo contiene 2 ADMINISTRATOR o DESIGNER. Por lo tanto, se trata de un mapa de uno a uno entre el usuario y el rol. A nivel bean gestionado, he implementado este

private Principal getLoggedInUser() 
{ 
    HttpServletRequest request = 
      (HttpServletRequest) FacesContext.getCurrentInstance(). 
       getExternalContext().getRequest(); 
    if(request.isUserInRole("ADMINISTRATORS")){ 
     admin = true; 
    }else{ 
     admin = false; 
    } 
    return request.getUserPrincipal(); 
} 

public boolean isUserNotLogin() 
{ 
    Principal loginUser = getLoggedInUser(); 
    if (loginUser == null) 
    { 
     return true; 
    } 
    return false; 
} 

public String getLoginUserName() 
{ 
    Principal loginUser = getLoggedInUser(); 
    if (loginUser != null) 
    { 
     return loginUser.getName(); 
    } 
    return "None"; 
} 

llamando isUserInRole, puedo determinar si el usuario es admin o no, entonces el JSF render el contenido correctamente. Sin embargo, eso no es lo suficientemente detallado (información de fondo real rápida: hay varios proyectos, un proyecto contiene varios dibujos). Porque si u es un DESIGNER, se puede ver todos los dibujos de todos los proyectos (lo que si sólo quiero tom para trabajar en proyecto A, mientras peter trabajará en proyecto B, Cindy puede supervisados ​​sobre los dos proyectos A y B). Quiero que, en tiempo de ejecución, cuando creo el usuario, pueda establecer específicamente qué proyecto puede ver. ¿Hay alguna manera de lograr esto? NOTA: hay más de dos proyectos, el ejemplo anterior es solo para la demostración.

Answer 1

El modelo de seguridad Java EE autentica un 'Principal' que puede tener uno o más 'Roles'.

En la otra dimensión tiene servicios y recursos que necesitan 'Permisos' configurables o 'Capacidades'.

En la configuración determina qué 'Principales' o 'Roles' tienen qué 'Permisos' o 'Capacidades'.

En otras palabras, sí es compatible con ACL y es tan fino como usted quisiera, pero deberá acostumbrarse a la terminología.

En la respuesta de Vineet es una excelente sugerencia para crear 'roles' por identificación de proyecto. Como las personas deben ser asignadas a proyectos de todos modos, es sencillo agregar a las personas a estos grupos en ese momento. Alternativamente, un script temporizado puede actualizar las membresías del grupo en función de los roles. El último enfoque puede ser preferible, porque es más fácil verificar la seguridad si estas decisiones están en un solo lugar en lugar de dispersas en todo el código de administración.

Como alternativa, puede utilizar roles de "grano grueso", p. diseñador y hacer uso de la base de datos (o la lógica del programa) para restringir las vistas para el usuario conectado

SELECT p.* FROM projects p, assignments a WHERE p.id = a.projectId AND a.finishdate < NOW(); 

o

@Stateless class SomeThing { 

    @Resource SessionContext ctx; 

    @RolesAllowed("DESIGNER") 
    public void doSomething(Project project) { 
     String userName = ctx.getCallerPrincipal.getName(); 

     if (project.getTeamMembers().contains(userName) { 
      // do stuff 
     } 
    } 

} 

Tenga en cuenta que el control de acceso de grano grueso que aquí se ha hecho con una anotación en lugar de código Esto puede mover una gran cantidad de etiquetas repetitivas difíciles de extraer del código y ahorrar mucho tiempo.

Existen características similares para representar páginas web en las que puede representar partes de la pantalla en función del usuario actual que utiliza una etiqueta normalmente.

también porque la seguridad es una preocupación tan amplio alcance, creo que es mejor utilizar las características proporcionadas a conseguir en el contexto de pasar una batería de indicadores booleanos como isAdmin alrededor, ya que rápidamente se convierte en muy desordenado. Aumenta el acoplamiento y es otra cosa que hace que las clases sean más difíciles de probar.

En muchas implementaciones JSF hay etiquetas que pueden ayudar a renderizar cosas opcionales. Aquí es decir, son ejemplos de richfaces y costura:

<!-- richfaces --> 
<rich:panel header="Admin panel" rendered="#{rich:isUserInRole('admin')}"> 
    Very sensitive information 
</rich:panel> 

<!-- seam --> 
<h:commandButton value="edit" rendered="#{isUserInRole['admin']}"/>. 

Here is an article que explican cómo agregarlo a ADF

Answer 2

El modelo de seguridad de Java EE implementos RBAC (Role Based Access Control). Para un programador de Java EE, esto significa que los permisos para acceder a un recurso se pueden otorgar a los usuarios. Los recursos pueden incluir archivos, bases de datos o incluso código. Por lo tanto, es posible no solo restringir el acceso a objetos como archivos y tablas en bases de datos, también es posible restringir el acceso al código ejecutable.

Ahora, los permisos se pueden agrupar en roles que eventualmente se vinculan a usuarios/sujetos. Este es el modelo de seguridad de Java EE en pocas palabras.

Según la descripción de su problema, parece que desea distinguir entre dos proyectos diferentes como dos recursos diferentes y, por lo tanto, tiene dos objetos de permiso separados o dos funciones separadas para dar cuenta de los mismos. Dado que ya tiene roles (más apropiadamente llamados grupos de usuarios) como Administrador, Diseñador, etc. esto no se puede lograr con bastante facilidad en Java EE. La razón es que está distinguiendo el acceso a los recursos a los usuarios en una función, en función de una propiedad adicional del recurso: la identificación del proyecto. Esto técnicamente cae en el área conocida como ABAC (Control de acceso basado en atributos).

Una forma de lograr ABAC en Java EE es llevar las propiedades/atributos otorgados a la función, en el nombre del rol. Por lo tanto, en lugar del siguiente código:

if(request.isUserInRole("DESIGNERS")){ 
    access = true; 
}else{ 
    access = false; 
} 

debe hacer algo como lo siguiente. Tenga en cuenta el carácter ":" utilizado como separador para distinguir el nombre del rol del atributo que lo acompaña.

if(request.isUserInRole("DESIGNERS"+":"+projectId)){ 
    access = true; 
}else{ 
    access = false; 
} 

Por supuesto, no es la parte en la que el módulo de inicio de sesión debe ser modificado (ya sea en la configuración o en el código) para volver roles que contienen identificadores de proyecto, en lugar de los nombres de función de civil. Tenga en cuenta que todos estos cambios sugeridos deben revisarse exhaustivamente en cuanto a los problemas, por ejemplo, uno debe impedir que el carácter separador sea parte de un nombre de rol, de lo contrario, es bastante posible realizar ataques de escalamiento de privilegios.

Si la implementación de lo anterior resulta ser un puñado, podría mirar los sistemas como Shibboleth que proporcionan soporte para ABAC, aunque nunca lo he visto en una aplicación Java EE.