Inicio de sesión SystemUser

Power Portals Pro reconoce los registros de Dataverse systemuser iniciados como usuarios del portal, junto con los usuarios respaldados por defecto contact. No se requiere configuración: cuando un usuario inicia sesión mediante autenticación de Microsoft, el portal primero busca una coincidencia systemuser; si existe una, la sesión se ejecuta como ese usuario del sistema y Dataverse hace cumplir la seguridad mediante suplantación. Si no se encuentra ningún usuario del sistema coincidente, el inicio de sesión vuelve a la ruta de contacto. El mismo portal puede atender al personal interno con licencia Dataverse y a los contactos externos de clientes al mismo tiempo.

Cuando esto importa

El flujo respaldado por el usuario del sistema es útil cuando:

El portal atiende al personal — empleados, agentes de soporte, socios con licencias Dataverse — que ya están provisionados como usuarios del sistema.
Quieres que los roles de seguridad de Dataverse sean la única fuente de verdad sobre lo que esos usuarios pueden ver y hacer.
No quieres duplicar la identidad manteniendo un registro paralelo contact para cada usuario del personal.

Solo autenticación de Microsoft
Solo el proveedor externo de Microsoft / Entra ID puede resolver a un usuario del sistema; los usuarios son emparejados contra systemuser.azureactivedirectoryobjectid, y cualquier usuario del sistema con isdisabled = true queda bloqueado. Nombre de usuario/contraseña local y otros proveedores externos (Google, etc.) siempre inician sesión como contacto.

Cómo funciona

En un inicio de sesión de Microsoft, el portal:

Consulta el ID de objeto de Azure AD autenticado contra systemuser.azureactivedirectoryobjectid. Si un registro activo coincide, la sesión queda vinculada a ese usuario del sistema.
De lo contrario, vuelve al flujo de contacto (coincidiendo con el inicio de sesión externo a través de adx_externalidentity).
Para las sesiones de systemuser, ServiceClient.CallerId se establece para systemuserid que cada llamada a Dataverse se ejecute como el usuario iniciado sesión — con sus roles de seguridad, alcance de unidad de negocio y acceso a nivel de fila. El lado ITablePermissionHandler del portal / ITableRecordPermissionHandler las instancias se omiten para la solicitud.
Las cuadras, formularios y botones reflejan los privilegios reales del usuario en Dataverse, calculados y RetrieveUserPrivilegesRequest almacenados en caché por usuario. Las sesiones de contacto continúan fluyendo a través de los manejadores registrados como antes.

Modelo de seguridad

Para sesiones respaldadas por systemuser, porque CallerId la suplantación delega la aplicación a Dataverse:

La seguridad a nivel de registros y columnas proviene del rol(los) de seguridad del usuario iniciado sesión en Dataverse, no del código del portal.
La seguridad a nivel de campo, la propiedad jerárquica y el alcance de las unidades de negocio se aplican automáticamente.
Los manejadores de permisos del lado del portal (ITablePermissionHandler / ITableRecordPermissionHandler) se omiten para la solicitud. Continúan funcionando con normalidad para las sesiones respaldadas por contacto en el mismo portal.
Los roles de seguridad de Dataverse del usuario se proyectan sobre el principal como ClaimTypes.Role reclamaciones, por lo que los atributos y User.IsInRole(...) comprobaciones existentes [Authorize(Roles = "…")] funcionan en su contra sin necesidad de un viaje adicional de ida y vuelta por petición. Las reclamaciones se actualizan tras la validación principal, por lo que las asignaciones de roles realizadas en Dataverse se detectan dentro del intervalo de sello de seguridad (~10 minutos) sin forzar un nuevo inicio de sesión.

Administradores: pruebas como contacto

Los administradores del portal suelen necesitar verificar la experiencia del lado del contacto: ¿la página principal se renderiza correctamente para un cliente iniciado sesión? ¿Este caso oculta correctamente ese botón de la barra de herramientas? — sin perder su capacidad para realizar acciones administrativas. Power Portals Pro soporta esto directamente: un administrador puede mantener un inicio de sesión de Microsoft vinculado tanto systemuser a una (su cuenta interna) como a contact (un registro de prueba, o su propio registro del lado del cliente), y alternar entre ambos sin cerrar sesión.

Elige al iniciar sesión. Cuando un inicio de sesión de Microsoft se resuelve con más de una identidad, la página posterior a la devolución de llamada muestra un selector que lista a cada candidato (tipo + nombre visible + correo electrónico). Elegir uno inicia la entrada del usuario con esa identidad para el resto de la sesión.
Recordaba la elección. El seleccionador escribe una pequeña cookie por clave de proveedor para que los inicios de sesión posteriores salten el prompt y vayan directamente a la última identidad seleccionada. La selección recordada se actualiza cada vez que el usuario cambia durante la sesión, por lo que el siguiente inicio de sesión ambiguo respeta la nueva preferencia.
Interruptor en sesión. Cuando el usuario iniciado sesión tiene una identidad hermana, aparece una entrada Cambiar para contactar / Cambiar para usuario del sistema en el menú de perfil. Se publica en /api/auth/switch-identity, que vuelve a emitir la cookie de autenticación para la identidad alternativa — no se requiere un viaje de ida y vuelta de OAuth nuevo. El endpoint lee el id de identidad alternativa del principal (nunca del cuerpo de la solicitud), por lo que un clic manipulado no puede iniciar sesión al usuario como otra persona.

Audiencias mixtas: diseña tus datos en consecuencia
Un único portal puede servir tanto a usuarios de sistema como a usuarios de contacto en el mismo despliegue. Si tus personalizaciones incluyen filtros FetchXML que asignan filas adx_contactid == currentUserId (un patrón común en portales solo de contacto), esos filtros no tendrán sentido cuando el usuario iniciado sesión es un usuario del sistema. Haz ramificaciones en tu código de personalización en el tipo de usuario para que cada audiencia vea los datos apropiados para él.

Cachés de privilegios

El mapa de metadatos de privilegios a nivel de entorno se carga una vez al iniciar la aplicación y se almacena en caché indefinidamente; Reiniciar la aplicación (o llamada IPrivilegeMetadataCache.InvalidateAsync) para detectar nuevas tablas o cambios en el esquema de privilegios. Los privilegios efectivos de cada usuario del sistema iniciado sesión se almacenan en caché durante 24 horas y pueden ser expulsados con IUserPrivilegeCache.InvalidateAsync(userId).