Autorización SAML y control de acceso

Instrucciones y metodología para definir su política de acceso y gestionar SAML en su organización.

SAML permite a las organizaciones gestionar la autenticación y los derechos de acceso de los usuarios de Tulip utilizando su proveedor de identidad (IdP) existente. Esta guía detalla las opciones disponibles para la implementación de la integración de un IdP de nivel empresarial a través del protocolo SAML.

Trabajo previo

• Comprender los roles de usuario de Tulip
• Clasifica a los futuros usuarios de Tulip por rol, de modo que estés preparado para actualizar un atributo SAML con su rol en Tulip
• Identifica quién, dentro de tu organización, se encargará de configurar tu IdP y tu cuenta de Tulip

Configuración del IdP

Cuando tu instancia de Tulip está configurada para utilizar SAML para el inicio de sesión, Tulip mantiene un vínculo entre los usuarios de Tulip y los usuarios de tu proveedor de identidad empresarial (IdP). Un usuario determinado que tenga una cuenta en el IdP debería tener , como máximo, una cuenta en una instancia concreta de Tulip. Tulip mantiene este vínculo mediante un concepto específico de SAML denominado «NameID». Un NameID es un tipo de identificador opaco que proporciona la autenticación SAML y que define el IdP.

Dado que el NameID se utiliza para mantener este vínculo, Tulip espera que los NameID sean estables, lo que significa que el NameID que Tulip recibe para un usuario concreto del IdP no debería cambiar a lo largo de la vida útil de dicho usuario. Si el NameID de un usuario cambia, el vínculo se romperá y es posible que se produzcan errores al iniciar sesión.

Tulip recomienda encarecidamente que configures tu IdP para que proporcione un NameID que no cambie con el tiempo. Por este motivo, Tulip desaconseja el uso de nombres o direcciones de correo electrónico como NameID, ya que estos valores pueden cambiar con el tiempo. Te recomendamos que configures tu IdP para que utilice ID de objetos internos o nombres de cuenta que, por garantía, nunca cambien.

Tenga en cuenta que los NameID no tienen por qué ser legibles ni reconocibles para las personas (de hecho, por motivos de seguridad, suele ser mejor utilizar valores no reconocibles como NameID).

Al configurar su IdP, le recomendamos que establezca el formato de NameID en «Persistente», lo que indica a Tulip que el valor debe permanecer constante durante toda la vida útil de un usuario.

Al asignar el valor de origen del atributo NameID, asígnelo a un valor que se sepa que es inmutable, como «ID de objeto» o «nombre principal de usuario».

Microsoft Entra

Los clientes que utilicen Microsoft Entra como IdP deben seguir estas instrucciones específicas para configurar su aplicación de Tulip de modo que utilice NameID persistentes:

1. En Entra, comience por la aplicación empresarial asociada a su instancia de Tulip.
2. En el menú de navegación de la izquierda, haz clic en «Inicio de sesión único» dentro del grupo «Administrar».
3. Edita la sección «Atributos y reclamaciones».
4. En la sección «Reclamaciones obligatorias», haz clic en la fila correspondiente a la reclamación denominada «Identificador único de usuario (Name ID)».
5. Asegúrese de que el «Formato del identificador de nombre» esté configurado en «Persistente». Establezca la «Fuente» en «Atributo» y seleccione un atributo que se mantenga estable durante toda la vida útil del usuario. user.userprincipalname y user.objectid son buenas opciones.

Opciones de configuración de SAML y Tulip

Modos de control

El modo de control de Tulip indica que el rol y el espacio de trabajo de un usuario en Tulip se obtienen de la asignación de atributos SAML únicamente la primera vez que inicia sesión en Tulip.

Se impide el inicio de sesión a los usuarios desactivados en Tulip.

El modo de control del IdP significa que el rol y el espacio de trabajo de un usuario en Tulip se actualizarán desde el IdP cada vez que inicie sesión.

Asignación predeterminada de roles (solo en el modo de control de Tulip)

En el primer inicio de sesión, a todos los usuarios se les asigna un nivel de acceso predeterminado (Visor con acceso a reproductor). A continuación, el titular de la cuenta deberá ajustar manualmente el rol al nivel adecuado dentro de Tulip.

Espacios de trabajo

Más información sobre los espacios de trabajo

Al igual que con el atributo de rol, ahora tendrás la opción de asignar automáticamente a los usuarios a un espacio de trabajo específico cuando se cree la cuenta por primera vez. Tras la creación de la cuenta, los titulares de la cuenta pueden mover a los usuarios de forma flexible entre los distintos espacios de trabajo.

Asignación personalizada de espacios de trabajo SAML

:::(Información) (Varios espacios de trabajo)
Ten en cuenta que solo puedes asignar usuarios a varios espacios de trabajo en el modo de control de « Tulip ».

En el modo de control del IdP, cada usuario solo puede ser miembro de un único espacio de trabajo.
:::

En el primer inicio de sesión, se asigna al usuario el acceso al espacio de trabajo en función del grupo indicado en su atributo de espacio de trabajo. A partir de ese momento, Tulip ya no leerá el atributo de espacio de trabajo de ese usuario, y cualquier cambio en el espacio de trabajo deberá ser realizado en la plataforma por un titular de la cuenta.

Asignación predeterminada de espacios de trabajo

En el primer inicio de sesión, todos los usuarios obtienen acceso a un espacio de trabajo predeterminado de su elección. A continuación, el titular de la cuenta puede ajustar el acceso al espacio de trabajo.

Grupos de usuarios

Puede asignar usuarios a la función «Grupos de usuarios»{target=_blank} de Tulip en todas las configuraciones SAML.

Los grupos de usuarios existen a nivel de cuenta. Una vez que un usuario se asigna a un grupo de usuarios, pasará a ser miembro de ese grupo en todos los espacios de trabajo.

Una vez que active la opción «Grupos de usuarios», podrá asignar usuarios desde su proveedor de identidades (IdP) a grupos de usuarios en Tulip en función del valor de un atributo en SAML.

A continuación, puedes especificar hasta 100 atributos SAML y asignar los valores de cada uno de ellos a un grupo de usuarios. De este modo, un usuario puede estar asignado a varios grupos de usuarios.

Asignación de grupos de usuarios y comportamiento del modo de control

El comportamiento de la pertenencia a grupos de usuarios depende de la configuración del modo de control.

• Modo de control de Tulip: los grupos asignados mediante SAML a un usuario se aplican únicamente la primera vez que inicia sesión. A partir de entonces, la pertenencia a los grupos se puede gestionar dentro de Tulip, y cualquier cambio manual se conserva en los inicios de sesión posteriores.
• Modo de control del IdP: La pertenencia completa a grupos de un usuario se recalcula a partir de sus atributos SAML actuales en cada inicio de sesión. Tulip asigna los grupos que el mapeo calcula y elimina al usuario de cualquier grupo no incluido en el mapeo, incluidos los grupos que se asignaron manualmente dentro de Tulip.

Opciones de autenticación

Si desea utilizar claves FIDO para la autenticación de usuarios, deberá «Desactivar la coincidencia de métodos de autenticación».

Clase de contexto de autenticación

La clase de contexto de autenticación es el método especificado mediante el cual los usuarios se autentican.

Cuando está habilitada, los usuarios solo podrán autenticarse utilizando el método especificado.

Si está desactivada, la selección del método de autenticación se delegará por completo al proveedor de identidad.

Autenticación forzada

Tulip utiliza el parámetro «forceAuthn» de SAML para controlar si los usuarios deben volver a autenticarse con su proveedor de identidad (IdP) en cada inicio de sesión, o si se puede reutilizar una sesión SAML existente a nivel del sistema operativo. Tulip no utiliza el parámetro «isPassive ». En este caso, la sesión existente es la sesión SAML a nivel del sistema operativo (por ejemplo, una sesión de Windows vinculada a tu proveedor de identidad), no una sesión específica de Tulip.

Autenticación forzada activada (por defecto): Tulip envía forceAuthn=true, lo que obliga al usuario a autenticarse activamente con su proveedor de identidad en cada inicio de sesión, independientemente de cualquier sesión SAML existente a nivel del sistema operativo. Esta configuración garantiza que los usuarios no puedan eludir la reautenticación.

Autenticación forzada desactivada: Tulip envía forceAuthn=false. Si el usuario ya tiene una sesión SAML activa a nivel del sistema operativo reconocida por el proveedor de identidad, iniciará sesión en Tulip automáticamente sin necesidad de volver a introducir sus credenciales.

Personalización

Personalización opcional para el inicio de sesión del usuario.

Etiqueta del botón de inicio de sesión: personaliza el texto del botón de inicio de sesión SAML en las páginas de inicio de sesión de Tulip.

Correo electrónico de asistencia personalizado: configura una dirección de correo electrónico personalizada que se mostrará a los usuarios cuando se encuentren con un error de inicio de sesión SAML. Esto puede dirigir a los usuarios a tu servicio de asistencia informática interno. Si se deja en blanco, se utilizará la dirección de correo electrónico de asistencia predeterminada «support@tulip.co».

Reproductor de escritorio: navegador predeterminado del sistema operativo para la autenticación

Si tu inicio de sesión SSO o la autorización del conector OAuth requieren una integración que solo está disponible a través de tu navegador predeterminado, el reproductor de Tulip se puede configurar para abrir los flujos de autenticación en el navegador predeterminado del sistema operativo en lugar de en una ventana integrada.

Requisitos de versión

Para la autenticación mediante el navegador predeterminado del sistema operativo, debe cumplir los siguientes requisitos de versión de Tulip:* Reproductor de escritorio 2.8 o superior* Versión de fábrica 318 o superior

Comportamiento de la función

Este comportamiento se aplica tanto al inicio de sesión en el reproductor de escritorio mediante SSO como a la autorización de conectores OAuth dentro de las aplicaciones de Tulip. En ambos casos, cuando un usuario inicia la autenticación, se abre el navegador predeterminado del sistema para gestionar el siguiente flujo:

1. El navegador del sistema se inicia y navega hasta la página de inicio de sesión del proveedor de identidad (IdP) de su organización.
2. El usuario completa su inicio de sesión (introduciendo credenciales, completando la autenticación multifactorial (MFA), etc.) en el navegador exactamente igual que lo haría en la web.
3. Una vez completada la autenticación, la página del navegador muestra el siguiente mensaje: «¡Listo! Puede cerrar esta ventana».
4. La ventana del navegador permanece abierta. No se cierra automáticamente. El usuario debe cerrarla manualmente.
5. Tulip Desktop Player detecta que el inicio de sesión se ha completado y continúa con normalidad.

Solicitudes de permiso previstas

Los usuarios pueden encontrarse con una o dos solicitudes de permiso, dependiendo de su sistema operativo y de la configuración del navegador:

1. Permiso del cortafuegos del Desktop Player / servidor local (a nivel del sistema operativo)

Cuando se inicia la autenticación, el Desktop Player crea un servidor local temporal para recibir la respuesta de autenticación. Dependiendo del sistema operativo y de la configuración de seguridad, puede aparecer un mensaje del cortafuegos del sistema o de acceso a la red preguntando si se permite que el Desktop Player acepte conexiones entrantes.

• Acción necesaria: Permitir la conexión. Se trata de un comportamiento esperado y es necesario para que el inicio de sesión se complete.
• Dependiendo de la configuración del sistema operativo, este mensaje puede aparecer solo la primera vez o cada vez.

2. Permiso de acceso a la red local del navegador (a nivel del navegador)

Una vez que el usuario haya completado el inicio de sesión con su proveedor de identidad, la página de finalización de la autenticación del navegador envía el resultado al Desktop Player realizando una solicitud al servidor local descrito anteriormente. Algunos navegadores muestran un mensaje de permiso preguntando si se permite que la página acceda a los dispositivos de la red local.

• Acción necesaria: Permitir el acceso. Se trata de un paso seguro y previsto en el flujo de autenticación.
• La solicitud se realiza únicamente a localhost y contiene únicamente la respuesta de autenticación cifrada. En este momento no se transmiten credenciales confidenciales.

Resumen de las diferencias para el usuario

La siguiente tabla compara los comportamientos de la autenticación predeterminada y la autenticación habilitada por el navegador del sistema operativo:

Ejemplo: Crear grupos de acceso dentro de tu IdP

El siguiente ejemplo te ayudará a comprender cómo se pueden utilizar conjuntamente todas las diferentes opciones de la configuración de SAML.

Crear roles estandarizados de Tulip

Cada usuario necesitará un atributo de rol especificado en su IdP para que Tulip pueda determinar sus privilegios una vez que se haya autenticado con su nombre de usuario y contraseña del IdP.

También puede utilizar este campo «Rol» para determinar a qué sitios tiene acceso el usuario utilizando una convención de nomenclatura estándar. Aunque un campo de rol puede ser simplemente una variable establecida, se recomienda asignar al usuario a grupos específicos de Tulip dentro de su IdP y asociarlos a un atributo.

Rol

A cada usuario se le asignará un único rol en un espacio de trabajo.

Cuando Tulip recibe varios roles válidos para un usuario, aplica la siguiente lógica:

Si el conjunto incluye algún rol integrado (Operador, Creador, etc.), Tulip selecciona el rol integrado de mayor rango según una jerarquía interna estática. Los roles personalizados siempre se sitúan por debajo de todos los roles integrados, por lo que nunca se seleccionarán si hay algún rol integrado presente.

Si el conjunto incluye únicamente roles personalizados, Tulip selecciona el primer rol personalizado recibido en la carga útil de SAML.

Más información sobre los roles de usuario de Tulip.

Sitio

Supongamos que su organización tiene dos sedes, con un Tulip Instance para cada una.

Podemos identificar cada sede por su ubicación (Texas y Londres, respectivamente).

Combinación de sede y rol

Podemos combinar estas dos propiedades para crear una matriz de grupos a los que asignar a los usuarios. Recomendamos que las organizaciones añadan «Tulip» al principio o al final del valor, para que resulte más fácil filtrar por él.

Convención: tulip-siteRole

Si Jane Smith es la responsable de la sede de Texas, se la asignaría al grupo tulip-texasAccountOwner. Si Jane Smith también necesita acceso de lectura a la sede de Londres, se la podría añadir al grupo tulip-londonViewer.

Exponer estos grupos como un atributo para Tulip

En tu IdP, Jane debería tener un atributo, tulip-role, al que se asignarán todos los grupos de los que sea miembro y que contengan el prefijo «tulip-».

Cuando inicie sesión en Tulip, el atributo «tulip-role» tendrá dos valores: «tulip-texasAccountOwner» y «tulip-londonViewer». Puede configurar la asignación de roles para cada Tulip instance de forma individual, de modo que reciba los permisos correctos en cada caso.

Roles globales

También es posible que desee crear roles de acceso globales, como por ejemplo un rol de «Viewer». Estos usuarios podrán iniciar sesión en todas las instancias de Tulip instance con los mismos permisos. El formato recomendado para ello es:

tulip-globalViewer

Deberías configurar esta asignación de roles en cada instancia individual, dentro de la página de configuración de SAML en «Ajustes de la cuenta», para permitir que este usuario acceda a cada instancia.

{{snippet.¿Has encontrado lo que buscabas?}}