Configurar SSO con Okta

Esta página cubre la parte de Okta en una conexión SSO. La parte de Bird (verificar un dominio, probar, activar y requerir SSO) es igual para todos los proveedores y está en SSO y aprovisionamiento.

Okta y Bird necesitan valores del otro, así que por dónde empiezas depende del protocolo. Mantén ambos abiertos mientras trabajas.

SAML

Empieza en Bird para SAML. El Entity ID y la Assertion Consumer Service URL de una conexión SAML derivan de la propia conexión, así que créala con Aún no he configurado mi proveedor, registra los valores que muestra y vuelve a Proporcionar los detalles. Configurar SAML sin valores provisionales describe ese flujo.

Los nombres de campo de Okta no coinciden con los de Bird. Dos de ellos se parecen lo suficiente como para intercambiarlos por error, y al hacerlo la respuesta de inicio de sesión se envía a una URL que no puede procesarla.

La Single sign-on URL de Okta es la Assertion Consumer Service URL de Bird, no la URL de inicio de sesión de Bird. Si pegas ahí la URL de inicio de sesión, Okta envía cada respuesta al endpoint incorrecto y el inicio de sesión falla.

Identificar miembros por su dirección de correo electrónico

En el Name ID format de la aplicación SAML, elige EmailAddress y establece Application username en el valor con el que quieres que Bird identifique cada cuenta. Bird rechaza Unspecified y rechaza una respuesta cuyo formato de NameID no coincida con el que espera la conexión.

Lee Cómo se identifican los miembros antes de decidir: el identificador es permanente para cualquiera que inicie sesión a través de la conexión, por lo que un nombre de usuario de aplicación opaco con la dirección enviada aparte como atributo email es la opción más segura.

Validez de la aserción

Okta firma aserciones válidas desde cinco minutos antes de la emisión hasta cinco minutos después. Bird acepta esa ventana. No hay nada que configurar.

OIDC

Empieza en Okta para OIDC. Bird necesita el emisor, el client ID y el client secret para crear una conexión OIDC, así que registra la aplicación en Okta primero. La Redirect URI de Bird es la misma para todas las conexiones y aparece en Add connection antes de crear nada, así que puedes registrarla de entrada.

Crea una aplicación web OIDC en Okta y copia su client ID y secret en Bird, con el emisor de Okta como Issuer. Bird se autentica en el endpoint de token con client_secret_basic.

Registra la Redirect URI de Bird como la URI de redirección de inicio de sesión de la aplicación.

Mosaico de aplicación de Okta

Para que los miembros inicien desde su panel de Okta, configura:

• Login initiated by: Either Okta or App
• Application visibility: el mosaico visible para los usuarios
• Login flow: Redirect to app to initiate login (OIDC Compliant)
• Initiate login URI: la Initiate login URI de la conexión en Bird

Elige el flujo compatible con OIDC. El flujo Send ID Token directly to app (Okta Simplified) de Okta envía un token directamente a Bird en lugar de redirigir, y Bird no lo acepta.

Asignar la aplicación

Un miembro que no está asignado a la aplicación de Bird en Okta es rechazado por Okta, no por Bird. Bird reporta el rechazo como proveniente de tu proveedor de identidad, así que revisa las asignaciones y cualquier política de acceso condicional en Okta antes de volver a comprobar la configuración de la conexión.

Rotar el certificado de firma

Rota primero en Okta y luego en Bird. Bird verifica contra los certificados que tiene la conexión, por lo que una conexión de Bird que solo lleve el certificado nuevo mientras Okta aún firma con el anterior rechaza cada inicio de sesión hasta que Okta active el nuevo. El rechazo es un error de firma y se resuelve en cuanto ambos coinciden.

Próximos pasos

• SSO y aprovisionamiento: verificar un dominio, probar la conexión y requerir SSO
• Configurar SSO con Google Workspace
• Configurar SSO con Microsoft Entra ID