Acceso e Identidad
Para qué sirve esta pantalla
Acceso e Identidad es donde tu despliegue decide quién puede iniciar sesión y cuánto tiempo sigue confiando en ella: cada cuánto rota la clave que firma sus tokens, cuánto sirve un enlace de activación o de restablecimiento, los orígenes de navegador autorizados a llamar a la plataforma, cuándo una racha de inicios de sesión fallidos bloquea una cuenta y cuánto vive una sesión recordada. La entrada del menú lateral abre este grupo; sus cinco entradas — JWT, Ciclo de Vida de Cuenta, Bloqueo y Anti-Abuso, CORS y Sesiones y Cookies — abren cada una una sección de lo descrito abajo.
Hay otras cuatro entradas en este grupo que no son ajustes: Federación de Identidad y Federación de Identidad de Cargas de Trabajo son subsistemas con pantalla propia, ciclo de vida propio y página propia aquí, Metadatos de claves de acceso guarda el archivo de metadatos de FIDO con el que se verifica la certificación de las claves de acceso, y Política de autenticación decide cómo inician sesión los administradores de la plataforma y qué métodos de inicio de sesión puede admitir cada tenant.
Qué debe existir antes
Llegas a esta superficie en el contexto de plataforma. Toda solicitud detrás de ella se rechaza si tu token no lleva el tenant de plataforma, y el rechazo dice solo "Forbidden": nunca indica qué tenant ni qué permiso estaba mal.
- El permiso de lectura de la configuración de plataforma llena estas listas. Sin él, la consola todavía te admite si tienes un permiso de auditoría o uno que alcance alguna hoja autónoma, y entonces las secciones de abajo dicen que la configuración no está disponible para ti en lugar de mostrarte una tabla vacía.
- El permiso de escritura de la configuración de plataforma habilita Editar. Sin él, cada fila se lee y ninguna se edita.
- Una fila — el atributo SameSite de la cookie de refresco — está clasificada como PELIGROSA y necesita además el permiso de cambios peligrosos. La pantalla te pide escribir la clave del ajuste antes de habilitar Guardar, y la plataforma rechaza la escritura sin ese segundo permiso, hayas escrito la clave o no.
Decisiones que tomas aquí
Cada fila muestra su valor efectivo, de dónde viene ese valor y una insignia por cada servicio al que alcanza. Una fila que la plataforma no te deja cambiar lleva un candado y un motivo. Junto a cada fila está lo que ocurre cuando la cambias: En vivo — se aplica al instante en todas las instancias, Requiere reinicio, Diagnóstico de solo lectura o Propiedad del despliegue — se establece en el entorno y se aplica al redesplegar. Lee esa línea antes que el valor: es la diferencia entre un cambio que surte efecto ahora y otro que espera a un redespliegue que tendrás que hacer tú.
JWT
Once filas y exactamente una decisión. Diez son las claves del par de activación de cuentas y de los cuatro pares de servicio a servicio, custodiadas como secretos del despliegue, mostradas enmascaradas y nunca reveladas por esta pantalla ni por la plataforma que hay detrás. La clave que firma los tokens de acceso de usuario no está entre ellas: no es un secreto del despliegue, y la ves — y la rotas o la revocas — en Claves de firma de tokens, dentro de Criptografía y Confianza.
La decisión es el período de rotación de la clave de firma de tokens: la antigüedad, en días, a la que la plataforma rota la clave que firma los tokens de acceso de usuario. Su valor predeterminado es 90 y admite de 1 a 365. El cambio es en vivo y se aplica en la siguiente comprobación programada.
Una rotación nunca cierra la sesión de nadie: la clave siguiente se publica antes de empezar a firmar, y la clave retirada sigue publicada hasta que vence cada token que firmó. Por eso el período solo limita cuánto tiempo firma una misma clave — y, con ello, cuánto podría falsificar una clave filtrada antes de ser sustituida. Un período más largo no cambia nada para los usuarios. No lo acortes para responder a una sospecha de compromiso: revoca la clave.
Ciclo de Vida de Cuenta
Tres decisiones, todas en vivo, más dos filas de solo lectura que informan las URL públicas con las que se construyen los enlaces de activación y de restablecimiento.
La profundidad del historial de contraseñas es cuántos hashes anteriores se conservan para impedir la reutilización. Su valor predeterminado es 5 y admite de 3 a 24. Bajarlo es destructivo y no se puede deshacer: el historial sobrante se poda en el siguiente cambio de contraseña de cada usuario, así que la comprobación de reutilización pierde para siempre contraseñas que antes podía rechazar, y restaurar el número anterior no las devuelve. Subirlo cuesta unas pocas filas por usuario.
La validez del token de activación (horas, predeterminado 24, rango de 1 a 168) y la validez del token de restablecimiento (minutos, predeterminado 60, rango de 5 a 1440) son el mismo juicio: cuánto tiempo un enlace que llega a un buzón sigue canjeable para quien lo lea. Un token de activación vencido no revive: se necesita otra invitación. El valor de restablecimiento rige además el registro de un solo uso que impide reproducir el enlace y la validez que anuncia el correo: un número demasiado pequeño vence los enlaces antes de abrirse y a la vez debilita la protección contra reproducción.
Bloqueo y Anti-Abuso
Cuatro valores que solo tienen sentido leídos juntos, todos en vivo. Los inicios de sesión fallidos se cuentan por autenticador: una contraseña o un código TOTP por red cliente, un código de recuperación o una passkey por cuenta. El bloqueo de uno nunca rechaza otro, así que las contraseñas erróneas nunca bloquean una passkey ni un proveedor de identidad.
El máximo de intentos (predeterminado 5, rango de 1 a 100) es cuántos fallos de un autenticador lo bloquean. El máximo de intentos de la cuenta (predeterminado 20, rango de 5 a 100) cuenta las contraseñas y los códigos TOTP erróneos desde redes desde las que la persona no inició sesión en los últimos 30 días; su bloqueo rechaza ambos solo desde esas redes. La ventana (predeterminada 15 minutos, rango de 1 a 1440) es el periodo hacia atrás sobre el que se cuentan los fallos. La duración (predeterminada 15 minutos, rango de 1 a 1440) es cuánto dura un bloqueo.
Si acortas demasiado la ventana, un atacante paciente nunca llega al techo, porque los fallos antiguos van envejeciendo y saliendo de la cuenta, y el bloqueo deja de dispararse en la práctica. Si la alargas, fallos sin relación de hace horas se acumulan en un bloqueo para un usuario legítimo. Un autenticador bloqueado no se desbloquea usándolo correctamente, porque se rechaza mientras el bloqueo existe: la persona inicia sesión con otro, o espera; así que una duración larga se mide en tickets de soporte.
Cada bloqueo queda registrado en el rastro de auditoría. Cuando los avisos de bloqueo están activados, la persona recibe como máximo un correo por duración de bloqueo para el bloqueo de un autenticador (el aviso previo a un bloqueo cuenta como ese único correo), y uno cuando se bloquea el máximo de la cuenta.
CORS
Aquí no hay nada editable desde esta pantalla, y ese es el motivo para leerla. Una fila informa si las aplicaciones manejan CORS. Las otras dos — los orígenes de navegador permitidos y las cabeceras de respuesta expuestas al JavaScript del navegador — son propiedad del despliegue: se cambian en el entorno y se aplican al redesplegar. La pantalla nombra la variable de cada una.
Enumera con exactitud cada origen que deba alcanzar la plataforma. El CORS con credenciales prohíbe los comodines, así que un valor que contenga uno — o un valor vacío — hace que los servicios se nieguen a arrancar en lugar de caer en algo permisivo. Omitir un origen legítimo falla al revés: todo arranca limpio y la consola se rompe solo en el navegador. Fíjate también en lo que no aplica esto: el proxy de borde ni lee estos valores ni emite ninguna cabecera CORS. Lo hace el filtro de cada aplicación, y por eso el cambio espera a que esos servicios reinicien.
Sesiones y Cookies
Siete filas. Cinco acotan toda sesión iniciada y se aplican en vivo; una fija qué tan reciente debe ser un inicio de sesión para las acciones sensibles; la última se comporta de forma distinta a propósito.
La duración máxima de la sesión (minutos, predeterminado 720, rango de 60 a 1440) es lo más que dura una sesión desde el inicio de sesión original; ningún refresco, cambio de tenant ni Recordarme la extiende. La inactividad máxima (predeterminado 30, rango de 15 a 60) termina una sesión que nadie ha usado durante ese tiempo.
Recordarme (activado de forma predeterminada) permite que un inicio de sesión conserve su sesión al reiniciar el navegador, con su propia inactividad máxima (predeterminado 720, rango de 15 a 1440), nunca más allá de la duración máxima. La gracia de reutilización del refresco (segundos, predeterminado 10, rango de 0 a 60) tolera que dos pestañas refresquen a la vez; un token antiguo presentado después termina la sesión completa. Un valor fuera de su rango se rechaza.
La ventana de reautenticación (segundos, predeterminado 300, rango de 60 a 900) indica qué tan reciente debe ser la última confirmación de identidad de una persona para las acciones sensibles: cambiar sus propias credenciales, proveedores de identidad, dominios, vínculos federados o la postura de autenticación, reparar la cuenta de una persona o designar un administrador de tenant desde la plataforma, autorizar el acceso de soporte, decidir una solicitud de quórum y entrar en un tenant como operador de plataforma.
Si es más antigua, se pide a la persona que vuelva a confirmar su identidad. Se aplica en vivo, y ningún valor desactiva el requisito.
El atributo SameSite de la cookie de refresco es la fila PELIGROSA y requiere reinicio. Admite Lax, None o Strict, su predeterminado es Lax y vuelve a Lax si se retira la anulación. None permite que el navegador adjunte la cookie de refresco a solicitudes originadas en cualquier otro sitio, la condición previa de la falsificación de solicitudes entre sitios contra el refresco de sesión. Strict tiene su propio fallo: la cookie no se devuelve tras una redirección entre sitios, así que un inicio de sesión federado que vuelve desde un proveedor de identidad externo pierde la sesión.
Cómo se relaciona con otras pantallas
El inicio de sesión federado, las identidades de máquina y la certificación de las claves de acceso se configuran desde las otras tres entradas de este mismo grupo, no desde las filas de arriba:
Quiénes son las cuentas, qué pueden hacer y qué tokens tienen se administran en otro sitio:
Las claves que gobierna el período de rotación, y las acciones que rotan o revocan una de inmediato:
Dónde leer más
Estas páginas están en inglés: