SSO con SAML 2.0

UDM Plus

El inicio de sesión único (SSO) con SAML 2.0 permite que tus usuarios inicien sesión en deskbird usando su proveedor de identidad (IdP) existente. A continuación encontrarás opciones rápidas para Okta y Keycloak, además de una guía completa de configuración de federación (SSO iniciado por el SP).

¿Estás configurando UDM Plus? User & Data Management (UDM) Plus: setup te guía paso a paso por el SSO, tu HRIS, SCIM y la configuración de visibilidad en orden.

1. SAML usando Okta
2. SAML usando Keycloak
3. Configuración de la federación SAML 2.0
4. Renovación del certificado SAML
5. Cuándo usar SAML vs. OAuth / OIDC

1. SAML usando Okta

Usa nuestra guía dedicada de Okta para configurar una app SAML en Okta, mapear los atributos requeridos y probar el SSO iniciado por el SP en deskbird. Incluye capturas de pantalla, declaraciones de atributos y consejos para solucionar problemas.
👉 Paso a paso: Configurar SAML SSO con Okta

2. SAML usando Keycloak

¿Prefieres usar Keycloak? Sigue la guía de Keycloak para iniciar el SSO en deskbird.
👉 Paso a paso: Configurar SAML SSO con Keycloak

3. Configuración de la federación SAML 2.0

SAML 2.0 (Security Assertion Markup Language) es un protocolo basado en XML para intercambiar de forma segura datos de autenticación/autorización entre un proveedor de identidad (IdP) y un correo electrónico del proveedor (SP). deskbird admite el SSO iniciado por el SP (la autenticación debe comenzar desde deskbird).

Si quieres un acceso directo en tu lanzador IAM (por ejemplo, OneLogin, JumpCloud) para que los usuarios puedan hacer clic, añade una Bookmark application que inicie el flujo SP-initiated en deskbird:
https://app.deskbird.com/saml?providerName={saml-provider-ID}
El ID del proveedor SAML sigue el formato saml.{company-name}. Ejemplo para "Polaroid": https://app.deskbird.com/saml?providerName=saml.polaroid.

Crea una Federation application separada y oculta en tu IdP para la conexión SAML en sí (no visible para los usuarios).

3.1 Configuración general

Configura tu IdP con los siguientes datos del correo electrónico del proveedor de deskbird:

💡 Para que la autenticación SAML 2.0 sea exitosa, configura NameID con la dirección de correo electrónico del usuario usando el formato urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

Ejemplo de fragmento de aserción

<saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="<IdP Entity ID>" SPNameQualifier="https://api.deskbird.app/saml/metadata" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> email </saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> </saml2:Subject> 

Enviar a deskbird para la configuración

Si tienes un archivo de metadatos de tu IdP, puedes simplemente enviar eso en su lugar.

3.2 Atributos de usuario

Atributo obligatorio (usa el nombre exacto):

Atributos recomendados:

3.3 Sincronización de nombre desde tu IdP

Si los usuarios se crean en su primer inicio de sesión SAML (sin SCIM ni sincronización HRIS), deskbird toma su nombre y apellido de tu IdP y los mantiene sincronizados:

• Primer inicio de sesión: el usuario se crea con el nombre y apellido de la aserción SAML.
• Inicios de sesión posteriores: si tu IdP envía un nombre diferente, deskbird lo actualiza. Esto también reemplaza los nombres que se hayan cambiado manualmente en deskbird.
• Edición: mientras tu IdP proporcione el nombre, los usuarios y los Admin no pueden editarlo en deskbird (web, iOS y Android). Los cambios de nombre deben hacerse en tu IdP y aparecerán tras el siguiente inicio de sesión del usuario.
• SCIM o sincronización HRIS: si también usas uno de estos, esa sincronización gestiona el nombre y SAML nunca lo sobrescribe.
• No se envía nombre: si la aserción no incluye nombre y apellido, los usuarios lo introducen durante la configuración y pueden seguir editándolo.

💡 Solo se sincronizan nombre y apellido. Otros atributos, como oficina o departamento, no se toman de SAML.

3.4 Archivo de metadatos

Después de crear la aplicación SAML en tu IdP, por favor envíanos el archivo de metadatos que incluya:

• Certificado
• Entity ID
• SSO URL

4. Renovación del certificado SAML

Los certificados SAML tienen una fecha de caducidad (normalmente de 1 a 3 años tras su creación). Cuando un certificado está a punto de caducar, tu proveedor de identidad te avisará. Es importante renovar el certificado antes de que expire para evitar problemas de acceso.

Proceso de renovación paso a paso (Microsoft Entra ID):

1. En el portal de Microsoft Entra ID, ve a tu Enterprise Application de deskbird.
2. Navega a Single sign-on > SAML Certificates.
3. Haz clic en el icono Edit (pencil).
4. Haz clic en New Certificate.
5. Establece la fecha de caducidad (por defecto son 3 años).
6. Haz clic en Save. El nuevo certificado aparecerá con estado Inactive.
7. Descarga el nuevo certificado (formato Base64).
8. Envía el certificado al soporte de deskbird mediante un ticket de soporte. Incluye el nombre de tu empresa y menciona que es una renovación de certificado SAML.
9. El soporte de deskbird reemplazará el certificado de nuestro lado y te confirmará cuando esté listo.
10. Una vez que deskbird confirme, vuelve a Entra ID y activa el nuevo certificado (ponlo como Active).

5. Cuándo usar SAML vs. OAuth / OIDC

Si estás decidiendo entre SAML y OAuth (Microsoft SSO), ten en cuenta lo siguiente: