2011-11-05 13 views
7

Estoy trabajando en la implementación de seguridad basada en roles en LDAP y Java. En concreto, tengo los siguientes objetos que tengo que representar en LDAP:Implementación de seguridad basada en roles en LDAP

  • Usuarios
  • Los grupos de sociedades de usuarios - Recursos Humanos, Finanzas, etc.
  • Permisos - DOCUMENT_READ, etc. DOCUMENT_MODIFY
  • Roles - ADMIN, GUEST, etc.

Las funciones son básicamente grupos de permisos y se pueden asignar a un usuario o grupo de usuarios.

Estaba pensando en representarlos en LDAP como folows:

  • Usuarios - clases de persona y uidObject con el atributo userPassword.
  • Grupos de usuarios: clase organizationalUnit, en la que los usuarios están ubicados .
  • Roles - groupOfNames object class.
  • Permisos: no estoy seguro acerca de esta, tal vez también groupOfNames clase.

La idea es tener un acceso rápido de un usuario o un grupo a una lista de funciones que este usuario o grupo tenga. Sé que puedo poner a los usuarios y grupos en los atributos de "miembro" de un rol, pero luego tendré que analizar todos los roles para encontrar cuáles tienen este usuario en la lista. ¿Hay alguna manera de tener algo como el atributo "miembro" en un objeto Persona?

En general, ¿alguien sabe de una buena implementación de seguridad basada en roles en LDAP? No pude encontrar buena documentación o tutoriales sobre este tema. Estoy usando ApacheDS como un servidor LDAP actualmente, pero estoy abierto a sugerencias.

Respuesta

8

Usuarios: inetOrgPerson

Colecciones: organizationalUnit, pero ten cuidado de tratar de replicar su estructura organizativa en el directorio LDAP: esto suele ser un error, ya que las organizaciones cambian y los usuarios se mueven alrededor de la organización. Debe considerar usar el atributo ou.

Roles: organizationalRole. Usé grupos de roles como groupOfUniqueNames, pero eso fue un error, debería haber seguido usando organizationalRole para que los roles sean simplemente recursivos.

Permiso: esto es solo un rol realmente, o un atributo de un rol. Si usa CMA, están definidos en web.xml, no LDAP.

Como dije, no intente hacer que su árbol LDAP refleje su organización. Hazlo espejo su propia organización. Utilizo atributos de múltiples valores cuando sea necesario. Utilizo organizationalUnit principalmente para capas dentro de LDAP, o donde he roto mis reglas anteriormente ;-)

OpenLDAP tiene una superposición de integridad referencial que puede hacer que todo esto sea más directo para usted.

Hay algunos muy buenos consejos sobre la estructura LDAP en El dominio de OpenLDAP por Matt Butcher, y una vista de nivel superior de todo en entendimiento e implementación de LDAP Directory Servicios por Howes et al.

+0

Gracias, lo intentaré. ou atributo es una buena idea. En mi caso, una persona puede pertenecer a más de una unidad organizativa, por lo que no estoy seguro de cuál es mejor: tener múltiples atributos ou o quizás también hacer grupos groupOfNames. – user1031054

+0

@ user1031054 ver las ediciones. – EJP

+0

buen artículo de ldap: http://www.zytrax.com/books/ldap/ – cleverpig

0

Echa un vistazo a Fortress. Cumple con ANSI RBAC INCITS 359 y está basado en LDAP. El código fuente es de código abierto y puede desplegar binarios preconstruidos que incluyen OpenLDAP desde aquí: http://iamfortress.org/

2

Una opción más: verifique el control de acceso basado en atributos (). ABAC es una evolución de RBAC. Utiliza atributos (que son etiquetas sobre el usuario, el recurso, el contexto) y políticas para determinar qué está permitido y qué no.

Ejemplo: Un usuario con el rol == administrador en el departamento == ventas puede hacer la acción == editar en un documento de tipo == orden de compra si la cantidad del pedido < = límite de aprobación del usuario.

Puede leer más sobre ABAC en el NIST website.

Cuestiones relacionadas