Sesiones y entrada#
Esta página explica cuánto dura una sesión de Empowerment Center, cuándo se cierra sola y cómo frena ECenter a quien prueba contraseñas. Todo se ajusta con variables de entorno o propiedades del servidor.
Antes de empezar#
- Las variables y propiedades se ponen en la configuración del servidor (el fichero de entorno o el
application.ymlpropio; vea Configuración). Hace falta reiniciar el servidor para que cambien. - Para ver y cerrar las sesiones abiertas, la consola de operación, con Administración del Sistema (vea Operación).
Cómo se entra#
En la pantalla de entrada el usuario escribe su Usuario y su Contraseña y pulsa Iniciar sesión, o pulsa Continuar con … si la instalación tiene un proveedor de identidad configurado (vea Inicio de sesión único). El login no distingue mayúsculas.
Si el usuario o la contraseña no son correctos, o el usuario no está habilitado, la pantalla dice solo «Usuario o contraseña incorrectos.»: no revela cuál de las dos cosas falla ni si el usuario existe.
El primer administrador#
En una instalación nueva no hay usuarios. Al arrancar, si la base de datos no tiene ningún usuario, ECenter crea uno con Administración del Sistema con el login y la contraseña de ECENTER_ADMIN_LOGIN y ECENTER_ADMIN_PASSWORD. Después esas variables no hacen nada y se pueden quitar. No hay ningún usuario ni contraseña fijos de fábrica.
Duración de las sesiones#
Las sesiones se guardan en la base de datos propia de ECenter: sobreviven a un reinicio del servidor y valen en cualquier instancia si hay varias. El navegador las lleva en una cookie SESSION que no lee el código de la página (HttpOnly) ni se envía desde otros sitios (SameSite=Lax).
| Variable | Por defecto | Qué hace |
|---|---|---|
ECENTER_SESSION_TIMEOUT |
30m |
Tiempo sin actividad tras el que caduca la sesión. |
ECENTER_SESSION_MAX_DURATION |
12h |
Duración máxima desde que se entró, aunque se siga usando. Pasado ese tiempo, la siguiente petición acaba la sesión y el usuario tiene que volver a entrar. 0 quita el máximo. |
Con el SSO, volver a entrar tras una caducidad no pide nada si la sesión del proveedor sigue abierta.
Nota
Las sesiones de un documento incrustado en otra aplicación y las credenciales de servicio (API, MCP, SCIM) tienen sus propias reglas de duración. Vea Integraciones.
Cuándo se cierran solas#
Además de por caducidad, ECenter cierra en el acto todas las sesiones de un usuario cuando:
- se le inhabilita, se le bloquea o se le elimina;
- se le cambia el login;
- un administrador le cambia o le pone la contraseña (si la cambia el propio usuario desde Cambiar contraseña…, se cierran las demás y sigue en la que usa);
- pierde Administración del Sistema (por quitarle el rol, quitársela a su rol o inhabilitarlo);
- pierde un rol que le daba el proveedor de identidad por un grupo del directorio.
La siguiente petición de esa sesión recibe un «no autorizado» y el usuario vuelve a la pantalla de entrada. Los demás cambios de roles o privilegios se aplican en su siguiente inicio de sesión.
Sesiones caducadas y auditoría#
El servidor borra las sesiones caducadas cada minuto y deja en la auditoría una entrada Sesión caducada por cada una, con el usuario. Una sesión cerrada por un cambio en su usuario que se vuelve a usar también queda como Sesión caducada, con el motivo «se había cerrado por un cambio en el usuario», y no como una salida.
| Propiedad | Por defecto | Qué hace |
|---|---|---|
ecenter.security.sessions.cleanup-interval |
1m |
Cada cuánto se borran las sesiones caducadas. |
ecenter.security.sessions.cleanup-enabled |
true |
Con false no las borra nadie: no lo cambie en producción. |
Las entradas, las salidas, los intentos fallidos y las sesiones caducadas se consultan en la categoría Accesos de la Auditoría.
Retardo tras intentos fallidos#
ECenter no bloquea cuentas por intentos fallidos: impone un retardo creciente entre intentos con un mismo login. Así frena a quien prueba contraseñas sin dejar fuera al usuario legítimo.
Con la configuración por defecto:
- Los 3 primeros fallos seguidos no tienen retardo.
- Tras el cuarto, hay que esperar 1 s antes del siguiente intento.
- La espera se duplica con cada fallo (2 s, 4 s, 8 s…) hasta un máximo de 60 s.
- Un fallo de hace más de 1 h ya no cuenta. Un acierto borra los fallos.
Mientras dura la espera, el botón de la pantalla de entrada se queda desactivado con la cuenta atrás («Espere N s») y el mensaje dice «Demasiados intentos seguidos. Podrá volver a intentarlo en N s.». Esos intentos no se comprueban ni alargan la espera.
El retardo:
- va por login, no por dirección de red, porque detrás de un proxy la dirección no es fiable;
- se aplica igual a los logins que no existen, para no revelar cuáles existen;
- vale para todas las instancias, porque los fallos se guardan en la base de datos;
- no afecta a la entrada con el proveedor de identidad, que tiene sus propios controles;
- frena también a quien cambia su propia contraseña: cada contraseña actual equivocada cuenta como un fallo de su login.
| Propiedad | Por defecto | Qué hace |
|---|---|---|
ecenter.security.login-delay.free-attempts |
3 |
Fallos seguidos sin retardo. |
ecenter.security.login-delay.initial |
1s |
Primera espera. |
ecenter.security.login-delay.max |
60s |
Espera máxima. |
ecenter.security.login-delay.reset-after |
1h |
Tiempo tras el que se olvida un fallo. No puede ser menor que max. |
Como variables de entorno se escriben en mayúsculas, sin guiones y con guiones bajos en lugar de puntos: ECENTER_SECURITY_LOGINDELAY_FREEATTEMPTS, ECENTER_SECURITY_LOGINDELAY_MAX…
Cada fallo queda en la auditoría con su motivo. Los intentos rechazados por el retardo se anotan uno por login y minuto, para que una ráfaga no llene el registro.
Consejo
Si un usuario dice que no puede entrar y espera cada vez más, compruebe en la auditoría si alguien está probando contraseñas con su login. Si sospecha de un ataque, bloquee la cuenta desde Usuarios y roles y cámbiele la contraseña.
La contraseña#
- Tiene que tener al menos 10 caracteres y como mucho 72 bytes (72 caracteres sin acentos, menos si lleva eñes o acentos).
- No puede estar en blanco.
- Distingue mayúsculas y minúsculas.
- Se guarda solo su huella (BCrypt), nunca la contraseña.
La pone un administrador de usuarios (vea Usuarios) y la cambia también el propio usuario, con Cambiar contraseña… en el menú de su cuenta.
Las contraseñas de los usuarios importados de EC7 se conservan aunque no cumplan esta política: se exigirá al cambiarlas.