SSO y aprovisionamiento

El inicio de sesión único (SSO) permite a los miembros iniciar sesión en Bird a través de tu proveedor de identidad en lugar de usar una contraseña de Bird independiente. Bird admite conexiones SAML 2.0 y OpenID Connect (OIDC).

Configurarlo es tarea de un Owner de la organización, y los controles están en la página Single sign-on de tu organización. Un miembro con el permiso de SSO puede gestionar conexiones sin ser Owner.

El inicio de sesión personal con Google o GitHub es independiente del SSO de la organización. Consulta Login, password & MFA.

Cómo funciona el SSO

Una conexión SSO cubre uno o más dominios de correo verificados, como yourcompany.com. Los miembros en esos dominios se autentican con tu proveedor de identidad. Sus permisos en Bird siguen proviniendo de sus roles en la organización y el espacio de trabajo.

Qué implica la configuración

Un Owner de la organización y un administrador del proveedor de identidad completan la configuración:

1. Demuestra que el dominio es tuyo. Bird te proporciona un registro DNS para publicar por cada dominio de correo cubierto por la conexión. La aplicación obligatoria no se puede activar hasta que el dominio esté verificado.
2. Configura la conexión. Para SAML, proporciona los metadatos del proveedor de identidad, o la URL de inicio de sesión y los certificados de firma. Para OIDC, proporciona el emisor y las credenciales del cliente. Copia los datos de service-provider o de redirección de Bird en tu proveedor de identidad.
3. Prueba la conexión. Completa un inicio de sesión de prueba antes de activar la conexión. Independientemente del protocolo que hayas elegido, un borrador cuya prueba sea exitosa se activa automáticamente, siempre que tu organización tenga un dominio verificado y esté dentro de su límite de conexiones activas.
4. Decide si exigir SSO. Cuando el SSO es opcional, los miembros pueden usar SSO u otro método de inicio de sesión disponible. Cuando es obligatorio, los miembros deben completar el SSO para acceder a la organización. Exigir SSO requiere una conexión activa y al menos un dominio verificado.

Exigir SSO surte efecto de inmediato, en cada solicitud, y no solo en el siguiente inicio de sesión. Un miembro cuya sesión actual no se haya establecido a través de tu proveedor de identidad pierde acceso a la organización hasta que vuelva a iniciar sesión con él, así que planifica el cambio en función del horario de tu equipo en lugar de anunciarlo después. Los Owners de la organización son la excepción: un Owner conserva el acceso con su contraseña de Bird, que es lo que evita que una conexión mal configurada deje a todos fuera.

Configura tu proveedor de identidad

El paso 2 es la mitad que varía según el proveedor: el mismo valor tiene un nombre distinto en cada uno, y cada uno tiene un ajuste que rechaza todos los inicios de sesión si está mal configurado. Los nombres de campo propios de Bird son los que aparecen en la página de la conexión, bajo Register these with your identity provider.

• Configurar SSO con Okta
• Configurar SSO con Google Workspace
• Configurar SSO con Microsoft Entra ID

Para cualquier otro proveedor SAML 2.0 u OpenID Connect, los cuatro pasos anteriores son todo lo necesario.

Configurar SAML sin valores provisionales

El Entity ID y la Assertion Consumer Service URL de una conexión SAML se derivan de la propia conexión, por lo que no existen hasta que la creas. Esto genera un círculo: tu proveedor de identidad necesita esos valores, y ellos necesitan la conexión.

Crea la conexión primero. En Add connection, elige SAML y luego I have not set up my provider yet. La conexión se crea como borrador sin datos del proveedor de identidad, y al abrirla se muestran los valores a registrar en Register these with your identity provider. Configura tu proveedor con ellos, luego vuelve y usa Supply the details en la misma conexión, en el formato que tengas disponible:

• una metadata URL, que obtenemos y leemos
• el documento de metadatos en sí, para un proveedor que entrega un archivo en lugar de alojarlo
• el entity ID, la URL de inicio de sesión y los certificados de firma, ingresados directamente

Un documento subido se lee para extraer esos tres valores y no se almacena.

Hasta que lleguen los datos, la conexión permanece como borrador: no atiende inicios de sesión y no se puede activar.

Cómo se identifican los miembros

Una conexión SAML identifica a cada miembro por el NameID que envía tu proveedor, y ese identificador es permanente para cualquiera que inicie sesión. Configurar una conexión no te pide qué formato usar. Si proporcionaste una metadata URL o un documento, leemos lo que tu proveedor anuncia allí y vinculamos la conexión a eso. Si ingresaste los datos manualmente, no hay metadatos que leer, por lo que la conexión se vincula a un ID permanente.

Lo que sí controlas es el valor detrás del identificador. Configura el nombre de usuario de la aplicación en tu proveedor con un valor opaco que nunca se reasigne, y envía la dirección por separado como atributo email. Usar una dirección de correo como identificador es más débil de forma permanente: si la dirección se reasigna, la siguiente persona que la reciba hereda la cuenta de Bird.

Los metadatos indican lo que tu proveedor puede enviar; la configuración de la aplicación decide lo que realmente envía, y ambos pueden diferir. Por eso el inicio de sesión de prueba del paso 3 reporta el identificador y el formato que la aserción realmente contenía, y ese reporte es cómo verificas que ambos coincidan antes de que alguien dependa de la conexión. También rechazamos un identificador etiquetado como persistente que en realidad sea una dirección de correo.

Si la prueba reporta un formato que no esperabas, tienes dos formas de corregirlo, y cuál es la correcta depende de cuál sea el problema:

• El proveedor está enviando el valor incorrecto. Cambia el nombre de usuario de la aplicación en tu proveedor y vuelve a probar. Esta suele ser la corrección adecuada, porque el identificador opaco es el que vale la pena conservar.
• La conexión está vinculada al valor incorrecto. Abre Edit en la conexión y cambia el formato de NameID al que tu proveedor envía.

Haz cualquiera de las dos antes de que los miembros empiecen a iniciar sesión. Una vez que lo hayan hecho, sus cuentas están vinculadas al identificador vigente, por lo que el formato queda fijo y el cambio se rechaza. Crea una conexión nueva para el formato correcto.

Reemplazar un proveedor

Los datos del proveedor de identidad de una conexión SAML se pueden reemplazar mientras nadie haya iniciado sesión con ella. Una vez que los miembros la hayan usado, sus cuentas están vinculadas a los identificadores que envía tu proveedor actual, por lo que el reemplazo se rechaza. Crea una conexión nueva para el nuevo proveedor. En una conexión OIDC puedes rotar el secreto del cliente en cualquier momento, lo cual no cambia cómo se identifican los miembros, pero el proveedor en sí no se puede reemplazar.

El inicio de sesión de prueba del paso 3 no cuenta. Una prueba no vincula ninguna cuenta ni otorga acceso, así que una conexión que hayas configurado y probado pero que aún no hayas dado a tu equipo todavía se puede redirigir.

Qué cambia para tu equipo

Una conexión puede otorgar acceso predeterminado a la organización y al espacio de trabajo a un miembro en su primer inicio de sesión SSO exitoso. Configura ese acceso predeterminado de forma explícita; de lo contrario, invita a los miembros y asigna roles antes de que inicien sesión. Consulta Usuarios, equipos y roles.

Suspender una conexión impide nuevos inicios de sesión a través de ella. Revisa las membresías en Bird y las sesiones activas por separado cuando alguien deja tu empresa.

Próximos pasos

• Login, password & MFA: seguridad de la cuenta individual, incluido el inicio de sesión personal con Google o GitHub
• Usuarios, equipos y roles: cómo funcionan los roles y permisos una vez que los miembros están dentro
• Authentication & claves de API: la referencia de autenticación para desarrolladores