Clasificación de atributos de OID y estructura del Directorio.
Tabla de contenidos
- 1. Descripción
- 1.1. Estructura de datos del Directorio
- 1.2. Organización del Directorio
- 1.3. Ramas principales
- 1.4. Atributos
- 1.5. Índices
- 1.6. Listado de Atributos de la Rama de Identidades
- 1.7. Listado de Atributos de la Rama de Grupos Organizativos
- 1.8. Aplicaciones
- 1.9. Comprobaciones de pertenencias a grupos en el Directorio
- Área: GUIA: Gestión Unificada de Identidades de Andalucía
- Carácter del recurso: Recomendado
Descripción
El Directorio OID es una base de datos jerárquica que cumple el estándar LDAP. De esta forma organiza la información en ramas y atributos para su explotación. La información contenida en el proviene de distintas fuentes autoritativas que se enumeran a continuación. Sirhus, Sirhus educación, Gerhonte y Directorio Judicial.
Se desarrolla a continuación la estructura de datos del Directorio concerniente a la integración de aplicaciones para autenticación y autorización en GUIA, por lo que solo se contempla el acceso para lectura. Se asumen conocimientos básicos de LDAP.
Estructura de datos del Directorio
Información del Directorio
La información existente en el Directorio y sus relaciones se muestra en el siguiente diagrama.
Implementación de la Estructura de Datos en el Diretorio
El directorio es una base de datos jerárquica que sigue el estándar LDAP. La información del esquema anterior se refleja en el Directorio por medio de entradas y atributos. Las relaciones en el Directorio se corresponden a atributos que contienen la ubicación física de otra entrada (Dn).
Tanto en el caso de los grupos de trabajo como para las unidades organizativas operativas se ha implementado en el Directorio como dos grupos distintos. Uno es el grupo que contiene los miembros de dicho grupo de trabajo o UOO y otro es el grupo que contiene los responsables de los miembros de dicho grupo. Ambos grupos de responsables y miembros se encuentran en ramas distintas, pero tienen el mismo identificador, atributo cn, que permite relacionarlos.
En el caso de los atributos, una aplicación tiene un conjunto de atributos propios. Existen también atributos globales que no pertenecen a ninguna aplicación concreta.
Organización del Directorio
Estructura física
Como ya se ha dicho OID organiza la información de forma jerárquica, en ramas y entradas, estas a su vez contienen atributos.
En un primer nivel se tienen dos tipos distintos de ramas. Una rama común con la información horizontal de la Junta de Andalucía y una rama por cada organismo que contendrá la información sobre este.
La estructura completa del Directorio se puede ver en la siguiente ilustración. Sobre ella vemos todas las ramas principales que contiene el directorio.
Ramas principales
Personas (o=personas,o=identidades,o=comun)
Esta rama contendrá entradas pertenecientes a personas físicas. Esta rama se encuentra sólo bajo la rama común.
Servicios (o=servicios,o=identidades,o=<organismo>)
Esta rama contendrá entradas para aplicaciones y sistemas de información que necesiten trabajar con el Directorio Corporativo. Los usuarios para la conexión con OID a través de los Servicios Web se encuentran aquí.
Entidades (o=entidades,o=comun)
La rama entidades contendrá la estructura organizativa de la Junta de Andalucía clasificada por cada fuente autoritativa (Sirhus, Sirhus Educación, Gerhonte, Directorio Judicial).
Grupos organizativos (o=gruposorganizativos,o=<organismo>)
Aquí se encuentran los grupos de usuarios a nivel organizativo como los grupos de unidades organizativas operativas (UOO). Se detectan los grupos o=responsablesuoo y o=identidadesuoo que contienen respectivamente los grupos de responsables de UOO y los grupos con las identidades de los UOO.
Las estructura completa de esta rama es:
- responsables: se encuentran los grupos de actores de los casos de uso
- acl: los grupos para la gestión de permisos
- identidadesuoo: grupos de miembros de UOO
- responsablesuoo: grupos de responsables de UOO
- identidadesgr: otro posibles grupos
- responsablesgr: responsables de otros posibles grupos
Por ejemplo, la información de los usuarios miembros y responsables de una unidad operativa denominada CONSEJ1.UO1 perteneciente al organismo consej1 se encontrarían en las dos siguientes ramas:
- cn=CONSEJ1.UO1,o=identidadesuoo, o=gruposorganizativos, o=consej1, dc=juntadeandalucia,dc=es
- cn=CONSEJ1.UO1,o=responsablesuoo, o=gruposorganizativos, o=consej1, dc=juntadeandalucia,dc=es
Siguiendo con el ejemplo y de manera análoga, la información de los usuarios miembros y responsables de un grupo de trabajo denominado CONSEJ1.GR1 perteneciente al organismo consej1 se encontrarían en las dos siguientes ramas:
- cn=CONSEJ1.GR1,o=identidadesgr, o=gruposorganizativos, o=consej1, dc=juntadeandalucia,dc=es
- cn=CONSEJ1.GR1,o=responsablesgr, o=gruposorganizativos, o=consej1, dc=juntadeandalucia,dc=es
Aplicaciones (o=aplicaciones,o= y o=aplicaciones,o=comun)
La rama de aplicaciones del OID contendrá información referente a la configuración de las mismas
Atributos
Cada entrada del Directorio tiene una serie de atributos que usa para almacenar la información.
Los atributos que puede tener una entrada están a su vez especificados en otros atributos. Estos atributos se llaman objectclass. De esta forma los objectclass que posea una entrada nos indica que tipos de atributos soporta esta.
Existen objectclass en el estándar LDAP que son usados en GUIA. Aparte GUIA define otros objectclass que son usados en el Directorio.
Índices
Los índices se definen para aumentar el rendimiento del directorio en las tareas de búsqueda. Estas búsquedas se utilizan tanto para localizar una entrada como para incluir una entrada dentro de un grupo dinámico. En las tablas de atributos se identifican aquellos que son índices.
Listado de Atributos de la Rama de Identidades
A continuación se van a listar todos los atributos que se tienen actualmente en el sistema, en la rama de identidades. De cada atributo se indica su nombre, descripción y si posee o no índice.
Para la explotación de esta información es necesario además conocer la disponibilidad que cada aplicación tendrá para leer o escribir esta información. Los atributos cuya procedencia este marcada como OID serán los que podrán ser modificados por las aplicaciones externas en el Directorio.
Atributos de identidad
| Nombre | Descripción | Indice |
|---|---|---|
| cn | Identificador de la identidad (identificador GUIA) | Si |
| uid | Identificador de usuario, coincide con identificador de correo corporativo | Si |
| givenName | Nombre de la identidad | Si |
| sn | Primer apellido de la identidad | Si |
| sn2 | Segundo apellido de la identidad | Si |
| orclGender | Género de la identidad [M, F] | No |
| Correo electrónico de la identidad | Si | |
| telephoneNumber | Número de teléfono del puesto de la identidad | Si |
| homePhone | Teléfono alternativo de contacto para la identidad no es obligatorio | Si |
| mobile | Teléfono movil corporativo de la identidad | Si |
| displayName | Nombre completo de la identidad Nombre y apellidos | |
| orgOIM | Nombre de la Organización OIM responsable de la identidad | Si |
| tipoIdentidad employeeType | Tipo de identidad según procedencia de fuente [...] | No |
| udOrgOp | Unidades organizativas operativas secundarias. Atributo multivaluado | Si |
| udOrgPrinc | Unidad organizativa principal, atributo proveniente de Sirhus. Univaluado | Si |
| orclisEnabled | Indica si la identidad se encuetra desactivada para poder hacer bind al directorio o no [true, false] | Si |
| anagramaFiscal | Anagrama fiscal de la identidad | No |
| Password | Contraseña de la identidad | No |
| numDoc | Valor del documento de la identidad (NIE o NIF) | No |
| tipoDoc | Índica si el documento es NIE o NIF [1, 2] | No |
| codigoSirhus | Código sirhus de la identidad | No |
| codigoConsejeria | Código de la Consejeria responsable de la identidad | No |
| codigoCentroDir | Código del Centro Directivo de la identidad | No |
| codigoCentroDes | Código del Centro de Destino de la identidad | No |
| codigoUnidadFuncional | Código de la unidad funcional de la identidad | No |
| codigoPuestoSirhus | Código del puesto en sirhus modificable sólo por fuente | No |
| grId | Grupos de trabajo a los que pertenece la identidad | Si |
| grResp | Grupos de trabajo que administra la identidad | Si |
| uooResp | UO que administra la identidad | Si |
Atributos de Cuenta de Servicio
| Nombre | Descripción | Indice |
| cn | Identificador cuenta de servicio | Si |
| userPassword | Password de la cuenta de servicio | No |
| description | Descripción que debe incluir información sobre la responsabilidad de gestión de la entrada | Si |
| orclisEnabled | Identifica si la cuenta puede hacer bind al directorio o no | Si |
| Correo electronico de contacto para la cuenta de servicio | Si | |
| businessCategory | Sirve para los usuarios de api de directorio indicando el tipo de usuario de cara a API de directorio | No |
| politicas | String. Atributo multivaluado que contendrá las políticas aplicadas a esta cuenta de servicio | No |
Listado de Atributos de la Rama de Grupos Organizativos
Los grupos organizativos son objetos con el objectclass “groupOfUniqueNames”. Estos grupos contienen un atributo uniqueMember con todos los miembros del grupo. Tenemos dos clases de grupos *Grupos de Trabajo *Unidades Operativas Cada grupo a su vez se descompone en dos grupos en el Directorio, un grupo con los responsables del grupo y otro con los miembros. La rama de gruposorganizativos en el Directorio está organizada de la siguiente manera:
o=gruposorganizativos
o=identidadesuoo
cn=Unidad_Operativa1
o=responsablesuoo
cn=Unidad_Operativa1
o=identidadesgr
cn=Grupo_Trabajo1
o=resposnablesgr
cn=Grupo_Trabajo1
Y los atributos de cada grupo son los siguientes:
| Nombre | Descripción | Indice |
| uniqueMember | Miembros del grupo | Si |
| labeleduri | Regla dinámica de grupo | No |
| telephoneNumber | Número de teléfono asociado al grupo | Si |
| Dirección de correo electrónico asociada al grupo | Si | |
| seeAlso | Utilizamos este atributo para una descripción larga del grupo | No |
| businessCategory | Categoría del grupo | No |
Aplicaciones
Nodos
Dentro de la rama de aplicaciones, la raíz o=aplicaciones es un objeto de tipo “organization”, su único atributo obligatorio es el “o”.
En el siguiente nivel, las ramas de consejerías, de aplicaciones horizontales y de configuración común también serán de tipo “organization”. Al igual que en el caso anterior, el único atributo obligatorio es el “o”.
Atributos
Las aplicaciones pueden usar un tipo de entrada para almacenar la información que estimen necesaria. De este modo existen atributos horizontales comunes a todas las aplicaciones y propios de cada aplicación. Todas estas entradas tienen un objectclass denominado “guiaAtributo”.
| Nombre | Descripción | Indice |
| cn (commonName) | Nombre del atributo | Si |
| valor | Valor del atributo | No |
Roles
Los roles son un conjunto de permisos que usaran las aplicaciones. Los roles serán objetos del tipo “groupOfUniqueNames”. Además se define el objectclass “guiaRol” que tiene otros atributos para las entradas del tipo rol.
Los roles y la asociación entre estos a las identidades no se modificaran directamente en OID sino que será a través de OIM.
| Nombre | Descripción | Indice |
|---|---|---|
| cn (commonName) | Identificador único del rol | Si |
| uniqueMember | Listado de los usuarios que poseen el rol | Si |
| description | Nombre del Rol | Si |
Comprobaciones de pertenencias a grupos en el Directorio
Una vez expuestos los atributos y la estructura, se describe como acceder a ellos para chequear la autorización de un usuario.
Pertenencia a roles de una aplicación
La comprobación más habitual y que en la mayoría de casos bastará para validar un usuario será la pertenencia a los roles de una aplicación.
En primer lugar será necesario saber donde se encuentran registrados los roles de la aplicación en el LDAP para hacer la comprobación. Suponiendo que la aplicación tiene sus roles ubicados en o=miaplicacion,o=aplicaciones,o=comun,dc=juntadeandalucia,dc=es los roles de esta se encontrarán en el subnodo o=roles,o=miaplicación,o=aplicaciones...
La forma de comprobar el usuario será tomar el subnodo o=roles como base de búsqueda, buscar todos los nodos (roles) cuyo atributo uniqueMember contenga el DN completo del usuario a validar y usar la lista de roles obtenida para comprobar los permisos.
MUY IMPORTANTE: Para poblar la lista de roles a partir del resultado de la búsqueda deberá usarse el atributo "description" como nombre de rol. NO DEBE USARSE EL ATRIBUTO CN.
Otra opción de validación sería, siendo el rol a buscar ya conocido, buscar el nodo cuyo atributo "description" coincida con el nombre del rol y buscar el DN del usuario en el atributo uniqueMember de dicho nodo.
Pertenencia a grupos organizativos y unidades operativas
La pertenencia a grupos organizativos se comprueba de forma similar a los roles, aunque sin la precaución de tener que usar otro atributo como nombre de grupo.
Para saber en qué rama buscar, suponiendo los grupos organizativos del organismo CICE, estos se encontrarán en
o=ceic
o=gruposorganizativos
o=identidadesgr
o=ceic.grupo1
o=ceic.grupo2
...
o=responsablesgr
o=ceic.grupo1
o=ceic.grupo2
...
o=identidadesuoo
o=ceic.uoo1
o=ceic.uoo2
...
o=responsablesuoo
o=ceic.uoo1
o=ceic.uoo2
...
Para comprobar si un usuario pertenece a un grupo "ceic.migrupo" no es necesario consultar los dos grupos "ceic.migrupo" ubicados en identidadesgr y responsablesgr. Casi siempre todo usuario que tenga perfil responsable por estar registrado en el grupo bajo o=responsableX pertenecerá también al grupo bajo o=identidadesX. De existir algún caso que no cumpla esto se supondrá que se ha registrado así a propósito. Todo lo dicho se aplica también para unidades operativas.
Según esto, si se desea comprobar si el usuario con DN "cn=usuario1,p=personas,o=identidades,..." pertenece al grupo "ceic.grupo_energias" solo habrá que buscarlo en
o=ceic
o=gruposorganizativos
o=identidadesgr
o=ceic.grupo_energias
Si se desean listar los grupos a los que pertenece, solo habrá que lanzar la búsqueda apropiada desde el nodo padre o=identidadesgr.
Si en cambio lo que se desea es consultar la pertenencia de un usuario como responsable de grupo, entonces en habrá que consultar en
o=ceic
o=gruposorganizativos
o=responsablesgr
o=ceic.grupo_energias
Y análogamente al anterior caso, para listar los grupos de los que el usuario es responsable, la base de búsqueda será o=responsablesgr.
