Autenticación, usuarios y grupos

Esta área responde a dos preguntas de gestión: cómo demuestran las personas quiénes son y cómo limita Opfield lo que pueden cambiar. El responsable de la identidad mantiene el inicio de sesión y la recuperación; los responsables de los recursos definen los grupos operativos; los administradores de seguridad revisan el acceso privilegiado. El éxito significa que las personas pueden recuperar el acceso sin saltarse los controles, y que un cambio de rol se puede aplicar y auditar sin reescribir todos los recursos.

Opfield admite autenticación independiente mediante OIDC, contraseña local y código de un solo uso por correo. Las passkeys se registran después de crear la cuenta. La política de MFA puede exigir el registro antes de que un usuario reciba una sesión normal. Los métodos de inicio de sesión, la autenticación multifactor, el proveedor OIDC y el aprovisionamiento de identidades se configuran en Settings > Authentication.

Usa los grupos como límite de permisos habitual. Mantén un grupo de administradores pequeño y auditable y separa a los operadores, los desarrolladores, los observadores y la automatización. Bloquear o eliminar a un usuario revoca el acceso conservando la atribución histórica. Restaurar un usuario eliminado deja la cuenta bloqueada hasta que se activa explícitamente.

La suplantación es un flujo de soporte administrativo y debe poder distinguirse en la finalidad de la sesión y en los registros de auditoría. Detén la suplantación para restaurar la sesión original del administrador; no emitas tokens de API normales desde una sesión suplantada.

Opfield todavía no ofrece SCIM. La compatibilidad con SCIM está prevista; hasta que llegue, usa la API de administración compatible con automatización OAuth con ámbitos limitados cuando tu sistema de identidad pueda llamar a API externas, o mantén un proceso manual documentado.

Diseño de la autenticación

Activa al menos dos vías de recuperación de administradores antes de depender de un proveedor de identidad externo. Prueba la redirección y el cierre de sesión de OIDC, la entrega de correos, la recuperación de contraseñas locales, el registro de MFA y los códigos de recuperación con cuentas que no sean de producción.

OIDC demuestra la identidad, pero no concede automáticamente un acceso amplio al producto. Los permisos de Opfield siguen siendo explícitos. Si el proveedor externo no está disponible, solo los métodos configurados de forma independiente pueden restablecer el acceso.

Conecta tu proveedor de SSO (OIDC)

Opfield inicia la sesión de los usuarios a través de un único proveedor OIDC por instalación, como Keycloak, Authentik, Microsoft Entra ID, Okta o Google Workspace. Cambiar el proveedor requiere settings:opfield:edit y admin:system; cambiar los métodos de inicio de sesión y el aprovisionamiento de identidades requiere settings:opfield:edit.

Antes de empezar, comprueba que Public URL, en Settings > General, es la dirección que abren los usuarios, por ejemplo https://opfield.example.com. La URI de redirección se construye a partir de ella.

1. Registra Opfield en el proveedor de identidad. Crea una aplicación web OpenID Connect (un cliente confidencial con el flujo de código de autorización). Registra la URI de redirección <Public URL>/auth/callback, por ejemplo https://opfield.example.com/auth/callback. El esquema, el nombre de host, el puerto y la ruta deben coincidir exactamente. Anota la URL del emisor, el ID de cliente y el secreto de cliente.

2. Rellena el proveedor. Abre Settings > Authentication > OIDC provider:

   Campo	Qué introducir
   Display name	El nombre del botón de inicio de sesión: Sign in with este nombre. Déjalo vacío para mostrar Sign in with SSO.
   Issuer URL	El emisor del proveedor, por ejemplo https://id.example.com/application/o/opfield/. Opfield lee de él el documento de descubrimiento para encontrar los endpoints de autorización, de tokens y de claves.
   Client ID	El identificador de cliente del paso 1.
   Client secret	El secreto del paso 1. Opfield lo guarda cifrado y después solo muestra sus cuatro últimos caracteres. Al editar, déjalo vacío para conservar el secreto guardado.
   Redirect URI	El mismo callback que registraste en el paso 1: <Public URL>/auth/callback.
   Scopes	Separados por espacios; openid es obligatorio. El valor predeterminado openid email profile da a Opfield el correo y el nombre del usuario.

   Pulsa Save.

3. Decide cómo aparecen las cuentas. En Settings > Authentication > Identity provisioning:

   • Auto-create users on OIDC sign-in crea una cuenta de Opfield la primera vez que un usuario inicia sesión a través del proveedor. Desactívalo cuando cada usuario deba crearse primero en Administration > Users con el método de inicio de sesión OIDC; su primer inicio de sesión con OIDC con el mismo correo reclama esa cuenta.
   • Require verified OIDC email acepta el correo solo cuando el proveedor envía email_verified: true.
   • Default group for new OIDC users es el grupo que reciben los usuarios creados automáticamente.

4. Activa OIDC. En Settings > Authentication > Sign-in methods, activa OIDC. Opfield lo rechaza con OIDC_NOT_CONFIGURED hasta que se guarda el proveedor.

5. Prueba el inicio de sesión. Mantén abierta tu sesión actual. En una ventana privada, abre Opfield, elige Sign in with con tu nombre visible e inicia sesión con una cuenta de prueba. Comprueba que el usuario acaba en el grupo esperado e inicia sesión después una vez como administrador a través del proveedor.

6. Pasa a los administradores. En Administration > Users > Configure User, fija Sign-in method en OIDC para cada administrador que deba usar el proveedor. Cambiar el método cierra la sesión del usuario en todas partes; la cuenta se vincula al proveedor en su siguiente inicio de sesión.

7. Desactiva otros métodos si quieres. Solo después de que un administrador haya iniciado sesión a través del proveedor, desactiva Email and password o Email sign-in code en Sign-in methods.

Lo que Opfield lee del proveedor

Claim	Uso
sub	La identidad del usuario en el proveedor. Junto con el emisor, vincula la cuenta de Opfield. Obligatorio.
email	Coincide con un usuario creado de antemano y pasa a ser el correo de la cuenta. Obligatorio en el primer inicio de sesión.
email_verified	Se comprueba cuando Require verified OIDC email está activado.
name	El nombre del usuario en Opfield. Los nombres de los usuarios OIDC los gestiona el proveedor y no se pueden editar en Opfield.
picture	El avatar del usuario.

Opfield no mapea los grupos ni los roles del proveedor. Los grupos y los ámbitos se asignan en Opfield; los usuarios nuevos reciben el grupo predeterminado.

Un usuario que ha iniciado sesión a través de un proveedor queda vinculado a su emisor. Si cambias Issuer URL a otro proveedor, esos usuarios no pueden iniciar sesión a través del nuevo (OIDC_ISSUER_MISMATCH). Para trasladar a uno de esos usuarios, cambia su Sign-in method en Configure User a otro método y vuelve a OIDC; se vincula de nuevo en su siguiente inicio de sesión.

Remove, en el panel OIDC provider, elimina el proveedor tras una confirmación y desactiva el inicio de sesión con OIDC.

API: PUT /api/admin/auth-settings con oidc (issuer, clientId, clientSecret, redirectUri, scopes, displayName), methods u oidcProviderAction: "remove"; MCP y asistente: update_opfield_settings con los mismos campos.

Inicia sesión con la cuenta de Opfield

Una instalación conectada a Opfield Cloud puede usar tu cuenta de Opfield como proveedor OIDC en lugar de registrar su propio SSO. Opfield pide a la cuenta un cliente de inicio de sesión; no introduces un emisor, un ID de cliente ni un secreto. No hace falta Allow remote management.

1. Comprueba que Public URL está definida en Settings > General. La cuenta devuelve a los usuarios a <Public URL>/auth/callback; sin una URL pública, la petición se rechaza con PUBLIC_URL_REQUIRED.
2. En Settings > Authentication > OIDC provider, elige Use Opfield account. El panel muestra “Waiting for your Opfield account… Sign-in with it is set up as soon as it answers” y un botón Cancel request. Volver a elegir el botón no envía una segunda petición.
3. Cuando la cuenta responde, Opfield añade el proveedor “Opfield account” y activa OIDC en Sign-in methods. La instalación tiene un solo proveedor OIDC, así que la cuenta de Opfield ocupa el lugar del proveedor que tenías. El panel se actualiza solo.
4. Deja que las personas inicien sesión con ella. Los usuarios se emparejan como con cualquier proveedor OIDC: da a un usuario existente el Sign-in method OIDC en Configure User, y su primer inicio de sesión con la cuenta de Opfield del mismo correo reclama la cuenta; los usuarios nuevos se crean cuando Auto-create users on OIDC sign-in está activado. Pruébalo en una ventana privada con Sign in with Opfield account.

Cancel request retira una petición que la cuenta todavía no ha respondido. Si cambiar a la cuenta de Opfield dejara la instalación sin ningún administrador capaz de iniciar sesión, Opfield solo guarda el cliente recibido y no cambia nada; da a un administrador un método que siga activo y vuelve a elegir Use Opfield account. Cuando la instalación ya tiene un cliente, Use Opfield account recupera el proveedor de inmediato, por ejemplo después de eliminarlo o de probar tu propio SSO.

Cuando alguien pierde el acceso a la instalación en la cuenta de Opfield, Opfield bloquea su usuario, y Administration > Users muestra Blocked by the Opfield account. Su siguiente inicio de sesión con la cuenta de Opfield, cuando la cuenta le devuelva el acceso, lo desbloquea; Unblock user también funciona. Consulta Acceso retirado en la cuenta de Opfield.

La cuenta de Opfield puede sustituir el secreto del cliente a través de la conexión mientras la instalación inicia sesión con el proveedor “Opfield account”. Cuando desconectas la instalación de Opfield Cloud, o la cuenta la desconecta, Opfield olvida el cliente, elimina el proveedor “Opfield account” y desactiva el inicio de sesión con OIDC. Si entonces ningún administrador pudiera iniciar sesión, el proveedor se mantiene y el panel OIDC provider lo indica: da a un administrador otro método de inicio de sesión y elige después Remove.

API: PUT /api/admin/auth-settings con oidcProviderAction: "opfield_account" o "cancel_opfield_account"; MCP y asistente: update_opfield_settings con el mismo campo. Los ajustes informan de opfieldAccountSignIn con available (conectada a Opfield Cloud), clientIssued, pendingRequest y detached. Sin conexión, la acción se rechaza con OPFIELD_ACCOUNT_CLIENT_MISSING.

Inicio de sesión con contraseña y con código por correo

Email and password y Email sign-in code, en Sign-in methods, envían enlaces y códigos por correo, así que necesitan un SMTP verificado en Settings > Advanced > SMTP configuration: envía antes allí una prueba. Sin él, activar cualquiera de los dos métodos se rechaza con SMTP_NOT_VERIFIED. El método propio de un usuario se fija en Administration > Users > Configure User > Sign-in method; cambiar a Email and password envía un enlace para establecer la contraseña.

El último administrador conserva una forma de entrar

Opfield rechaza un cambio tras el cual ningún administrador del sistema podría iniciar sesión. Lo comprueba cuando desactivas OIDC, Email and password o Email sign-in code, eliminas el proveedor OIDC o guardas un proveedor con otro emisor. El cambio se rechaza con LAST_ADMIN_SIGN_IN: “No administrator could sign in after this change.” Un administrador solo cuenta cuando su propio método de inicio de sesión sigue activo y, para OIDC, solo cuando no está vinculado a otro emisor. Las passkeys no cuentan. Da a otro administrador, o a ti mismo, un método que siga activo, inicia sesión con él y haz después el cambio.

En una instalación gestionada por Opfield Cloud, el proveedor empieza siendo “Opfield account” y sigue las mismas reglas; consulta Instalaciones gestionadas.

Ciclo de vida de los usuarios

1. Crea o invita al usuario a través de una vía de autenticación aprobada.
2. Exige MFA según la política antes de conceder ámbitos sensibles.
3. Añade el usuario a grupos basados en roles en lugar de asignarle permisos puntuales cuando sea posible.
4. Verifica que el usuario puede acceder a un recurso previsto y que se le deniega un recurso fuera de su ámbito.
5. Revisa las sesiones, los tokens y la pertenencia a grupos cuando cambie el rol del usuario.
6. Bloquea la cuenta de inmediato cuando el acceso deba terminar.
7. Elimínala solo después de transferir las dependencias de propiedad y de automatización.

Bloquear detiene el uso nuevo sin borrar la atribución. La eliminación sigue siendo visible en el historial de auditoría. Restaurar un registro eliminado no lo reactiva silenciosamente.

Correos de invitación

Un correo de invitación indica a un usuario nuevo que un administrador ha creado su cuenta de Opfield y enlaza a la página de inicio de sesión, con una indicación para su método de inicio de sesión: el proveedor de identidad, un código por correo o el correo aparte que establece su contraseña. El envío requiere un SMTP verificado y la URL pública de Opfield.

• Send invitation email, en Administration > Users > Configure User, en el panel Account, lo envía a mano. Se ofrece una vez por usuario y solo hasta su primer inicio de sesión; después del envío, el panel muestra cuándo se envió. Requiere admin:users sobre ese usuario.
• Settings > Authentication > Identity provisioning > Send an invitation email when an account is created lo envía para cada cuenta creada en la consola, la API o MCP. Está desactivado por defecto y cambiarlo requiere settings:opfield:edit. Si el envío falla, la cuenta se crea igualmente y la invitación se puede enviar más tarde a mano.

API: POST /api/admin/users/{id}/invitation; MCP y asistente: operación send_invitation de manage_user. La lista de usuarios devuelve lastLoginAt e invitationSentAt para cada usuario.

Diseño de grupos

Separa la administración de la plataforma, la administración de seguridad, la operación de aplicaciones, el desarrollo, la observación de solo lectura y la automatización. Usa concesiones limitadas por recurso para una carpeta, una Route, un nodo, una carga de trabajo, una base de datos o un Pages Project en lugar de conceder un área completa del producto.

El diálogo de grupos y los permisos adicionales de un usuario muestran el acceso como una lista de líneas. Add Access añade una: un Role, Where se aplica (Everywhere, In a project folder, In an app environment o Specific resources) y qué Covers, o un nivel de acceso sobre repositorios Git. Review N scopes abre los propios ámbitos; la cabecera de cada sección muestra hasta dónde llegan sus ámbitos (Everywhere, un lugar o N places) y los limita a carpetas, apps o entornos. Consulta Restringe los tokens y las concesiones OAuth.

Mantén pequeño el grupo de administradores y una vía de emergencia documentada. Prueba los cambios de permisos con una sesión real sin privilegios de administrador; la vista de un administrador no puede demostrar que los límites de denegación funcionan.

Suplantación y soporte

Usa la suplantación solo para una investigación de soporte acotada. La sesión debe seguir marcada de forma visible y ser auditable. No cambies credenciales, no crees tokens de administrador duraderos ni hagas trabajo no relacionado mientras suplantas a otro usuario. Detén la suplantación antes de volver a la administración normal.

Aprovisionamiento antes de SCIM

El aprovisionamiento SCIM todavía no está disponible y no hay una fecha de lanzamiento garantizada. Hasta que se publique, mantén una lista de comprobación de altas, cambios y bajas y concilia los usuarios y los grupos a mano o mediante la automatización compatible con la REST API y OAuth. Da al cliente de automatización solo los ámbitos de usuarios y grupos que necesite, haz que las peticiones sean idempotentes y verifica una concesión esperada y una denegación esperada tras cada cambio de acceso.

Recuperación y prevención de bloqueos

Trata la configuración de identidades como una dependencia de producción. Antes de cambiar el único método de inicio de sesión que funciona, crea y prueba una segunda vía de administrador en un perfil de navegador aparte. Guarda los códigos de recuperación fuera de Opfield, verifica que el correo de recuperación de contraseñas locales llega al buzón previsto y registra qué equipo es responsable de la aplicación OIDC y de su secreto de cliente. No desactives el método anterior hasta que una sesión nueva pueda iniciar sesión, completar MFA y llegar a una página exclusiva de administradores a través de la vía sustituta.

Si los administradores quedan bloqueados, restablece la dependencia externa que ha fallado o usa el método independiente probado previamente. Evita editar directamente en PostgreSQL las filas de usuarios, sesiones o grupos: saltarse la aplicación puede dejar incoherentes los estados de contraseñas, MFA, sesiones y auditoría. Cuando se recupere el acceso, revisa los eventos de autenticación recientes, las sesiones activas, la pertenencia a grupos y el estado de los códigos de recuperación antes de dar por cerrado el incidente.

Lista de comprobación de verificación

• Inicia sesión con cada método activado con una cuenta que no sea de producción.
• Confirma que se exige el registro de MFA antes de emitir una sesión privilegiada normal.
• Verifica que un usuario bloqueado no puede crear una sesión nueva ni usar un token existente.
• Verifica que un usuario restaurado sigue bloqueado hasta que se activa explícitamente.
• Prueba una acción permitida y otra denegada sobre un recurso para cada grupo operativo.
• Confirma que la suplantación está marcada de forma visible y que el actor de la auditoría sigue siendo atribuible.
• Concilia periódicamente los usuarios inactivos, los grupos sin usar, las sesiones obsoletas y las invitaciones pendientes.

La autenticación demuestra quién es quien llama; los grupos y los ámbitos deciden qué puede hacer. Un inicio de sesión con OIDC correcto nunca debe usarse como prueba de que el usuario deba recibir una autoridad amplia en Opfield.