Reino, usuarios y clientes

Un servidor de identidad autoalojado no guarda todas las cuentas en un solo montón. Las agrupa en reinos: cada reino tiene sus propios usuarios, credenciales, roles, grupos y clientes, y lo que existe en un reino no existe en otro. Es la frontera que decide quién puede ser autenticado y para qué. Un servidor suele traer además un reino de administración, pensado solo para quienes operan el propio servidor, y sobre el resto se decide cuántos reinos hacen falta: uno para el personal y los estudiantes, otro para ensayos.

Esa frontera importa al revisar. Una cuenta con un permiso poderoso en un reino de ensayo no lo tiene en el reino de producción, y un error de configuración en un reino no se arrastra al resto. Por eso la primera pregunta de una revisión es qué reinos hay y qué le exige cada uno a quien entra.

Cada reino trae sus propias opciones de entrada. La más delicada es el registro propio: si está activo, cualquier persona que llegue a la pantalla de acceso puede crearse una cuenta sin que nadie la apruebe. Puede tener sentido en un reino de ensayo, o en un servicio público, pero en un reino con personal y estudiantes reales es una puerta abierta.

Abre glosario.txt para el significado de cada columna y reinos.txt para ver la configuración de cada uno.

El estado de una cuenta y su correo verificado son dos cosas distintas. Una cuenta habilitada puede iniciar sesión; una cuenta con el correo sin verificar puede tener un correo mal escrito o ajeno, y ese correo es el canal de recuperación de la contraseña. Una cuenta que cumple ambas cosas es una lista que alguien debe poder explicar, incluidas las de servicio.

En usuarios.txt cuenta las cuentas habilitadas cuyo correo no está verificado. No cuentes las deshabilitadas.

Un cliente es una aplicación que le pide al servidor que autentique a una persona. Cada cliente declara las direcciones de redirección a las que el servidor puede devolver a la persona con su sesión. Si esa lista admite un comodín muy amplio, un atacante que consiga engañar a una persona con un enlace puede lograr que el servidor entregue la sesión a una dirección que él controla. Un cliente público, que no puede guardar un secreto (una aplicación de navegador o móvil), depende más de esa lista que uno confidencial, que se identifica ante el servidor con un secreto guardado en su propio servidor.

Lee clientes.txt y fíjate en la columna de redirecciones.

Lo normal es que la persona escriba su contraseña en la pantalla del servidor. El acceso directo con contraseña permite que el cliente reciba usuario y contraseña y los presente él al servidor; así la aplicación ve la contraseña en claro y el servidor no puede exigir pasos intermedios como un segundo factor. Por eso se revisa qué clientes lo tienen activo y se pide una razón para cada uno.

Cuenta en clientes.txt los clientes con el acceso directo con contraseña activado.