Autorización de usuarios#

En la tarjeta del usuario, seleccione el método de inicio de sesión: Local, LDAP o OpenID. Para LDAP y OpenID, primero configure la conexión con el proveedor en el servidor Orchestrator.

Las capturas muestran la interfaz rusa. Los nombres de los elementos de este texto corresponden a la interfaz en inglés. Solo se muestra el método de acceso. Los demás parámetros del Usuario se describen en el artículo de la pantalla Usuarios.

El administrador del servidor configura las conexiones LDAP y OpenID. Estos ajustes permiten que Orchestrator compruebe las cuentas en un sistema externo durante el acceso. Se necesitan si la organización utiliza LDAP u OpenID. El acceso local con nombre de usuario y contraseña no requiere estas conexiones.

Aplicación de los ajustes de autenticación#

En una instalación con Docker, el administrador modifica los parámetros de .env en el directorio de instalación de Orchestrator. En una instalación local, los parámetros correspondientes se configuran en backend/config/config.ini. Después de modificar este archivo, es necesario reiniciar la aplicación.

Para aplicar los cambios de .env en Docker, vuelva a crear el contenedor de la aplicación desde el directorio de instalación. El siguiente comando interrumpe temporalmente la aplicación, pero no vuelve a crear la base de datos:

docker compose up -d --no-deps --force-recreate orchestrator

Autorización local#

Para acceder con nombre de usuario y contraseña, seleccione "Local".

Ejemplo: "Login" contiene docs.user y en "Password" se ha introducido la contraseña de esa cuenta. La contraseña se muestra como puntos. Está seleccionado "Local".

Autenticación LDAP#

Para acceder con una cuenta del directorio, seleccione "Use LDAP authentication" y elija el Usuario en "LDAP users". La captura muestra el método seleccionado. Todavía no se ha elegido una cuenta del directorio.

Para conectar el directorio LDAP, el administrador configura estos parámetros en .env:

• LDAP_SERVER — dirección del servidor del directorio que almacena las cuentas.
• LDAP_PORT — puerto de conexión. Depende del método de protección descrito a continuación.
• LDAP_BASE_DN — sección del directorio donde Orchestrator busca las cuentas.
• LDAP_GROUP — unidad organizativa dentro de LDAP_BASE_DN donde se realiza la búsqueda.
• LDAP_FILTER — condición de selección de cuentas. Limita los resultados de búsqueda y se aplica al iniciar sesión.
• LDAP_UID_KEY — atributo del directorio que identifica al Usuario, por ejemplo uid.

Si el directorio exige una cuenta independiente para buscar usuarios, el administrador debe configurar sus credenciales.

El cifrado protege la conexión con el directorio. El administrador debe ajustar el método y el puerto a la configuración del servidor LDAP:

• StartTLS — activa el cifrado después de conectarse al servidor. Se establece LDAP_ENCRYPTION=tls, normalmente con el puerto 389.
• LDAPS — establece una conexión cifrada desde el inicio. Se establece LDAP_ENCRYPTION=ssl, normalmente con el puerto 636.

El certificado del servidor LDAP debe ser de confianza en el servidor Orchestrator. Los parámetros adicionales controlan la comprobación del certificado y los tiempos de espera:

• LDAP_TLS_CACERT — ruta al archivo o directorio de certificados de confianza utilizado para comprobar el servidor LDAP.
• LDAP_NETWORK_TIMEOUT — tiempo de espera de la conexión de red con el servidor LDAP.
• LDAP_OPERATION_TIMEOUT — tiempo de espera para completar una operación del directorio.

El administrador debe elegir los valores según los certificados y los tiempos de respuesta del servidor de su organización. Después de modificar .env, es necesario aplicar los ajustes de autenticación. Luego se comprueba el acceso con una cuenta LDAP.

Autenticación OpenID#

Para acceder mediante un proveedor OpenID, seleccione "Use OpenID authentication" e indique en "oAuth id" el valor que identifica al Usuario en el proveedor.

Ejemplo: el valor sub del proveedor es docs.user. Está seleccionado "Use OpenID authentication" y "oAuth id" contiene docs.user.

Un proveedor OpenID es un sistema externo que verifica la cuenta durante el acceso. Para conectarlo, el administrador configura estos parámetros en .env:

• O_AUTH_CLIENT_ID — identificador de Orchestrator registrado con el proveedor.
• O_AUTH_CLIENT_SECRET — secreto utilizado para autenticar Orchestrator ante el proveedor. Se obtiene del administrador del proveedor y no debe publicarse.
• O_AUTH_AUTH_URI — dirección de la página del proveedor donde accede el Usuario.
• O_AUTH_TOKEN_URI — dirección donde Orchestrator obtiene un token que confirma el acceso.
• O_AUTH_USER_INFO_URI — dirección para obtener los datos del Usuario del proveedor.
• O_AUTH_SCOPE — permisos solicitados para acceder a los datos del proveedor. Se configura según sus ajustes.

Las direcciones y los valores se obtienen de la configuración de la aplicación registrada con el proveedor.

Registre un callback HTTPS fijo con el proveedor: https://<dominio-orquestador>/api/v1/system/oauth_hook. Establezca esto en O_AUTH_REDIRECT_URI o deje esta variable vacía: entonces la dirección se formará a partir de NGINX_DOMAIN_NAME. El dominio y la dirección registrados con el proveedor deben coincidir.

Por defecto, para vincular al usuario con el proveedor se utiliza el campo inmutable sub (O_AUTH_USER_LINK_FIELD=sub). Si ya se ha configurado otro esquema de vinculación o se cambia de proveedor, primero coordine la migración de los inicios de sesión existentes de OpenID: un simple cambio de variable puede privar a los usuarios de acceso. La instalación admite un solo proveedor configurado.

Después de configurar el proveedor, es necesario aplicar los ajustes de autenticación y comprobar el acceso con una cuenta OpenID.

Diagnóstico de errores de inicio de sesión con OpenID#

Si el acceso falla al volver del proveedor, un administrador debe abrir "System errors".

Para verla se requiere "Read" de "Robot Messages" en la pestaña "Access" del Rol. La captura muestra este permiso. Los demás permisos del Rol se configuran por separado.

Busque una entrada con el canal oauth y nivel WARNING. Su hora debe corresponder al intento de acceso.

El mensaje OAuth callback failed significa que el acceso se interrumpió al volver del proveedor. El valor stage indica la etapa que falló:

• callback — comprobación de la solicitud y los ajustes;
• token — obtención del token del proveedor;
• userinfo — obtención de los datos del Usuario;
• identity — validación del valor que identifica al Usuario;
• session — almacenamiento de los datos verificados para completar el acceso.

El código de la causa aparece en reason. Un fallo de comunicación con el proveedor también puede incluir los valores disponibles http_status, curl_errno o provider_error.

Ejemplo de un error de configuración después de iniciar el acceso:

OAuth callback failed: stage=callback, reason=not_configured

Para restablecer el acceso, es necesario realizar estos pasos:

1. Comprobar que el identificador del cliente, las direcciones HTTPS de token y de información del usuario, el campo de vinculación y el callback estén configurados correctamente. Compruebe O_AUTH_CLIENT_ID, O_AUTH_TOKEN_URI, O_AUTH_USER_INFO_URI, O_AUTH_USER_LINK_FIELD y O_AUTH_REDIRECT_URI.
2. Si la configuración cambió durante el acceso, restablecer una configuración coherente y aplicarla según la sección de aplicación de los ajustes de autenticación.
3. Iniciar el acceso de nuevo desde la página de inicio de sesión. No volver a abrir el callback anterior: su estado ya se ha utilizado.

La causa pending_missing significa que no hay un intento de acceso pendiente en la sesión actual. Con state_invalid o pending_expired, también es necesario iniciar el acceso de nuevo. Si el error persiste, el administrador debe comprobar la conservación de la sesión del navegador y la configuración del proveedor.

El mensaje OAuth login failed corresponde a la finalización del acceso después del callback y contiene solo la etapa. El valor verified_identity indica que faltan datos verificados o que han caducado, user_match indica un error al vincular al usuario y session indica un error al crear la sesión.

Los mensajes de diagnóstico no incluyen tokens, el código de autorización, el secreto del cliente, el identificador de sesión ni el valor del campo de vinculación del usuario. Para contactar con soporte, basta con proporcionar la hora del error y la entrada de diagnóstico sin añadir esos datos. Un callback exitoso no genera una entrada de error. Si el error es inesperado, puede aparecer solo el nombre de la clase de excepción en lugar de la etapa y la causa.