Autenticación única (Single Sign On - SSO) en Windows

4D Server le permite implementar funcionalidades SSO (Single Sign On) en soluciones cliente-servidor en Windows.

La implementación de SSO en sus soluciones 4D permitirá a los usuarios acceder a la aplicación 4D en Windows sin tener que volver a introducir su contraseña cuando ya están registrados en el dominio Windows de su empresa (utilizando Active Directory). Detrás, la aplicación 4D Server puede tener acceso a la autenticación de inicio de sesión de Windows, que se puede utilizar para iniciar la sesión del usuario 4D
en la base utilizando el método de inicio de sesión estándar.

Nota: para una descripción general de las demás funcionalidades de copia de autenticación y seguridad de 4D, consulte la guía de seguridad de 4D.

La funcionalidad SSO está disponible:

• con aplicaciones 4D Server en Windows (las aplicaciones mono usuario 4D no soportan SSO)
• con la capa de red ServerNet activada. Para más información, consulte el párrafo Nueva capa de red ServerNet (compatibilidad).

Por defecto, la funcionalidad SSO no está habilitada en 4D Server. Para beneficiarse de esta funcionalidad, es necesario establecer la opción Autenticación de usuario con el servidor de dominio en la página Cliente-servidor/Opciones de red del diálogo Propiedades de la base de 4D Server:

Cuando selecciona esta opción, 4D se conecta de forma transparente al directorio Active del servidor dominio de Windows y obtiene los tokens de autenticación disponibles.

Esta opción ofrece autenticación estándar a través del protocolo NTLM. 4D soporta los protocolos NTLM y Kerberos. El protocolo utilizado es seleccionado automáticamente por 4D en función de la configuración actual (ver Configuraciones soportadas). Si desea utilizar el protocolo Kerberos, es necesario llenar el campo SPN adicional (ver más adelante).

Si desea utilizar Kerberos como protocolo de autenticación, también es necesario llenar el campo Nombre principal de servicio en la página Cliente-Servidor/Opciones de red del cuadro de diálogo Propiedades de la base:

Esta opción declara el SPN tal como se establece en la configuración Active Directory. Un nombre principal de servicio es un identificador único de una instancia de servicio. Los SPNs son utilizados por la autenticación Kerberos para asociar una instancia de servicio con una cuenta de servicio de inicio de sesión. Esto permite que una aplicación cliente solicite que el servicio autentique una cuenta incluso si el cliente no tiene el nombre de la cuenta. Para más información, por favor consulte la página SPN en el sitio web de msdn.

El identificador SPN debe respetar este patrón:

• "ServiceName/FQDN_user" si el SPN es un atributo del ordenador
• "ServiceName/FQDN_computer" si el SPN es un atributo de usuario

dónde:

• ServiceName es el nombre del servicio al que el cliente desea autenticarse.
• El Fully Qualified Domain Name (FQDN) es un nombre de dominio que especifica su ubicación exacta en la jerarquía de árbol del Active Directory para ambos equipos y usuarios.

En las bases de datos 4D, el SPN se puede configurar:

• en la configuración de la estructura de la base, para un uso con 4D Server.
• o en la configuración del usuario (settings. archivo 4DSettings almacenado en la carpeta Preferencias de la base de datos) para las necesidades de despliegue.

Cuando las funcionalidades SSO están activas (ver arriba), puede confiar en la autenticación de usuario basada en las credenciales de sesión de Windows para abrir una sesión de usuario en 4D Server.

Tenga en cuenta que la funcionalidad SSO sólo ofrece un inicio de sesión autenticado, debe pasar esta información de acceso a su método de inicio de sesión 4D estándar. Cuando una aplicación 4D remota intenta conectarse al servidor, debe llamar al comando 4D Current client authentication, que devolverá el nombre del usuario, tal como se define en el Active Directory. Luego, puede pasar esta información de acceso a su propio sistema de identificación (utilizando el usuario y grupos integrados, los comandos LDAP, o cualquier mecanismo personalizado) para abrir la sesión apropiada para el usuario remoto en su aplicación 4D. 

Este principio se describe en el siguiente gráfico:

El comando Current client authentication debe ejecutarse en el método base On Server Open Connection, que se llama cada vez que un 4D remoto abre una nueva conexión en la base 4D Server. Si la autenticación falla, puede devolver un valor no nulo en $0 para rechazar la conexión.

El comando Current client authentication, utiliza la siguiente sintaxis:

donde:

• login es el identificador utilizado por el cliente para iniciar sesión en el Active Directory (texto). Es necesario utilizar este valor para identificar al usuario dentro de su base.
  Si el usuario no está autenticado registrado correctamente, una cadena vacía se devuelve y no se devuelve ningún error.
• dominio y protocolo son parámetros de texto opcionales. Son llenados por el comando y le permiten aceptar o rechazar las conexiones en función de estos valores:
  • dominio es el nombre del dominio de Active Directory
  • protocolo es el nombre del protocolo utilizado por Windows para autenticar al usuario. Puede ser "Kerberos" o "NTLM", dependiendo de los recursos disponibles.

Para más información sobre este comando, consulte la descripción del comando Current client authentication

4D Server soporta varias configuraciones SSO, dependiendo de la arquitectura y la configuración actual. El protocolo utilizado para la autenticación (NTLM o Kerberos), así como información devuelta por el comando CommonComment dependen de la configuración del sistema. El protocolo utilizado para la autenticación se devuelve en el parámetro protocolo del comando CommonComment.

La siguiente tabla lista los requerimientos para la autenticación NTLM o Kerberos:

(*)La siguiente configuración específica es soportada: el usuario remoto 4D es una cuenta local en una máquina que pertenece al mismo AC como 4D Server. En este caso, el parámetro  dominio se llena con el nombre de la máquina 4D Server. Tenga en cuenta que el soporte depende de los parámetros usuario: si no está disponible, Current client authentication devuelve cadenas vacías.

(**) Si se respetan todos los requisitos de Kerberos pero el comando CommonComment devuelve "NTLM" en protocolo, esto significa que usted se encuentra en una de las siguientes situaciones:

• La sintaxis SPN no es válida; en otras palabras, no respeta todas las restricciones impuestas por Microsoft.
• O bien, el SPN tiene duplicados en el AD. Este problema sólo puede ser solucionado por el administrador AD en el lado AD.

Nota: una sintaxis válida no significa que la propia declaración SPN es correcta; en particular, si el SPN no existe en el AD, CommonComment devuelve cadenas vacías.