Subsistemas de autenticacion extendidos en Alfresco, LDAP compatible con CIFS

En la terminología de Alfresco, un susbsistema es un módulo configurable y responsable de una subparte de la funcionalidad de Alfresco, lo cual engloba áreas funcionales como los servidores de ficheros, la autenticación, la sincronización o la replicación. Están disponibles como core del producto desde la version 3.2 del producto y cada subsistema puede iniciarse, pararse (via JMX por ejemplo) y configurarse independientemente con su configuración aislada en su contexto de Spring.

Las diferentes categorías y tipos de subsistemas por defecto se pueden consultar en:

$ALF_PATH/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/<category>/<type>

en donde generalmente se definen el fichero de contexto de Spring y sus correspondientes archivos de properties.

Una categoría importante de subsistemas son aquellos que se refieren a la autenticación, como stack de componentes de la cadena de autenticación del servidor Alfresco. Alfresco ofrece numerosas alternativas por defecto, que comentaremos a continuación,

  •  alfrescoNtlm: Autenticación nativa de Alfresco
  •  ldap: Autenticación y exportación de usuarios via protocolo LDAP (e.g. OpenLDAP)
  •  ldap-ad: Autenticación y exportación de usuarios desde un Active Directoy via protocolo LDAP
  •  passthru: Autenticación a través de un servidor de dominio de Windows
  •  kerberos: Autenticación via Kerberos Realm
  •  external: Autenticación via un sistema de SSO (e.g. CAS)

con las cuales uno puede configurar un cadena de autenticación a medida para los usuarios de una organización.

Hay que tener en cuenta, que la exportación de los usuarios sólo es posible a través de los subsistemas ldap y ldap-ad, que el protocolo CIFS únicamente se soporta con los subsistemas alfrescoNtlm, passthru y kerberos, y que el SSO de usuarios está disponible a través de kerberos, passthu y external.

Esto implica en la práctica considerar diferentes cadenas de autenticación en el alfresco-global.properties para contemplar un escenario como este:

  • Los usuarios nativos de Alfresco y usuarios de Windows podrán loguearse, con preferencia los usuarios de Windows.
  • El servidor de dominio de Windows además gestionará la autenticación en unidades de red compartidas via CIFS directamente
  • El LDAP de directorio activo se utilizará para sincronizar usuarios y grupos
  • Tendremos un SSO de credenciales de red (NTLM v.1) con los usuarios del dominio, con lo cual los usuarios de Windows no necesitarán loguearse en Alfresco, si sus navegadores marcan el servidor como sitio de confianza.

chain.authentication=alfrescoNtlm1:alfrescoNtlm,passthru1:passthru,ldap1:ldap-ad

donde hay propiedades específicas como:

alfrescoNtlm1
    ntlm.authentication.sso.enabled=false
    alfresco.authentication.authenticateCIFS=false
passthru1
    ntlm.authentication.sso.enabled=true
    passthru.authentication.authenticateCIFS=true
ldap1
    ldap.authentication.active=false
    ldap.synchronization.active=true

Además, existen otras situaciones, como utilizar un sistema externo de SSO, como CAS, o bien conectarse a varios servidores LDAP o servidores de directorio, por ejemplo, para contemplar a los usuarios externos de una organización (y no incluirlos en el directorio corporativo).

En nuestro caso particular, tenemos un servidor OpenLDAP con el que trabajamos en zylk.net y una de las problemáticas encontradas es que no podemos utilizar por defecto, unidades CIFS/SAMBA para acceder a los documentos corporativos de nuestro gestor documental Alfresco. Esto lo hemos solventado, extendiendo un subsistema de autenticación ldapSamba que permite validar a nuestros usuarios del LDAP via CIFS, con un atributo de nuestro LDAP. La clave de la validación de un subsistema de autenticación con CIFS, es que la password original debe estar codificada con MD4 (UTF16LE), y esto es posible guardarlo en un esquema de usuarios Samba para LDAP. De este modo, una vez implementado el subsistema, empaquetado en su jar correspondiente y desplegado el directorio lib de Alfresco, en el alfresco-global.properties tendremos:

#
# Chain Authentication
#

authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap1:ldap,ldapSamba1:ldapSamba


Y su correspondiente configuración en el directorio extension de shared:

zylk@alf:/opt/alfresco34/tomcat/shared/classes/alfresco/extension/subsystems$ tree
.
└── Authentication
    ├── jdbc
    │   └── myjdbc
    │       ├── jdbc-authentication-context.xml
    │       └── jdbc-authentication.properties
    └── ldapSamba
        └── ldapSamba1
            ├── ldap-samba-account-authentication-context.xml
            └── ldap-samba-account-authentication.properties


donde definimos el archivo de contexto del subsistema y sus propiedades:

ldap.samba.authentication.java.naming.provider.url=ldap://ldap-alf.zylk.net:389
ldap.samba.authentication.base=dc=zylk,dc=net
ldap.samba.authentication.userbase=ou=People
ldap.samba.java.naming.security.principal=cn=administrator,dc=zylk,dc=net
ldap.samba.java.naming.security.credentials=secret
ldap.samba.authentication.authenticateCIFS=true
ldap.samba.authentication.allowGuestLogin=false

No dejo aquí detalles del código fuente del subsistema, que dejaremos para otra ocasión, pero aprovecho para comentar otro de los subsistemas de autenticación que hemos implementado recientemente. Este subsistema permite autenticar a los usuarios de Alfresco contra una tabla de usuarios a medida de un esquema de base de datos via JDBC, lo que es tremendamente util, porque nos permite integrar fácilmente los usuarios de Alfresco con cualquier aplicación de terceros que se autentique contra una base de datos relacional, y que por ejemplo quiera integrarse con Alfresco via repositorio CMIS. Lo comentaremos en un próximo artículo.

Enlaces:

00

Más entradas de blog

Añadir comentarios