RBAC no es RBAC no es RBAC y RBAC en papel es difícil, pero casi imposible de implementar en la vida real.
Todos tienen su propia "idea" de RBAC y casi todos usan diferentes términos para cada cosa asociada con RBAC. En general, desde una perspectiva de implementación de LDAP, rara vez tiene todas las "partes de piezas" para realizar una implementación adecuada dentro de LDAP.
las "piezas partes" en términos simples son:
S = subject = Una persona o agente automatizado o usuarios
P = Permisos = Una aprobación de un modo de acceso a un recurso de destino
T = Recursos de destino = El objeto al que desea asignar permisos
El rol, como mínimo, debe asociar un permiso y un usuario. El recurso de destino podría estar fuera de LDAP por completo. Por lo tanto, podría ser una Aplicación en un servidor Tomcat o simplemente el derecho de leer "otras" entradas dentro del Servidor LDAP.
Por lo general, lo mejor que hará dentro de LDAP es configurar un objeto que tenga una lista de usuarios y si hay algunos recursos dentro de LDAP, asigne los permisos de directorio adecuados para esos recursos de destino.
Luego está el pequeño problema de implementación.
Ahora necesitamos una Política para la implementación de nuestra Función. Entonces, nuestro rol, lo llamaremos USER-LECT-SOLAMENTE, no es útil sin una política sobre cómo se debe usar.
En nuestro caso, podríamos decir que el rol de USER-READ-ONLY puede leer cualquier cosa en nuestra organización.
Así que ahora tenemos una política. ¿Dónde está almacenada esta política? La representación digital de una política se almacena en el "Punto de información de política" o PIP.
¿Cómo interpretamos la política suministrada desde el PIP? Las políticas son interpretadas por el Policy Decision Point (PDP).
¿Quién decide si un sujeto (usuario) puede acceder a un recurso? Los puntos de aplicación de políticas (PEP).
Poniendo todo esto la política en conjunto nos encontramos con la representación digital de la política es proporcionada por la política Punto de Información al punto de decisión política que luego pasa a la decisión de la Punto de aplicación de políticas que se permite o se deniega el acceso.
Entonces en nuestra historia RBAC, ¿dónde está el PIP, el PDP y el PEP? Bueno, si el recurso de destino está en el directorio LDAP, entonces es el directorio LDAP el PIP (que probablemente codificamos y no se abstrae, el PIP y el PEP también, y eso fue fácil.
Pero si es nuestra aplicación Tomcat, DEBE ser un método dentro de la aplicación Tomcat que puede interrumpir sabe debe usar un método para decir "Tengo este sujeto (usuario) y quiere acceder a este recurso objetivo (inventario) para realizar este permiso (Read-Only)".
Seguro que hay algunas normas para todas estas cosas. (Google XAML, RFC3198, ISO10181-3, NIST) pero son estándares con grandes brechas para implementaciones prácticas.
Tenga en cuenta que las implementaciones REALES de RBAC son difíciles.
Seguro En mi humilde opinión, debemos conocer RBAC, estudiar los documentos y convertirlo en una dirección estratégica, pero la implementación de la vida real a través de una amplia base de proveedores y aplicaciones, bueno, todavía no lo hemos logrado.
-Jim
Curioso: ¿por qué el voto negativo sin siquiera un comentario? Esta parecía ser una pregunta relevante cuando lo pregunté hace tres años ... Particularmente para el proyecto en el que estaba trabajando en ese momento. –
Como OP, veo que esto es un duplicado de [Implementación de seguridad basada en roles en LDAP] (http://stackoverflow.com/questions/8020237/role-based-security-implementation-in-ldap) que en realidad tiene alguna guía útil. –
Y en la última actualización: descubro que el control de acceso basado en notificaciones en .Net es un buen mecanismo, y ADFS parece razonablemente capaz como un mecanismo para ordenar reclamos de una base de datos de aplicaciones en la estructura de autenticación/autorización. –