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
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.
#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):
#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
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 |
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.
Para que la validación de usuarios sea exitosa es necesario que éstos tengan definidos el atributo "dn"
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
Modificar usuario internal
El nuevo usuario deberá estar asociado al rol System y tener definido cómo atributo runAsEnabled de tipo Boolean.
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
Debemos ir a Panel de Control, seleccionar la opción Configuraciones y luego Autenticación.
En el tab General configurar para que el método de autenticación de usuarios sea Por nombre de usuario
Luego seleccionamos el tab LDAP, esto es para todo tipo de LDAP incluso Activi Directory.
Verificar que Habilitado y Requerido no estén chequeados.
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.
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
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 sustituid por @screen_name@, el resto del filtro se debe dejar tal como está. Los demás campos en general queda bien, revisar el campo Nombre de usuario, debería coincidir con lo que igualamos @screen_name@
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
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
En el tab CAS le diremos a Liferay como autenticarse.
Es obligatorio que el checkbox Habilitado este chequeado.
Si queremos que los datos de los usuarios se importen del LDAP debemos chequear Importación de LDAP.
El resto de los campos deben dejarse tal como están. Atención, cambios en estos campos pueden llevar a no poder loguearse a liferay, se recomienda consultar antes de modificarlos.
Últimos pasos
Luego que configuramos todo solo resta apretar el botón de salvar para persistir los cambios.
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
- 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. - Liferay no auntentica contra el LDAP
Revisar que el filtro sea correcto, usualmente en el log se ve que no encuentra al usuario. - 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.