Autenticación y seguridad, incluido SSO

De fábrica, todo el mundo inicia sesión con un nombre de usuario y una contraseña. La dirección de correo sirve en lugar del nombre de usuario. Si el envío de correo está configurado, debajo del formulario aparece el enlace «Do you need a password reset?». El envío de correo forma parte de Professional.

Tras iniciar sesión, el navegador recibe un pase válido durante un tiempo determinado. La tarjeta «JWT token timer» decide cuánto. Se admiten valores de 1 a 24 horas; se recomiendan 12. Después hay que volver a iniciar sesión.

La tarjeta «Password policy» se aplica a cada contraseña que se define en el sistema. Se exige al crear una cuenta, cuando alguien cambia su propia contraseña y cuando un administrador la restablece.

Defines la longitud mínima, qué tipos de caracteres deben aparecer, al cabo de cuántos días caduca una contraseña y cuántas contraseñas antiguas quedan bloqueadas. En los días y en la lista de bloqueo, 0 significa «desactivado».

Las reglas sobre mayúsculas y minúsculas no dejan fuera a ningún idioma. Muchos sistemas de escritura no distinguen entre ellas, y un carácter de uno de esos sistemas cumple por sí solo ambas reglas.

Las cuentas que solo inician sesión mediante SSO o un directorio no tienen contraseña local, así que la caducidad no se les aplica. Sus reglas están en el proveedor. Si una cuenta existente se vinculó a SSO y aún tiene contraseña propia, la caducidad y la política de contraseñas siguen aplicándose a esa contraseña.

La tarjeta «2FA Settings» decide quién tiene que usar el inicio de sesión en dos pasos. En «Two-factor requirement» eliges uno de cuatro niveles: «Off», «Administrators only», «Administrators and agents» o «Everyone». «Everyone» incluye a los clientes. Una instalación nueva empieza con «Administrators only». Una instalación que ya existía conserva su ajuste anterior tras una actualización.

Quien inicie sesión a continuación sin un segundo factor lo configura. El sistema muestra un código QR para una aplicación de autenticación y la misma clave para teclearla a mano. Tras el primer código, el factor queda activo. Con «Set up later» la configuración se puede aplazar, y el inicio de sesión sigue sin ella. Eso funciona como máximo 7 días, contados desde el primer aplazamiento. La línea bajo el botón muestra los días que quedan. Después, la configuración es obligatoria.

Justo después aparecen diez códigos de recuperación. Cada uno sustituye una vez al código de la aplicación. Se muestran exactamente una vez. Los guardas con «Copy» o «Download». «Download» funciona siempre. «Copy» suele funcionar también.

Si alguien pierde su dispositivo y sus códigos, le ayuda el administrador. En la lista de usuarios, el botón con el escudo tachado restablece el inicio de sesión en dos pasos de esa persona. Ella lo vuelve a configurar en su siguiente acceso.

Los códigos dependen del reloj del servidor. Si está mal, no se acepta ningún código. El botón «Check now» de esa misma tarjeta compara la hora del servidor con una fuente de tiempo pública.

Si alguien inicia sesión mediante un servicio externo, el sistema no pide ningún código. El proveedor ya ha comprobado el segundo factor. Con el directorio es distinto: ahí sigue valiendo la regla anterior.

Cada usuario puede activar el inicio de sesión en dos pasos para su propia cuenta. Vale para cada rol, también cuando la tarjeta «2FA Settings» no lo exige. Abre el menú de usuario de la esquina inferior izquierda de la barra lateral y elige «Profile picture». La misma página contiene el área «Two-factor authentication».

El área muestra si el inicio de sesión en dos pasos está activado. Mientras está desactivado, ahí está el botón «Turn on». Primero pide tu contraseña. Después aparece un código QR para la aplicación de autenticación, con la misma clave para teclearla a mano. Tras el primer código de la aplicación, el factor queda activo.

Justo después aparecen diez códigos de recuperación. Guárdalos con «Copy» o «Download». «I have saved my codes» cierra la lista. Solo se muestra esta única vez.

Mientras el inicio de sesión en dos pasos está activado, el área muestra cuántos códigos de recuperación quedan. «New recovery codes» crea diez nuevos. Los códigos antiguos dejan entonces de funcionar. «Turn off» vuelve a desactivar el inicio de sesión en dos pasos. Los dos botones piden el código actual de la aplicación. Ahí no se acepta un código de recuperación.

Si la tarjeta «2FA Settings» exige el inicio de sesión en dos pasos para tu rol, falta «Turn off». Una línea del área lo indica.

Una contraseña o un código erróneos cuentan como un inicio de sesión fallido. La protección contra el adivinado de contraseñas también vale aquí. La activación y la desactivación quedan en el registro de seguridad. Si un administrador desactiva su propio inicio de sesión en dos pasos, el registro da una alerta.

Las cuentas que solo inician sesión a través de un servicio de inicio de sesión externo ven una frase en lugar de los botones. Su proveedor se ocupa del segundo factor. Las cuentas de un directorio introducen en el primer paso su contraseña del directorio.

La protección funciona sin ningún ajuste. No hay nada que activar. La nota correspondiente está en la tarjeta «2FA Settings».

Actúa en dos niveles. Tras cinco intentos fallidos con la misma cuenta, la dirección desde la que provienen queda en pausa. La pausa termina como muy tarde 15 minutos después del primero de esos intentos. Desde cualquier otra dirección, la cuenta sigue utilizable de inmediato.

Esa es la parte importante. De lo contrario, cualquiera que conociera un nombre de acceso podría dejar fuera a un compañero con cinco contraseñas equivocadas. Para ello no necesitaría contraseña alguna.

El segundo nivel es la cuenta en sí. Queda bloqueada 15 minutos tras 20 intentos fallidos. Como una sola dirección puede aportar como mucho cinco, hacen falta varias direcciones.

Un inicio de sesión correcto pone a cero ambos contadores. Tras reiniciar el servidor, la pausa de la dirección desaparece; el bloqueo de la cuenta se mantiene. Los mismos contadores se aplican al inicio de sesión mediante un directorio. Un directorio inaccesible no cuenta como intento fallido. Si todavía no hay ninguna cuenta para ese nombre en el sistema de tickets, solo se aplica la pausa de la dirección.

En la lista de usuarios, una cuenta bloqueada así lleva la marca «temporarily locked». Permanece en la lista. Al cabo de 15 minutos, la marca desaparece sola.

No hace falta esperar. En esa misma fila hay un botón con un candado abierto. Levanta el bloqueo de inmediato y pone a cero ambos contadores.

Esto no es lo mismo que «Archive». Ese botón cierra una cuenta de forma definitiva, y solo él ocupa o libera un puesto interno.

El registro de seguridad recoge dos tipos de eventos. El área «Sign-in» contiene los inicios de sesión fallidos, las cuentas bloqueadas, los intentos de inicio de sesión durante un bloqueo, los códigos de dos factores rechazados y los cambios de contraseña. Esto vale para el inicio de sesión con contraseña, a través de un directorio y a través de SSO.

El área «Administration» muestra quién cambió qué. Eso abarca cuentas, roles, permisos, ajustes de seguridad y archivos. Cada exportación del registro también queda registrada allí.

Los inicios de sesión correctos solo se registran en dos casos. El primer caso es un administrador. El segundo caso es un inicio de sesión después de intentos fallidos en la misma cuenta. El inicio de sesión normal de un agente o de un cliente no figura en el registro. El registro no es una lista de asistencia.

Si alguien inicia sesión con un nombre que no existe, la entrada dice «unknown account». El sistema no guarda el nombre escrito. A veces es una contraseña que acabó en el campo equivocado.

Los eventos de inicio de sesión guardan la dirección IP y el navegador. Las acciones de administración guardan quién las realizó, pero ninguna dirección IP. Las contraseñas, los códigos y el contenido de tickets o correos electrónicos nunca están en el registro.

La página muestra primero las entradas más recientes, 50 por página. La tarjeta «Filters» acota la lista. «Area» elige inicios de sesión o administración, «Event» un único tipo de evento. «Person» busca en el nombre de quien actuó y de quien se vio afectado. «From» y «To» limitan los días. «Failures only» oculta todo lo que salió bien.

Los filtros solo surten efecto tras hacer clic en «Apply». «Reset» los vuelve a quitar.

«Export CSV» y «Export PDF» descargan exactamente lo que muestran los filtros. Cada archivo contiene como máximo 10.000 entradas. Si coinciden más entradas con los filtros, un aviso junto a los botones de exportación lo indica. El PDF está en tu idioma y menciona arriba los filtros y el periodo. La fecha y la hora usan el formato ajustado en «Settings → General Settings».

El archivo CSV siempre queda en inglés y las horas están en UTC. Así un programa puede leerlo independientemente del idioma. Cada exportación figura a su vez en el registro, como «Security log exported».

Seis eventos generan una alerta. Son una cuenta bloqueada tras intentos fallidos, un rol cambiado a «Admin», una cuenta creada directamente con el rol «Admin» y un inicio de sesión de dos factores restablecido de un administrador. A ellos se suman los tickets archivados que se quitaron de los datos en curso y el inicio de sesión de un administrador después de intentos fallidos.

Tras una alerta, todo el que tenga el permiso ve un banner amarillo en la parte superior de cada página. Indica el número de alertas desde su última visita al registro. El enlace «Open security log» lleva allí. Al abrir el registro, el banner desaparece. Antes de la primera visita cuenta las alertas de los últimos siete días.

Además, cada cuenta activa con el permiso y una dirección de correo electrónico recibe un correo de alerta. El sistema reúne las alertas cada 15 minutos y envía un correo por persona, no uno por evento. El correo indica el evento, la persona afectada y la hora. No contiene ninguna dirección IP. El correo de alerta forma parte de Professional.

La ejecución nocturna elimina las entradas antiguas. Los plazos están en «Settings → Security», en la tarjeta «Data protection», en el bloque «Security log retention». Los eventos de inicio de sesión se conservan 90 días de forma predeterminada; se permiten de 7 a 365 días. Las acciones de administración se conservan 12 meses de forma predeterminada; se permiten de 1 a 120 meses.

Cada plazo tiene su propio interruptor: «Delete old sign-in events» y «Delete old administrator actions». Si un interruptor está desactivado, esas entradas se conservan. La tarjeta «Plazos de conservación» explica la ejecución nocturna.

En una solicitud de datos, la persona recibe cada entrada en la que actuó o se vio afectada. La dirección IP y el navegador solo se incluyen en las entradas que ella misma provocó, por ejemplo su propio inicio de sesión. Si se anonimiza a la persona, el sistema elimina sus eventos de inicio de sesión. Sus acciones de administración se conservan. Allí su nombre se sustituye por el marcador de posición.

Una nota para ti como operador: los inicios de sesión correctos solo figuran en el registro para administradores y después de intentos fallidos. Aun así, el registro muestra quién hizo qué y cuándo. En una empresa con comité de empresa es, por tanto, un asunto de codecisión.

Arriba del todo está el interruptor principal «Enable single sign-on». Mientras esté desactivado, todo sigue con nombre de usuario y contraseña. Todo lo que configures debajo se guarda y solo surte efecto cuando lo actives.

La tarjeta «Active Directory / LDAP» conecta un directorio local. Introduces el servidor, la base de búsqueda, el filtro que encuentra a una persona y los campos de la dirección de correo y de los nombres.

La cuenta usada para las consultas es opcional. Sin ella, el sistema pregunta de forma anónima. La contraseña de una persona solo se usa para autenticarse contra el directorio y no se almacena nunca.

Un directorio no aporta un segundo factor propio. Si la página de seguridad exige inicio de sesión en dos pasos, a estas personas también se les pide.

La tarjeta «Identity providers» contiene los servicios de inicio de sesión externos. Cada uno recibe su propia ficha y su propio botón en la página de inicio de sesión. «Add provider» crea uno nuevo.

En «Provider type» eliges el tipo. «Generic OIDC Provider» encaja con servicios como Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 o Ping Identity. «SAML 2.0 Provider» encaja con esas mismas casas cuando se van a conectar por SAML.

Junto a ellos hay seis servicios regionales: LINE, Kakao, Naver, WeChat, WeCom y DingTalk. Sus direcciones vienen ya puestas y aparecen como texto gris en el campo.

El nombre que pongas en «Display name» aparecerá después en el botón. El interruptor de al lado se aplica solo a ese proveedor.

Para la dirección de retorno, sigue este orden. Introduce primero solo un nombre y pulsa «Save provider». Solo entonces conoce el sistema el número del proveedor y muestra la dirección completa en «Redirect URI». Se forma a partir de la dirección pública de esta instalación, la que está guardada en «Settings → Security». Es exactamente la dirección que usa el sistema cuando alguien inicia sesión.

Copias esa dirección y la registras en el proveedor. Allí tiene que coincidir carácter por carácter. A cambio, el proveedor te da un identificador y un secreto, y los introduces aquí con «Edit».

El campo «Allowed e-mail domains» limita quién puede entrar por este proveedor. Si se deja vacío, se permite cualquier dominio.

Si a un proveedor le falta algo, su ficha lleva la marca roja «Incomplete». Entonces no aparece en la página de inicio de sesión. El texto de al lado indica qué campos necesita ese tipo.

Los proveedores completamente configurados siguen sin aparecer mientras el interruptor principal esté desactivado. La ficha lo indica en una línea amarilla.

Si tu licencia vuelve a Basic, el inicio de sesión mediante SSO y el directorio sigue funcionando. En esta página solo puedes entonces desactivar los proveedores y el directorio. El registro de intentos de inicio de sesión sigue siendo legible.

El interruptor «Automatically create accounts on first sign-in» está en la misma tarjeta que el interruptor principal. De fábrica está activado.

Cuando alguien inicia sesión por primera vez con un proveedor, el sistema busca primero una cuenta que ya pertenezca a ese proveedor. Si no encuentra ninguna, crea una nueva.

La cuenta nueva recibe el rol «Customer» y ningún equipo. Un cliente no necesita pertenecer a ningún equipo para crear un ticket, así que puede trabajar de inmediato.

Los clientes son ilimitados en ambas ediciones, de modo que una cuenta creada así no consume ningún puesto interno. Quien deba convertirse en agente recibe después ese rol en la gestión de usuarios.

Si ya existe una cuenta con la misma dirección de correo, ambas se enlazan. Esto solo ocurre cuando el proveedor comunica la dirección como verificada. Si no lo hace, se rechaza el acceso.

Si lo desactivas, solo entran las personas que ya tienen cuenta. A las demás se les niega el acceso.

La tarjeta «Recent sign-in attempts», abajo del todo, muestra los últimos 100 eventos de inicio de sesión a través de SSO y del directorio. Proceden del registro de seguridad. Los intentos fallidos aparecen siempre. Un inicio de sesión correcto solo aparece para administradores y después de intentos fallidos en la misma cuenta. Por tanto, no todos los inicios de sesión aparecen en la lista.

Cada fila nombra la hora, el proveedor, el resultado y la dirección de origen. En un intento fallido, el motivo aparece al lado. La columna «User» muestra el nombre de la cuenta. Si no hay cuenta, muestra la dirección que comunicó el proveedor; si no, «unknown account». El sistema no guarda el nombre introducido.

El acceso con nombre de usuario y contraseña no aparece en esta tabla. No es SSO. Lo encuentras en el registro de seguridad. Lo encuentras en el registro de seguridad.

De fábrica, las entradas se eliminan al cabo de 90 días. La frase bajo el título de la tarjeta indica el plazo configurado. La tarjeta «Plazos de conservación» explica este ajuste.

Tras la instalación, tu equipo usa el sistema en cualquier navegador web. El instalador pregunta cómo se debe acceder al sistema. En el instalador de Windows lo eliges en la página «Accesibilidad». En Linux, install.sh hace la misma pregunta y numera las opciones del 1 al 5. Más adelante lo cambias con «Cambiar cómo se accede a SMITEY». Tus datos se quedan donde están.

La opción «Solo en la red local, a través de la dirección IP (HTTP) - la opción más sencilla» es el ajuste predeterminado. Tu equipo abre el sistema en http:// seguido de la dirección IP del servidor y el puerto, por ejemplo http://192.168.1.20:8088. El puerto es 8088, salvo que elijas otro. También funciona el puerto 80. Entonces la dirección no necesita puerto. Esta opción no necesita ni nombre ni certificado.

La opción «En la red local con un nombre propio (HTTP, HTTPS posible más adelante) - dispone de DNS interno» funciona como la primera, pero con un nombre como ticket.company.local. El nombre lo creas tú en tu DNS interno. Apunta a la dirección IP del servidor. Así tu equipo llega al sistema por el nombre y también, como antes, por la dirección IP. Después, el instalador muestra la dirección con ese nombre.

Con las dos opciones HTTP, las contraseñas y los tickets viajan por tu red como texto plano. En ese caso, los administradores ven un aviso arriba en la página.

Las otras tres opciones usan HTTPS: «A través de un dominio público con HTTPS (automático, mediante Let's Encrypt)», «En la red local con HTTPS y un certificado propio» y «En la red local con HTTPS, certificado creado por SMITEY». Necesitan los puertos 80 y 443 en el servidor. La siguiente tarjeta las describe.

Para una primera prueba basta la primera opción. Si tu red tiene DNS interno, elige la segunda. Si el sistema debe ser accesible desde internet, elige el dominio público. Si tu empresa tiene su propia CA, elige el certificado propio en la red local. Si no, deja que SMITEY cree el certificado.

Sin HTTPS, las contraseñas y los tickets viajan por tu red como texto plano. Una instalación nueva empieza con HTTP simple, para que funcione enseguida en cualquier navegador web. Mientras un administrador abra el sistema por HTTP simple, aparece un aviso arriba en la página: «This connection is not encrypted.» Si el sistema se abre en el propio servidor como «localhost», el aviso no aparece. Los agentes y los clientes nunca lo ven.

«How to switch on HTTPS» lleva a esta tarjeta. «Hide for 30 days» oculta el aviso para ti. El ajuste pertenece a tu cuenta, así que también vale en otro navegador. Pasados 30 días, el aviso vuelve mientras la conexión siga sin cifrar.

El instalador de SMITEY configura HTTPS de tres maneras. En el instalador de Windows lo eliges en la página «Accesibilidad», y en Linux install.sh hace la misma pregunta. En un sistema que ya está en marcha, abre «Cambiar cómo se accede a SMITEY» en el escritorio de Windows o en el menú Inicio. En Linux, el comando de abajo hace lo mismo. Tus datos se quedan donde están.

La opción «En la red local con HTTPS y un certificado propio» usa tu propio certificado, por ejemplo de la CA de tu empresa. El instalador pide el nombre del sistema y el archivo del certificado con su clave. También vale un archivo PFX con su contraseña. Antes de cambiar nada, comprueba el certificado. La clave debe corresponder, el certificado debe ser válido y el nombre debe figurar en el certificado.

La opción «En la red local con HTTPS, certificado creado por SMITEY» no necesita un certificado propio. SMITEY crea uno él mismo y también lo renueva él mismo. El instalador guarda el certificado raíz como SMITEY-root-ca.crt en la carpeta de instalación. Instala este archivo en cada equipo como certificado raíz de confianza, por ejemplo con una directiva de grupo. Hasta entonces, los navegadores muestran un aviso.

La opción «A través de un dominio público con HTTPS (automático, mediante Let's Encrypt)» obtiene su certificado de Let’s Encrypt. Necesita un dominio público que apunte al servidor. Para ello, el servidor tiene que ser accesible desde internet.

En las dos opciones de la red local, el nombre puede ser un nombre como ticket.company.local, una sola palabra como helpdesk o una dirección IPv4. Los tres caminos necesitan los puertos 80 y 443 en el servidor. Si otro programa los usa, el instalador se detiene y no cambia nada. Después, el sistema se alcanza en https:// seguido del nombre, sin puerto.

Tu propio certificado caduca en algún momento. Desde 30 días antes, los administradores ven arriba en la página un aviso con la fecha. Desde 7 días antes, es rojo. En Professional, todos los administradores con dirección de correo reciben además un correo 30 y 7 días antes. Para renovarlo, abre de nuevo «Cambiar cómo se accede a SMITEY», elige la opción con tu propio certificado e indica los archivos nuevos.

El archivo HTTPS-GUIDE.txt que viene con la instalación describe cada paso. Eso incluye repartir el certificado raíz y los pasos a mano.