# Inicio de sesión único (Workspace) > Demuestra que eres dueño de un dominio, conecta Google Workspace, proveedores OpenID Connect o SAML, asigna cada dominio verificado a una conexión, define la política de la organización, prueba las conexiones y, en Enterprise, exige SSO. **Inicio de sesión único** en el riel lateral del Workspace abre `/workspace/sso`. Los **propietarios** y **administradores** de la organización gestionan el inicio de sesión único de la organización activa; los **miembros** y **espectadores** ven un mensaje de permiso y no pueden leer ni cambiar nada de esto. El inicio de sesión único permite que las personas de tus dominios verificados entren a tu organización con su cuenta existente en su proveedor de identidad, en lugar de una contraseña de Probara. Una organización puede tener varias conexiones: como máximo una conexión de Google Workspace y cualquier número de proveedores OpenID Connect y SAML, como Okta o Microsoft Entra ID. Cada conexión atiende los dominios verificados que le asignas. En el plan Enterprise, también puedes requerirlo para toda la organización. ## Estado La sección **Estado**, al principio de la página, indica en qué punto está el inicio de sesión único y ofrece la acción que lo hace avanzar: reclamar un dominio, verificar un dominio pendiente o añadir una conexión. En un plan sin inicio de sesión único ofrece **Ver planes**. ## No disponible en todos los planes El inicio de sesión único es un derecho del plan con dos partes. **Pro** incluye las conexiones, los dominios verificados y el inicio de sesión de personas nuevas (**Añadir automáticamente a la organización a las personas nuevas que inicien sesión** y **Los nuevos inicios de sesión ingresan como**). **Enterprise** añade **Requerir SSO** y el límite de duración de la sesión. Si tu plan no lo incluye, la sección **Estado** muestra **El inicio de sesión único no está en tu plan** y el resto de la página pasa a ser de solo lectura: tus dominios, tu política y tus conexiones siguen visibles, sin los controles que los cambian. Cualquier dominio que ya hayas verificado y cualquier conexión que ya hayas configurado siguen visibles y legibles: perder el derecho nunca oculta ni borra tu configuración, solo pausa la posibilidad de cambiarla y detiene que **Requerir SSO** se aplique hasta que el derecho vuelva. En un plan sin exigencia, aún puedes desactivar **Requerir SSO**. ## Demuestra que eres dueño de un dominio Antes de que Probara permita que las personas de `example.com` inicien sesión a través de tu organización, tienes que demostrar que controlas `example.com`. 1. Ingresa el dominio y selecciona **Reclamar dominio**. Aparece en la lista con el estado **Pendiente** y un valor **TXT**. 2. Publica ese valor como registro `TXT` en el dominio raíz (`example.com`), desde tu proveedor de DNS. Probara solo lee ese nombre, así que un registro en un subdominio u otro nombre de host no se detecta. El contenido del registro debe ser exactamente el valor publicado. 3. Cuando el registro esté activo, selecciona **Verificar**. Cuando Probara lo lee correctamente, el dominio pasa a **Verificado**. Dos dominios no pueden tener a la vez el estado **Verificado** para el mismo nombre: la organización que lo demuestra primero lo conserva, y cualquier otro reclamo queda en **Pendiente**, sin más detalle sobre quién lo tiene. Probara no admite como dominios reclamables a los proveedores de correo públicos o gratuitos, como `gmail.com`, `outlook.com` o `icloud.com`, ni a sus subdominios. Reclama un dominio que tu organización posea. ### Verificar un dominio no toca las cuentas existentes Conviene decirlo con claridad, porque es el temor natural: **verificar un dominio no le da a tu organización ningún poder sobre las cuentas existentes en él.** No las absorbe, mueve, fusiona ni une automáticamente a nadie. No hace visible para ti ninguna cuenta existente de Probara, y no cambia cómo inicia sesión alguien fuera de tu organización. La verificación solo habilita el paso de conexión que sigue: no ocurre nada con una cuenta hasta que alguien inicia sesión realmente a través de ella. ### Quitar un dominio Selecciona **Quitar** en la fila del dominio y confirma. La organización deja de reclamar ese dominio. Quitar un dominio no cambia ninguna cuenta ni membresía en él, y la eliminación queda registrada en la actividad de la organización. Mientras **Requerir SSO** esté activo, no puedes quitar tu último dominio verificado. Desactiva antes la exigencia. ### Revisiones y dominios caducados Probara revisa cada dominio verificado aproximadamente una vez al día, buscando el registro TXT que publicaste. Una comprobación que no recibe respuesta del DNS no cuenta como fallo; solo una respuesta sin tu registro inicia el plazo. Cuando falta el registro, cada propietario y administrador recibe un correo con la fecha límite. Si el registro sigue sin aparecer siete días después del primer aviso, el dominio vuelve a **Pendiente** y la actividad registra que dejó de estar verificado. Hasta que lo vuelvas a verificar con el mismo registro, el inicio de sesión a través de tus conexiones no reconoce a las personas de ese dominio, y las cuentas de ese dominio no se vinculan por dominio. Si vuelves a publicar el registro dentro de los siete días, el dominio sigue verificado y no se envía ningún correo más. Si **Requerir SSO** está activo y el dominio que caduca es el último verificado, Probara desactiva **Requerir SSO** en ese mismo momento, lo registra en la actividad y envía un correo a cada propietario y administrador. Sin un dominio verificado nadie podría iniciar sesión mediante SSO, así que la exigencia dejaría a todos sin acceso. Los miembros pueden iniciar sesión con contraseña hasta que verifiques un dominio y vuelvas a activar la exigencia. Mientras quede otro dominio verificado, la exigencia sigue activa. ## Política de la organización Tres ajustes se aplican a toda la organización, sea cual sea su número de conexiones. Cámbialos en **Política de la organización** y selecciona **Guardar política**. | Ajuste | Efecto | | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Requerir SSO para esta organización** | Solo en Enterprise. Cuando está activado, todos deben entrar a esta organización a través de una de sus conexiones de inicio de sesión único. Cada dominio verificado debe estar atendido por una conexión. Consulta **Requerir SSO** más abajo. | | **Añadir automáticamente a la organización a las personas nuevas que inicien sesión** | Cuando está activado, una persona cuyo correo está en un dominio verificado y que inicia sesión por primera vez se une a tu organización automáticamente, con el rol predeterminado de abajo. Cuando está desactivado, primero hay que invitarla. | | **Los nuevos inicios de sesión ingresan como** | El rol que recibe una persona nueva al unirse mediante el inicio de sesión o mediante el aprovisionamiento SCIM. Cualquier rol excepto Propietario, incluidos tus roles personalizados. Un inicio de sesión nunca concede el rol de Propietario. El valor predeterminado es Espectador. | Al activar **Requerir SSO** se te pide confirmación primero, y la confirmación indica cuántos tokens de API personales y clientes MCP creados sin SSO se revocarán. ## Conexiones ### Añade una conexión Selecciona **Añadir conexión**. En el cuadro de diálogo que se abre, elige **Google Workspace**, **OpenID Connect** o **SAML**, escribe un **nombre** y selecciona **Conectar Google Workspace**, **Conectar OpenID Connect** o **Conectar SAML**. El nombre es lo que ven los administradores en esta lista y en el registro de actividad. Una organización tiene como máximo una conexión de Google Workspace. El cuadro de diálogo ofrece Google Workspace solo mientras tu organización no tenga ninguna; para otros proveedores de identidad, añade conexiones OpenID Connect o SAML. Puedes conectar antes de verificar un dominio, pero nadie podrá iniciar sesión con SSO hasta que un dominio verificado esté atendido por una conexión, y lo necesitas para activar **Requerir SSO**. ### Edita, prueba y quita una conexión La fila de cada conexión tiene tres acciones: - **Editar** abre los ajustes de la conexión en un cuadro de diálogo. Cambia el nombre, la duración máxima de sesión y, en OpenID Connect, los ajustes del proveedor. En SAML, lee antes [SAML](#saml). Selecciona **Guardar conexión**. - **Probar conexión** ejecuta el inicio de sesión de esa conexión (consulta **Probar conexión** más abajo). - **Quitar** elimina la conexión después de confirmar (consulta **Quitar una conexión** más abajo). ### Asigna dominios a las conexiones Cada dominio verificado muestra la conexión que lo atiende, como **Lo atiende** seguido del nombre de la conexión. Cómo obtiene un dominio su conexión depende de cuántas conexiones tengas: - Con una sola conexión, esa conexión atiende todos los dominios verificados que no hayas asignado a otra. No hay nada que asignar. - Con varias conexiones, cada dominio verificado lo atiende solo la conexión que elijas para él, desde el menú de su fila. Un dominio que ninguna conexión atiende muestra **Ninguna conexión lo atiende**. Mientras **Requerir SSO** esté activo, cada dominio verificado debe estar atendido por una conexión, así que Probara rechaza estos pasos hasta resolverlos: - activar **Requerir SSO** mientras un dominio verificado no esté atendido; - dejar un dominio verificado sin conexión; - quitar una conexión que atiende un dominio verificado, salvo que sea tu última conexión. Quitar tu última conexión desactiva **Requerir SSO**; - verificar un dominio nuevo mientras tu organización tenga varias conexiones. Desactiva **Requerir SSO**, verifica el dominio, asígnalo a una conexión y vuelve a activar **Requerir SSO**. Un dominio que caduca (consulta **Revisiones y dominios caducados**) deja de estar atendido hasta que lo verifiques de nuevo. ## Configura un proveedor ### Google Workspace Google Workspace no necesita credenciales tuyas. El propio cliente de Google de Probara atiende a todas las organizaciones, y el inicio de sesión admite solo cuentas de tus dominios verificados. Una cuenta de un dominio verificado que no tiene contraseña, como una que tu proveedor de identidad creó mediante SCIM, se vincula a su cuenta de Google en su primer inicio de sesión a través de tu organización. Una cuenta que sí tiene contraseña debe confirmar primero la vinculación. ### OpenID Connect OpenID Connect conecta cualquier proveedor que admita OpenID Connect con el flujo de código de autorización. 1. En tu proveedor, crea una aplicación web para OpenID Connect. Guarda su ID de cliente y su secreto de cliente. 2. En Probara, selecciona **Añadir conexión**, elige **OpenID Connect** e introduce el **nombre** (lo ven los administradores y aparece en el registro de actividad), la **URL del emisor** (la URL base del proveedor), el **ID de cliente** y el **secreto de cliente**. Los **ámbitos** tienen como valor predeterminado `openid email profile`; la lista debe incluir `openid`. 3. Selecciona **Conectar OpenID Connect**. 4. Copia la **URI de redirección** que muestra después la conexión y regístrala en las URI de redirección de inicio de sesión de tu proveedor. Después, ejecuta **Probar conexión**. #### URI de redirección Cuando la conexión existe, sus ajustes muestran su URI de redirección: la dirección de tu Probara, seguida de `/api/v1/auth/sso/`, el identificador de la conexión y `/callback`. Registra exactamente esa dirección, con el mismo esquema y host, en tu proveedor. Un valor distinto hace que el proveedor rechace el inicio de sesión. Cada conexión OpenID Connect tiene su propia URI de redirección. #### Secreto de cliente El secreto de cliente debe tener al menos 16 caracteres. Probara lo guarda cifrado, muestra solo sus últimos cuatro caracteres y nunca lo vuelve a mostrar. Para cambiarlo, escribe un secreto nuevo en **Reemplazar secreto de cliente**; un campo vacío conserva el guardado. Cambiar la URL del emisor exige un secreto de cliente nuevo. #### Okta Crea una integración de aplicación con **OIDC – OpenID Connect** y el tipo **Web Application**. Usa la URL del emisor de tu servidor de autorización, por ejemplo `https://tu-empresa.okta.com/oauth2/default`, como URL del emisor, y copia el ID de cliente y el secreto de cliente desde la aplicación. #### Microsoft Entra ID En el centro de administración de Microsoft Entra, registra una aplicación en **Registros de aplicaciones**, añade la URI de redirección en la plataforma **Web** y crea un secreto de cliente en **Certificados y secretos**. Copia el **Id. de aplicación (cliente)** y usa `https://login.microsoftonline.com//v2.0` como URL del emisor. Entra envía una dirección de correo en el token de inicio de sesión solo si la añades. En **Configuración de tokens**, añade estas notificaciones opcionales al token de ID: - `email`, la dirección con la que Probara identifica a una persona; - `xms_edov`, la marca de dominio verificado de Entra. Probara vincula una cuenta existente a un inicio de sesión solo cuando el correo está verificado o `xms_edov` es verdadero. Sin ninguno de los dos, el inicio de sesión se rechaza y la cuenta no cambia. #### Otros proveedores Cualquier proveedor que publique su configuración en `/.well-known/openid-configuration` y envíe una notificación `email` funciona de la misma manera. Probara lee `email_verified` para decidir si una cuenta existente puede vincularse, como hace con `xms_edov` de Entra. ### SAML SAML conecta un proveedor de identidad que inicia sesión a las personas con SAML 2.0, como Okta o Microsoft Entra ID. Probara actúa como proveedor de servicio. Tu proveedor de identidad necesita los valores que Probara muestra una vez guardada la conexión. #### Qué introducir en Probara Elige un origen. Probara lee la configuración del proveedor de identidad desde él al guardar: | Origen | Introduce | Nota | | ------------------------------ | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Desde una URL de metadatos** | La dirección de los metadatos. | HTTPS, y que responda sin redirecciones. La URL de metadatos de la aplicación de Entra funciona. | | **Desde el XML de metadatos** | El documento de metadatos. | Probara lo lee una vez, al guardar. | | **Introducir manualmente** | El **ID de entidad**, la **URL de inicio de sesión único** (HTTPS) y el **certificado de firma**. | Añade un **segundo certificado de firma** solo mientras el proveedor rota su clave (véase abajo). | Probara conserva el ID de entidad, la dirección de inicio de sesión, los certificados y la dirección de los metadatos. No conserva el documento de metadatos. Probara rechaza las direcciones que nombran una red privada o local, como `localhost`, una dirección IP privada o un host `.local` o `.internal`. #### Configúralo en este orden Los valores del proveedor de servicio (la URL de ACS, el ID de entidad del SP y la URL de metadatos del SP) existen solo después de guardar la conexión, igual que la URI de redirección de OpenID Connect. Por eso el orden es este: 1. En tu proveedor de identidad, crea una aplicación SAML. Si te pide la URL de ACS, el ID de entidad o la URL de metadatos antes de tenerlos, escribe cualquier dirección HTTPS como marcador. 2. Copia la URL de metadatos o el XML de metadatos del proveedor de identidad, o anota su ID de entidad, su URL de inicio de sesión y su certificado de firma. 3. En Probara, selecciona **Añadir conexión**, elige **SAML**, escribe un **nombre**, elige un origen e introdúcelo, y selecciona **Conectar SAML**. 4. En la conexión, copia la **URL de ACS** y el **ID de entidad del SP** en tu proveedor de identidad, sustituyendo los marcadores. Algunos proveedores piden en su lugar la **URL de metadatos del SP**: es la misma dirección que el ID de entidad del SP. 5. Selecciona **Probar conexión**. #### Okta Crea una integración de aplicación con el método de inicio de sesión **SAML 2.0**. Define **Single sign-on URL** como la URL de ACS y **Audience URI (SP Entity ID)** como el ID de entidad del SP. Define **Name ID format** como correo electrónico y **Application username** como correo, para que el NameID lleve el correo de la persona. Para los valores del proveedor de identidad, usa la URL de metadatos que Okta publica para la aplicación. Para el origen manual, usa su **Identity Provider Issuer** (el ID de entidad), su **Identity Provider Single Sign-On URL** y su certificado de firma. #### Microsoft Entra ID Añade una aplicación empresarial con su propio inicio de sesión único de SAML. Define **Identifier (Entity ID)** como el ID de entidad del SP y **Reply URL (Assertion Consumer Service URL)** como la URL de ACS. En **User Attributes & Claims**, haz que el NameID lleve la dirección de correo, o añade una notificación de correo. Para los valores del proveedor de identidad, usa **App Federation Metadata Url** como URL de metadatos. Para el origen manual, usa **Microsoft Entra Identifier** como ID de entidad, **Login URL** como URL de inicio de sesión único y el certificado de firma activo. Los nombres son los de la consola en inglés; si tu consola está en español, busca su equivalente. #### Firma de las aserciones Mantén activada la firma de la aserción en el proveedor. Probara acepta solo una respuesta cuya aserción lleve la firma del proveedor de identidad. Ignora los certificados que la respuesta nombre dentro de ella, así que solo confía en los certificados que introdujiste o en los metadatos que diste. #### Correo electrónico Probara reconoce a una persona que vuelve por el NameID que envía esta conexión, y usa el correo la primera vez para encontrar su cuenta o crearla. Usa un NameID persistente o con formato de dirección de correo: un NameID que cambia en cada inicio de sesión (transitorio) solo sirve para el primero. Probara lee el correo del NameID cuando su formato es una dirección de correo; si no, lee el primero de estos atributos que encuentre: `email`, `mail` o la notificación estándar `emailaddress`. Una respuesta sin correo utilizable se rechaza, y el resultado de la prueba lo indica. El correo debe estar en un dominio verificado de tu organización, como con los demás proveedores. Probara considera verificado el correo de una respuesta firmada, y el resultado de la prueba lo muestra así. #### Dos certificados para la rotación Añade el siguiente certificado en **Segundo certificado de firma (opcional)** antes de que venza el actual. Probara acepta una respuesta firmada con cualquiera de los dos certificados guardados. Cuando el proveedor haya pasado a la clave nueva, guarda la conexión de nuevo en **Introducir manualmente** con solo el certificado nuevo. Probara rechaza un certificado que ya ha vencido. #### Inicio de sesión iniciado en el proveedor de identidad **Permitir el inicio de sesión iniciado en el proveedor de identidad** está desactivado por defecto. Permite empezar desde el icono de la aplicación en el proveedor. La contrapartida: no existe una solicitud de inicio de sesión de Probara para ese inicio, así que Probara no puede vincularlo al navegador que lo empezó. Probara sigue comprobando la firma, la audiencia, la ventana de tiempo y que la respuesta no se haya usado antes. Después de ese inicio, Probara abre solo una página dentro de Probara. Actívalo solo si tu proveedor lo necesita. #### Configuración guardada y cambios Al editar una conexión SAML se muestran su ID de entidad, su dirección de inicio de sesión, su dirección de metadatos, la huella SHA-256 y la fecha de vencimiento de cada certificado, y el ajuste de inicio iniciado en el proveedor. Probara nunca muestra el texto de un certificado. Cambiar solo el nombre o el ajuste de inicio iniciado en el proveedor conserva la configuración guardada del proveedor de identidad. Para reemplazarla, elige un origen e introdúcela de nuevo. #### No compatible - **Aserciones cifradas.** Desactiva el cifrado de aserciones en el proveedor. - **Solicitudes de inicio de sesión firmadas.** Probara las envía sin firmar. - **Cierre de sesión único.** Cerrar sesión en el proveedor no termina la sesión de Probara. ## Probar conexión Selecciona **Probar conexión** en la fila de una conexión para ejecutar el inicio de sesión de ese proveedor sin iniciar tu sesión ni cambiar ningún miembro. Probara abre el proveedor, y el resultado aparece en su propia página, que indica qué conexión se probó: - **El inicio de sesión funcionaría**: la cuenta ya está vinculada a un miembro de la organización. - **La cuenta existente se vincularía**: un correo verificado coincide con una cuenta que ya existe en Probara. - **Se crearía un miembro nuevo**: ninguna cuenta coincide, y la persona entraría con el rol predeterminado. - **El inicio de sesión se rechazaría**: con el motivo, por ejemplo un correo que el proveedor no verificó o una notificación de correo que no envió. La página también enumera las notificaciones que envió el proveedor: el emisor, el sujeto, el correo y si está verificado, además de las notificaciones propias del proveedor, como `xms_edov` de Entra. Ningún token, código ni secreto se muestra ni se guarda. El resultado se conserva durante diez minutos, y solo el administrador que inició la prueba puede leerlo. Después de ese tiempo, o desde otra sesión, la página indica que el resultado caducó, y tienes que volver a probar. Cada prueba queda registrada en el registro de actividad. ## SSO en la página de inicio de sesión Las personas que prefieren no usar contraseña pueden seleccionar **SSO** en la página de inicio de sesión. Se abre una página propia, donde introducen su correo de trabajo. Si ese dominio lo verifica una organización con una conexión, Probara las lleva al inicio de sesión de la organización y después a la página a la que iban. Si no, la página indica que no encontró inicio de sesión único para esa dirección y sugiere entrar con contraseña o pedirlo a un administrador. La página nunca muestra el nombre de la organización. En esa página, **Volver al inicio de sesión** regresa a la página de inicio de sesión. La búsqueda tiene un límite de frecuencia. Cuando se alcanza, la página pide que se intente de nuevo en unos minutos. ## Dirección de inicio de sesión Cuando existe una conexión, la pantalla muestra la dirección de inicio de sesión de tu organización: la dirección de tu aplicación Probara, seguida de `/sso/` y del identificador de la organización. Cópiala con el control de copia y compártela con tus personas. Al abrir la dirección se inicia el inicio de sesión de tu organización. Con una conexión, la página ofrece el botón de inicio de sesión de esa conexión. Con varias conexiones, la página pide el correo de trabajo de la persona y continúa con la conexión que atiende el dominio de ese correo; nunca enumera los proveedores de identidad. La dirección se oculta mientras tu plan no incluya el inicio de sesión único, porque entonces no está disponible. ## Quitar una conexión Selecciona **Quitar** en la fila de la conexión y confirma. El inicio de sesión a través de esa conexión se detiene, sus dominios dejan de estar atendidos por ella, y las cuentas y las membresías no cambian. Puedes volver a añadir la conexión más adelante. Mientras **Requerir SSO para esta organización** esté activo, solo el propietario, o alguien que pueda gestionar el SSO y haya iniciado sesión a través de una de las conexiones de esta organización, puede quitar una conexión. Cualquier otra persona recibe un rechazo, y la pantalla muestra el motivo. Quitar una conexión mientras la exigencia está desactivada no necesita ese inicio de sesión. ## Requerir SSO Requerir SSO necesita el plan Enterprise. En los demás planes, aún puedes desactivarlo. Activar **Requerir SSO para esta organización** es el ajuste más estricto de esta pantalla: a partir de ese momento, una sesión autenticada con contraseña no puede llegar a esta organización en absoluto; solo una sesión creada al iniciar sesión a través de una de las conexiones propias de esta organización. Iniciar sesión en tu cuenta, y en cualquier otra organización a la que pertenezcas, no se ve afectado en absoluto: este ajuste solo gobierna el acceso a _esta_ organización. Una sesión con contraseña que abra una organización que requiere SSO se envía a la página de inicio de sesión de esa organización. Esa página enumera las otras organizaciones a las que perteneces y que no requieren SSO, para que puedas cambiar a una, y ofrece cerrar sesión. Tu perfil y tus tokens de API siguen accesibles en todo momento. Cuando Probara abre una organización por ti, en un dispositivo nuevo o cuando ya no perteneces a la que usaste la última vez, abre una que no requiere SSO. Solo abre una que requiere SSO cuando todas las organizaciones a las que perteneces lo requieren, o cuando eliges esa organización tú mismo. **No puedes bloquearte a ti mismo.** Activar la exigencia **no** se permite a menos que tu sesión actual se haya creado iniciando sesión a través de una de las conexiones de esta organización, así que la plataforma no te deja activarla desde una sesión con contraseña. Tampoco se permite mientras un dominio verificado no esté atendido por una conexión, ni mientras tu organización no tenga ningún dominio verificado, porque nadie podría iniciar sesión con SSO sin uno. El orden para configurarlo es, por tanto: 1. Verifica un dominio. 2. Añade una conexión, asigna el dominio a ella y deja **Requerir SSO** desactivado. 3. Inicia sesión al menos una vez a través del flujo de SSO propio de esta organización. 4. Ahora activa la exigencia desde esa sesión autenticada con SSO. Si el interruptor se rechaza, la pantalla muestra el motivo y devuelve el interruptor a su valor anterior: nunca ignora el rechazo en silencio. Desactivar la exigencia, y quitar una conexión mientras la exigencia está activa, necesitan que sea el **propietario** de la organización con cualquier tipo de sesión, o alguien que pueda gestionar el SSO y haya iniciado sesión a través de una de las conexiones propias de esta organización. Un administrador con sesión por contraseña recibe un rechazo, y la pantalla muestra el motivo. Entonces, cada propietario y administrador recibe un correo con lo que cambió, quién lo cambió y cuándo, y cómo volver a requerir SSO. Quitar una conexión mientras la exigencia está desactivada no necesita ese inicio de sesión: cualquiera que pueda gestionar el SSO, por defecto propietarios y administradores, puede quitarla con cualquier sesión, y no se envía ningún correo. Si no puedes usar el interruptor por algún motivo, el personal de Probara también puede revocar un dominio verificado o restaurar tu acceso como medida de emergencia: contacta con soporte. **Activar la exigencia revoca el acceso creado fuera de SSO.** En ese momento, todo token de API personal y toda conexión MCP u OAuth creada desde una sesión que no pasó por el SSO de esta organización se revoca, y su siguiente petición se rechaza. La confirmación indica cuántos antes de que confirmes. Los tokens y conexiones creados a través del SSO de esta organización siguen funcionando. Los tokens de apps de CI son credenciales de la organización para tus integraciones, así que no se revocan y siguen funcionando. Desactivar la exigencia no restaura una credencial revocada: crea una nueva. ## Duración de la sesión Cada conexión tiene su propio campo **Duración máxima de la sesión (horas)**. Define cuánto tiempo sigue siendo válida una sesión que inició sesión a través de esa conexión mientras **Requerir SSO para esta organización** está activo, lo que necesita el plan Enterprise. Escribe un número entero de horas de 1 a 720, o deja el campo vacío para no tener más límite que la duración de sesión de la plataforma. Cuando se supera el límite, esta organización rechaza la sesión, y el siguiente inicio de sesión a través de SSO crea una nueva. Una sesión que supera el límite tampoco puede crear tokens de API personales ni conexiones OAuth para esta organización. El límite no tiene efecto mientras **Requerir SSO** esté desactivado, y no se aplica a una sesión de emergencia del propietario (consulta más abajo). ## Acceso de emergencia del propietario Si el inicio de sesión único no está disponible, el propietario puede entrar a una organización que requiere SSO durante una hora, sin SSO: 1. Abre la página de inicio de sesión de la organización. Solo el propietario de la organización ve la sección **Acceso de emergencia del propietario** allí. 2. Introduce un código de tu aplicación de autenticación, o uno de tus códigos de recuperación, y continúa. El propietario necesita tener activada la autenticación en dos pasos en su cuenta. Los miembros y administradores nunca ven esta opción. Mientras dura el acceso, el propietario puede abrir esta organización y sus datos, y puede desactivar **Requerir SSO**. No la activa, y no crea tokens de API personales ni conexiones OAuth para esta organización: esos siguen necesitando una sesión que haya iniciado sesión a través de SSO. Para cambiar otros ajustes de SSO durante el acceso, desactiva antes **Requerir SSO**: guardar con la exigencia activa sigue necesitando una sesión que haya iniciado sesión a través de SSO. El acceso termina después de una hora, al cerrar sesión o al transferir la propiedad. Cada propietario y administrador recibe un correo cuando se usa el acceso, con quién lo usó y cuándo termina. Un propietario puede probar como máximo cinco códigos por hora, y cada intento también cuenta para el límite de dos pasos de la cuenta de cinco códigos cada 15 minutos. Tras cualquiera de los dos límites, los intentos se rechazan hasta que se reinicie.