Hay un momento en todo equipo que crece en el que la forma de iniciar sesión deja de ser un detalle. Alguien se va y una semana después nadie sabe si su cuenta ha desaparecido de todos los sistemas. Un externo necesita acceso dos semanas y acaba con una contraseña que sobrevive al contrato un año entero. Una credencial compartida vive en una nota fijada porque pedir un usuario propio era más lento que copiarla.
Con la infraestructura es peor que con la mayoría de herramientas, porque esas cuentas pueden arrancar y parar servidores de producción y tienen las llaves de tus redes. El hueco entre "lo hemos dado de baja en el directorio de la empresa" y "ya no puede entrar al panel" es la ventana en la que nadie quiere pensar, y suele medirse en lo que tarda una persona en acordarse.
La solución es antigua y bien conocida: dejar de tener una contraseña distinta por herramienta y dejar que el sistema que tu empresa ya opera decida quién entra. Eso es el inicio de sesión único, y CubePath lo soporta para organizaciones. Tu equipo entra con el proveedor de identidad corporativo, los miembros se dan de alta en su primer login, y el acceso termina cuando tu proveedor dice que termina.
Lo que sigue es qué puedes conectar, cómo se configura y qué cambia el SSO para las personas de tu organización.
Qué Puedes Conectar
El SSO de CubePath usa OpenID Connect. Si tu proveedor de identidad soporta OIDC, funciona: Okta, Microsoft Entra, Google Workspace, proveedores autoalojados como Authentik y cualquier otro que siga el estándar. SAML no está soportado, y conviene saberlo antes de planificar una migración a su alrededor.
El requisito es un documento de discovery OIDC público. Tu proveedor tiene que publicar su configuración en la ruta estándar /.well-known/openid-configuration, sobre un issuer accesible desde internet por HTTPS en el puerto por defecto. Un proveedor que solo existe dentro de tu red privada, o que escucha en un puerto no estándar, no se puede alcanzar desde nuestro lado. En el panel hay un botón de prueba que comprueba exactamente esto antes de que te comprometas con nada.
Los tokens deben ir firmados con un algoritmo asimétrico estándar. Se aceptan las familias RSA y ECDSA, lo que cubre a todos los proveedores habituales con su configuración por defecto. Si el tuyo está puesto en algo poco común, la prueba de conexión te lo dirá.
Configurarlo Desde el Panel
El SSO vive en el panel, en Organización y luego SSO. Solo lo ven y lo cambian los propietarios y administradores de la organización.
Empieza registrando el callback en tu proveedor. Crea allí una aplicación OIDC y dale la redirect URI que aparece en la página de SSO de CubePath, con un botón para copiarla al lado:
https://identity.cubepath.com/account/sso/callback
Después trae cuatro valores. Un nombre de proveedor, que es solo la etiqueta que tu equipo va a reconocer, más la URL del issuer, el client ID y el client secret de la aplicación que has creado. Usa el botón de prueba junto al campo del issuer para confirmar que CubePath llega a tu proveedor antes de guardar nada.
El client secret se guarda cifrado y no se vuelve a mostrar. Cuando vuelvas a editar la configuración, ese campo aparece vacío, y dejarlo vacío mantiene el secreto que ya habías guardado. Solo lo vuelves a escribir si lo rotas en tu proveedor.
Después activa el SSO y guarda. La configuración se guarda igualmente, así que puedes prepararlo todo por adelantado y encenderlo cuando tu equipo esté listo.
Verificar Tu Dominio de Correo
Configurar el proveedor decide adónde van los logins. Lo que decide qué logins van ahí es tu dominio de correo verificado, y ese es un paso aparte que se hace con nuestro equipo de soporte.
Se solicita a través de soporte. Abre un ticket desde tu organización pidiendo el dominio, y nuestro equipo confirma que lo controlas antes de fijarlo en tu cuenta. Es un paso único, y una vez fijado el dominio se queda.
La verificación es lo que enciende el login por dirección de correo. Hasta que tu dominio esté verificado, tus ajustes de SSO se guardan pero tu equipo no puede iniciar sesión escribiendo su correo de trabajo, porque todavía no hay nada que asocie esa dirección con tu proveedor. La página de SSO muestra el estado de verificación, así que siempre sabes dónde estás.
El dominio no lo puedes poner tú, a propósito. Si cualquier organización pudiera escribir un dominio en un formulario, cualquiera podría reclamar el tuyo y desviar los logins de tus empleados a un proveedor bajo su control. Además, un dominio pertenece a una sola organización a la vez. Es la parte más lenta de la configuración y la que menos dispuestos estamos a convertir en autoservicio.
Se aplica en cada login, no solo al configurarlo. Si tu proveedor devolviera alguna vez una identidad cuyo correo queda fuera de tu dominio verificado, ese login se rechaza. Tu dominio verificado es la frontera de lo que tu proveedor de identidad puede afirmar dentro de CubePath.
Cómo Entra Tu Equipo
Escriben su correo de trabajo y eligen entrar con SSO. CubePath reconoce el dominio, les muestra tu proveedor y les envía allí a autenticarse. Vuelven ya con la sesión iniciada, sin ninguna contraseña de CubePath de por medio. Si tu proveedor les pide MFA, una llave hardware o cualquier otra cosa, eso ocurre en tu lado del flujo.
Quien ya está en tu organización simplemente entra. Los miembros existentes conservan el rol y los permisos que tienen. Una invitación enviada y nunca aceptada se da por aceptada con el login por SSO, así que nadie se queda a medio entrar.
A quien ya tenga una cuenta personal de CubePath con tu dominio hay que invitarle primero. Si un usuario ya tiene su propia cuenta de CubePath con una dirección de empresa pero no es miembro de tu organización, el SSO no adopta esa cuenta de forma automática. Invítale desde la página de Equipo y su siguiente login por SSO funcionará. Es deliberado: una cuenta existente nunca debería acabar dentro de una organización solo porque coincidía un dominio de correo.
Quién Entra, y Con Qué Rol
Crear miembros automáticamente en el primer login es un interruptor que controlas tú. Activado, cualquiera de tu dominio verificado que se autentique con tu proveedor pasa a ser miembro de tu organización en su primer login, sin invitación. Es lo que quiere la mayoría de equipos, porque es el punto en el que dar de alta a alguien en CubePath deja de ser una tarea que nadie debe olvidar. Desactivado, el SSO se convierte en un método de acceso para la gente a la que ya has invitado, y al resto se le deniega la entrada.
Tú eliges el rol que reciben los miembros nuevos, entre member, viewer y billing. Owner y admin no se pueden repartir automáticamente. Un error en la configuración de un proveedor de identidad nunca debería poder generar un administrador de tu cuenta de infraestructura, así que esos dos roles siguen siendo una decisión manual y deliberada.
Los miembros creados por SSO los gestiona tu proveedor. Su rol y sus permisos individuales no se editan a mano dentro de CubePath, porque tu proveedor de identidad es la fuente de verdad sobre quiénes son esas personas. En la práctica, decides el rol una vez, en los ajustes de SSO, y todo el mundo aprovisionado por esa vía llega con él.
Dar de Baja, Que Es de Lo Que Va Todo Esto
Aquí es donde el SSO se gana su sitio, así que conviene ser preciso sobre qué ocurre.
Desactivar a alguien en tu proveedor de identidad termina su acceso a CubePath. Ya no puede autenticarse, así que no puede conseguir una sesión nueva. Con el back-channel logout configurado, del que hablamos más abajo, sus sesiones actuales también terminan de inmediato.
Quitar a un miembro de SSO desde la página de Equipo es inmediato y definitivo. Borra su membresía, cierra sus sesiones en esa organización y elimina los tokens de API que tuviera para ella, así que también se para lo que tuviese automatizado. Además queda bloqueado para que el SSO no vuelva a crearle: su siguiente login a través de tu proveedor se rechaza en lugar de aprovisionarle otra vez en silencio. Volver a invitar a esa dirección desde la página de Equipo levanta el bloqueo cuando quieras recuperarle.
Sesiones y Cierre de Sesión
Las sesiones de SSO son cortas. Una sesión normal de CubePath dura un mes. Una sesión abierta por SSO dura unas ocho horas, y después la persona vuelve a autenticarse con tu proveedor. Eso es lo que hace que desactivar a alguien en tu directorio signifique algo aunque no configures nada más: el acceso termina en horas, y no cuando alguien se acuerda de limpiar.
El back-channel logout hace inmediato el cierre de sesión. Registra esta URL en tu proveedor de identidad y avisará a CubePath cada vez que un usuario cierre sesión o quede desactivado, para que sus sesiones de CubePath terminen al momento:
https://identity.cubepath.com/account/sso/backchannel-logout
Es opcional y todo funciona sin ello. Simplemente reduce la ventana de horas a segundos, que es lo que importa el día en que hace falta.
Cada login por SSO deja rastro. Aparece en el registro de actividad de tu organización, y el usuario recibe el mismo aviso de seguridad por correo que genera cualquier otro método de acceso, con el proveedor, la IP, la ubicación aproximada y la hora.
SSO y Doble Factor
CubePath no añade su propio 2FA encima de un login por SSO. Cuando alguien se autentica con tu proveedor de identidad, la plataforma no vuelve a pedir el código de su cuenta de CubePath.
El motivo es que tu proveedor es la autoridad en ese login. Ya ha decidido quién es el usuario bajo la política que tú apliques: MFA, llaves hardware, postura del dispositivo, acceso condicional. Un segundo factor gestionado aquí, encima de una decisión tomada allí, te deja con dos políticas que mantener sincronizadas y un peor resultado cuando una de las dos está mal.
La consecuencia práctica es directa: cuando adoptas SSO, el multifactor pasa a ser trabajo de tu proveedor de identidad. Aplícalo ahí. Las sesiones cortas y el back-channel logout son lo que mantiene a CubePath alineado con las decisiones que tomas en tu directorio.
Activar el SSO no desactiva los otros métodos de acceso. Las cuentas que ya tienen contraseña pueden seguir usándola, y el 2FA personal se sigue aplicando en esos logins. El SSO añade una vía de entrada para tu organización en lugar de cerrar las demás, así que si tu política es que todo el mundo pase por tu proveedor, hoy eso es un acuerdo que aplicas con tu equipo.
Qué Cubre el SSO Hoy
Ser útil aquí pasa por ser claro con los límites de la función.
Los miembros se crean al entrar, no se sincronizan desde tu directorio. No hay aprovisionamiento SCIM, así que tu lista de miembros en CubePath refleja a las personas que han entrado de verdad, no a todo el que existe en tu directorio. Cortar el acceso lo cubren las sesiones cortas, el back-channel logout y la página de Equipo, pero la lista en sí no es un espejo de tu directorio.
Los claims de grupo no se mapean a roles. Todo el mundo aprovisionado por SSO recibe el mismo rol por defecto que hayas configurado. Roles distintos para grupos distintos no es algo que hoy puedas expresar.
Un proveedor y un dominio verificado por organización. Si tu empresa entra desde varios dominios de correo, o quieres apuntar dos proveedores a la misma organización, eso todavía no está soportado.
La verificación del dominio pasa por soporte. Es un ticket y una comprobación humana en lugar de un botón, por diseño, porque es el paso del que depende todo lo demás.
La Forma del Trato
El SSO no hace desaparecer la gestión de accesos. Mueve la decisión al sistema que debería haberla estado tomando desde el principio, y hace que esa decisión valga donde las consecuencias son reales: servidores, redes, facturación, credenciales.
Lo que ganas a cambio del esfuerzo de configurarlo es concreto y merece la pena. La gente nueva llega con el rol correcto sin que nadie tenga que pedirlo. Quien se va pierde el acceso cuando lo dice tu directorio, no cuando alguien se acuerda. Nadie tiene una contraseña más que guardar mal. Y la respuesta a "¿quién puede entrar en nuestra cuenta de infraestructura?" pasa a ser la misma que la respuesta a "¿quién está en nuestro proveedor de identidad?", que es la única versión de esa pregunta que una empresa que crece puede seguir de verdad.
Si dar de alta a alguien en tu empresa significa hoy crear cuentas en seis sitios, esta es una buena candidata para quitar de la lista. Crea una aplicación OIDC en tu proveedor, pega el issuer, el client ID y el secret en Organización y luego SSO, prueba la conexión, y abre un ticket para verificar tu dominio.