Seguridad de O3 en LDAP y Active Directory

Esta página explica cómo configurar el Servidor de O3 BI para utilizar un servidor LDAP o Active Directory como soporte para la definición de usuarios y roles, así como manejar la autenticación al sistema.

Se asume que se tienen conocimientos básicos del protocolo LDAP, así como conocimientos de cómo configurar el servidor LDAP o Active Directory que se desea utilizar.

Se presentan algunos ejemplos que deben tomarse simplemente como guía ya que las estructuras de directorios presentadas pueden variar dependiendo del servidor LDAP utilizado.

La seguridad del O3 Server

La seguridad del Servidor de O3 se basa sobre un módulo comúnmente conocido como RBAC (Role Based Access Control).

Este módulo define un conjunto de repositorios que son los encargados de almacenar los diferentes elementos involucrados en la seguridad del servidor - usuarios, roles, atributos, asociaciones entre ellos, etc.

Es posible elegir diferentes implementaciones de estos repositorios de modo que los datos puedan ser leídos desde diferentes servidores y utilizando tecnologías diferentes. 

O3 BI incluye una implementación de este módulo para poder conectarse a servidores de directorio tales como LDAP y Active Directory.

Configurando el Servidor de O3

  1. La elección de qué implementación de los repositorios de RBAC usar, se realiza en el archivo O3Server_custom.properties que se encuentra en la raíz de la instalación de O3 BI. En caso de no existir, crear uno respetando las mayúsculas y minúsculas del nombre.

En este archivo se deben definir un conjunto de properties que permiten indicar el repositorio que debe utilizarse.

En O3Server.properties
#RBAC Repositories Configuration
#rbac.roleRepository         = com.ideasoft.rbac.repository.impl.jndi.JndiRoleRepository
#rbac.userRepository         = com.ideasoft.rbac.repository.impl.jndi.JndiUserRepository
#rbac.raAssignmentRepository = com.ideasoft.rbac.repository.impl.jndi.JndiRAAssignmentRepository
#rbac.loginService           = com.ideasoft.rbac.repository.impl.jndi.JndiLoginService

La distribución de O3 incluye estas properties comentadas en O3Server.properties, tal como puede verse por los caracteres "#" al principio de cada línea. Para poder activar el uso de LDAP o Active Directory es necesario quitar esos caracteres del principio de cada línea de modo que queden de la siguiente forma (es recomendable mantener comentadas estas líneas en el archivo O3Server.properties y agregarlas en el O3Server_custom.properties para una mayor comprensión del manejo de los cambios realizados a la instalación personalizada):

En O3Server_custom.properties
#RBAC Repositories Configuration
rbac.roleRepository         = com.ideasoft.rbac.repository.impl.jndi.JndiRoleRepository
rbac.userRepository         = com.ideasoft.rbac.repository.impl.jndi.JndiUserRepository
rbac.raAssignmentRepository = com.ideasoft.rbac.repository.impl.jndi.JndiRAAssignmentRepository
rbac.loginService           = com.ideasoft.rbac.repository.impl.jndi.JndiLoginService

Si lo único que se desea es validar los usuarios contra LDAP o Active Directory, teniendo los roles definidos en la base de datos de O3, sólo deberá descomentarse las líneas que especifican el rbac.loginService y rbac.userRepository. Si no se habilita el rbac.userRepository todos los usuarios deberán existir tanto en LDAP como en la base de datos de O3.

Tener en cuenta bien el rbac.userRepository que sea  com.ideasoft.rbac.repository.impl.jndi.JndiUserRepository ya que hay otra que es para lectura/escritura


2. Además de habilitar el uso de implementaciones alternativas de los repositorios de RBAC, es necesario configurar una serie de parámetros que cada mecanismo (LDAP o Active Directory) requieren para su correcto funcionamiento.

Estas configuraciones específicas para cada servidor se indican en un archivo adicional que se encuentra en la carpeta <O3>/config/rbac

El nombre del archivo de configuración a utilizar se indica también en el O3Server_custom.properties que puede encontrarse en la raíz de la instalación de O3

jndi.cfg.filename = JndiConfiguration-SunONE.properties

La distribución de O3 incluye dos archivos de ejemplo JndiConfiguration-MS.properties y JndiConfiguration-SunONE.properties para Microsoft Active Directory y SunONE Directory Server respectivamente. Al final de este documento se pueden ver estos ejemplos.

Estos archivos definen los siguientes parámetros:

Parámetro

Descripción

java.naming.provider.url

Indica la ruta al servidor donde se encuentran los repositorios. Esta ruta es de la forma ldap://<host>:<port>

java.naming.factory.initial

Indica el nombre de la clase java que implementa el Contexto Inicial. Este es un parámetro del sistema que no debe cambiarse a menos que se indique lo contrario. El valor por defecto de esta property es "com.sun.jndi.ldap.LdapCtxFactory"

java.naming.security.authentication

Indica el mecanismo de autenticación. Este es un parámetro del sistema que no debe cambiarse a menos que se indique lo contrario. El valor por defecto de esta property es "simple"

browseUserDN

Distinguished Name del usuario que utiliza el sistema para obtener las listas de usuarios, roles, etc.

browseUserPassword.plain

Contraseña del usuario indicado en el parámetro browseUserDN. El valor de esta property se ingresa como texto plano y una vez que el servidor se reinicia ésta es cambiada por la property browseUserPassword cuyo valor será encriptado en forma automática por el servidor

roleDefAttributeID

Nombre del atributo que deben tener las entradas en el directorio que representan roles

roleDefValueAttributeID

Valor que debe tener el atributo roleDefAttributeID para ser considerado un rol

roleNameAttributeID

Atributo que se va a utilizar para recuperar el nombre del rol

roleSearchBaseDN

DN a partir del cual se buscarán los roles

userDefAttributeID

Nombre del atributo que deben tener las entradas en el directorio que representan usuarios

userDefValueAttributeID

Valor que debe tener el atributo userDefAttributeID para ser considerado un usuario

userNameAttributeID

Atributo que se va a utilizar para recuperar el nombre del usuario

userSearchBaseDN

DN a partir del cual se buscarán los usuarios

userRolesAttributeID

Nombre del atributo multivaluado que contiene la lista de los roles que tiene asignado el usuario

(warning) Nota
Para el caso en que la lista de roles indicada por la property userRolesAttributeID sea una lista de DN (Distinguished Name) en lugar de los nombres de los roles directamente, es necesario especificar el atributo dereferenceRoleAttribute, el cual indica el atributo a partir del cual se va a obtener el nombre del rol. En este caso, el valor de dereferenceRoleAttribute y el de roleNameAttributeID deben coincidir para que funcione correctamente la asignación de roles a usuarios.

(warning) Nota: Para que la validación de usuarios sea exitosa es necesario que éstos tengan definidos el atributo "dn" 

(warning) Nota

En caso de que se tenga mas de un path para buscar los usuarios se debe declarar:

 userSearchBaseDN_0 = .....
 userSearchBaseDN_1 = ....


Ejemplos de Archivos de Configuración

Ejemplo de Archivo de configuración para Microsoft Active Directory
#Microsoft - Active Directoy Configuation file

allowEmptyPasswords       = false

java.naming.provider.url  = ldap://dataserver:389
userRolesAttributeID      = memberOf
dereferenceRoleAttribute  = cn

#Browse user's  DN (used to bind to the Directory)

#Option 1: User Principal Name (username@domain)
#browseUserDN             = o3user@radiusserver.ideasoft.com
#browseUserPassword.plain = ????????

#Option 2: DN (Distinguished Name) asumiendo en AD un usuario O3 User
browseUserDN              = CN=O3 User, CN=Users, DC=xxxxxxx,DC=xxx
browseUserPassword.plain  = ????????

#Roles's Entry definition
roleDefAttributeID        = objectclass
roleDefValueAttributeID   = group
roleNameAttributeID       = cn
roleSearchBaseDN          = ou=Roles, dc=radiusserver, dc=ideasoft, dc=com

#User's Entry definition
userDefAttributeID        = objectclass
userDefValueAttributeID   = user
userNameAttributeID       = sAMAccountName
userSearchBaseDN          = cn=Users, dc=xxxxxxxx, dc=xxx
Ejemplo de Archivo de configuración para SunONE Directory Server
#Sun ONE Directory Server Configuation file

java.naming.provider.url  = ldap://dataserver:51685
userRolesAttributeID      = nsrole
dereferenceRoleAttribute  = cn

#Browse user's  DN (used to bind to the Directory)
browseUserDN              = uid=admin, cn=directory administrators, dc=ideasoft
browseUserPassword.plain  = ????????

#Roles's Entry definition
roleDefAttributeID        = objectclass
roleDefValueAttributeID   = ldapsubentry
roleNameAttributeID       = cn
roleSearchBaseDN          = ou=People, dc=ideasoft

#User's Entry definition
userDefAttributeID        = objectclass
userDefValueAttributeID   = person
userNameAttributeID       = uid
userSearchBaseDN          = ou=People, dc=ideasoft
Ejemplo de Archivo de configuración para Apache DS
java.naming.provider.url    = ldap://localhost:10389
userRolesAttributeID        = memberOf

#Browse user's  DN (used to bind to the Directory)
browseUserDN                = uid=admin,ou=users,o=ideasoft,dc=ideasoft,dc=com
browseUserPassword.plain    = ????????
 
#Role's Entry definition
roleDefAttributeID          = objectclass
roleDefValueAttributeID     = group
roleNameAttributeID         = cn
roleSearchBaseDN            = ou=Roles, o=ideasoft, dc=ideasoft, dc=com

#User's Entry definition
userDefAttributeID          = objectClass
userDefValueAttributeID     = person
uderNameAttributeIs         = uid
userSearchBaseDN            = ou=users,o=ideasoft,dc=ideasoft,dc=com
Ejemplo de Archivo de configuración para Open Ldap
java.naming.provider.url               = ldap://localhost:389
#userRolesAttributeID                  = nsrole
#dereferenceRoleAttribute              = cn

#Browse user's  DN (used to bind to the Directory)
browseUserDN 						   = cn=o3,ou=usuarios,dc=ids,dc=com,dc=uy
browseUserPassword.plain			   = ????????

#Roles's Entry definition
roleDefAttributeID                     = objectclass
roleDefValueAttributeID                = ldapsubentry
roleNameAttributeID                    = cn
roleSearchBaseDN                       = ou=grupos,dc=ids,dc=com,dc=uy 

#User's Entry definition
userDefAttributeID                     = objectclass
userDefValueAttributeID                = person
userNameAttributeID                    = uid 
userSearchBaseDN                       = ou=usuarios,dc=ids,dc=com,dc=uy 


3. Modificar usuario internal

El nuevo usuario deberá estar asociado al rol System y tener definido como atributo runAsEnabled de tipo Boolean con valor TRUE.

En <o3>\O3Server.properties modificar:

rest.user=internal
rest.pass=internal

En <o3>\Portlets.properties, modificar:

gclient.runas.user = internal
gclient.runas.password = internal

En <o3>\liferay\tomcat\webapps\o3-parts-web\WEB-INF\classes\portlets-config\portlets-config.properties, modificar:

adminUser=internal
adminPass=internal

En <o3>\jboss\standalone\deployments\o3report.war\WEB-INF\webapp.properties, modificar:

gclient.runas.user = internal
gclient.runas.password = internal

En <o3>IdeaSoft\o3bi\jboss\standalone\configuration\O3bi-xml

<module-option name="rbac.rest.user" value="internal"/>
<module-option name="rbac.rest.pass" value="internal"/>
 

Nota: Esta repetido dos veces, hay que cambiarlo en ambos lados del authentication


Configuración de Liferay con LDAP y CAS

Por defecto Liferay viene configurado para autentificar con CAS. Si configuramos O3 para que autentifique contra un LDAP o AD, puede interesarnos que los datos de los usuario se importen del LDAP en forma automática, o que todo usuario autorizado por O3 se le cree la cuenta en forma automática en Liferay

Hacer que Liferay tome los datos del LDAP

  1. Debemos ir a Panel de Control, seleccionar la opción Configuraciones y luego Autenticación.
  2. En el tab General configurar para que el método de autenticación de usuarios sea Por nombre de usuario
  3. Luego seleccionamos el tab LDAP, esto es para todo tipo de LDAP incluso Activi Directory.
  4. Verificar que Habilitado y Requerido no estén chequeados.
  5. Elegir en Valores por defecto el LDAP de nuestra preferencia. y luego apretar el botón Restaurar valores, esto hará que se precarguen valores en los campos siguientes.
  6. Debemos completar los datos de conexión, si todo está correcto al apretar el botón de Probar la conexión a LDAP deberia mostrarnos una pantalla diciendo que se ha establecido la conexión con éxito con el servidor LDAP.
Configuración de usuarios
  1. Esta es la parte más delicada de la configuración, se debe configurar correctamente el Filtro de búsqueda para autenticación para que Liferay encuentre el usuario que se quiere loguear. Por defecto el filtro queda configurado con @user_id@ que deberá ser sustituido por @screen_name@, el resto del filtro se debe dejar tal como está. Los demás campos en general quedan bien, revisar el campo Nombre de usuario, debería coincidir con lo que igualamos @screen_name@
  2. Probamos con el botón de Probar la configuración de usuarios LDAP, si todo está bien nos mostrara una pantalla con los primeros usuarios del LDAP
  3. (minus) Atención: ver bien esta pantalla no implica que el Filtro de búsqueda para autenticación haya sido bien configurado. Si el filtro quedó mal sucederá que no importara los usuarios.
Configuración de CAS
  1. En el tab CAS le diremos a Liferay como autenticarse.
  2. Es obligatorio que el checkbox Habilitado este chequeado.
  3. Si queremos que los datos de los usuarios se importen del LDAP debemos chequear Importación de LDAP.
  4. El resto de los campos deben dejarse tal como están. (warning) Atención, cambios en estos campos pueden llevar a no poder loguearse a liferay, se recomienda consultar antes de modificarlos.
Últimos pasos
  1. Luego que configuramos todo solo resta apretar el botón de salvar para persistir los cambios.
  2. Podemos ir al link de Asociaciones por defecto de los usuarios y hacer que todo usuario que se crea por defecto pertenezca  a una comunidad y que tenga determinados roles.
Ejemplo de configuración para Microsoft Active Directory

Problemas

  1.  O3 no autentica contra el LDAP
    Se puede revisar el log del servidor y ver se hay algún error inmediatamente de habernos intentado loguear. Estudiar si es problema de credenciales del usuario, del usuario que accede al ldap para obtener datos, mal el DN base.
  2. Liferay no auntentica contra el LDAP
    Revisar que el filtro sea correcto, usualmente en el log se ve que no encuentra al usuario.
  3. No importa los datos de los usuario
    Esto se pude deber a que el filtro está mal y no lo encuentra.
    También se pude deber a que faltan datos obligatorios en el LDAP, por ejemplo la casilla de correo, o el apellido, etc. Ver datos necesarios en la parte de usuarios.