Configuración de seguridad nativa de Dataverse

Avance

Este modelo de seguridad está actualmente en vista preliminar — tanto la función unificada de seguridad subyacente de Microsoft en Dataverse como el soporte de Power Portals Pro para ella. Power Portals Pro sigue el calendario de lanzamientos de Microsoft: una vez que la función alcance disponibilidad general por parte de Microsoft, el soporte de Power Portals Pro también dejará la vista previa. La designación de vista previa existe para tener en cuenta cualquier cambio que Microsoft pueda hacer en su lado durante la fase de vista previa.

El modelo de seguridad nativo de Dataverse permite que Dataverse imponga la seguridad para los usuarios de tu portal mediante roles de seguridad estándar, configurados exactamente como Power Pages: roles web y permisos de tablas. Esta página repasa toda la configuración, de principio a fin.

Para saber cómo funciona el modelo y cómo se relaciona con los manejadores de permisos, véase el Resumen de seguridad

1. Instalar los componentes del framework de Power Pages

El modelo de seguridad unificado se ejecuta en componentes que Microsoft instala en tu entorno Dataverse cuando se crea un sitio web de Power Pages. Si el entorno nunca ha alojado un sitio de Power Pages, crea uno ahora — cualquier plantilla sirve, y un sitio de prueba está bien. Consulta Crear y gestionar sitios en la documentación de Power Pages.

Nota

No necesitas pagar por el sitio ni mantenerlo en funcionamiento — una vez instalados los componentes del framework y activada la función de seguridad, puedes eliminar el sitio web en sí. El registro del sitio de Power Pages (powerpagesite) referenciado por tu configuración debe permanecer en el entorno, ya que los mapeos de usuario y la sincronización de roles de seguridad se resuelven en su contra.

2. Habilitar la seguridad unificada de Dataverse para el sitio

Activa la función de seguridad unificada de Dataverse de Microsoft para el sitio siguiendo los pasos de Unify Power Pages Security with Dataverse. Una vez habilitada, la plataforma crea un rol de seguridad emparejado de Dataverse (denominado PowerPages_*) para cada rol web del sitio y lo mantiene sincronizado.

3. Configurar roles web y permisos de tabla

En la aplicación Power Pages Management , crea (o ajusta) los roles web y permisos de tabla del sitio, y vincula cada permiso de tabla a los roles web que deberían recibirlos. Esta es la única forma soportada de conceder acceso bajo este modelo: la plataforma traduce los permisos de la tabla enlazada en privilegios para cada rol de seguridad sincronizado de rol web. Los scopes funcionan exactamente igual que en Power Pages (Global, Contacto, Cuenta, ...), así que aquí también se configuran reglas de acceso a nivel de registro.

4. Encuentra el ID de tu sitio Power Pages

PowerPortalsPro necesita el id del registro del powerpagesite sitio. Puedes consultarlo directamente — por ejemplo, abrirlo <your org url>/api/data/v9.2/powerpagesites?$select=name en un navegador y copiar el powerpagesiteid de tu sitio.

5. Habilitar la provisión en Power Portals Pro

Configúralo SecurityOptions en tu servidor Program.cs:

La configuración se valida al inicio: cuando ProvisionSystemUsers está habilitada, PowerPagesSiteId debe establecerse y resolver a un registro existente powerpagesite , de lo contrario la aplicación no arranca con la guía. A partir de este punto, PowerPortalsPro provisiona automáticamente un sistema gestionado por el sistema (C2) systemuser y un powerpagesusermapping registro para cada contacto del portal — al registrarse nuevos contactos y al iniciar sesión perezosamente para los existentes — e imita a ese usuario en cada llamada de Dataverse.

6. Asignar roles web a los contactos

Concede acceso a los usuarios individuales asignando roles web a sus contactos — en la aplicación Power Pages Management o programáticamente a través de la powerpagecomponent_mspp_webrole_contact relación. La plataforma asigna y elimina automáticamente los roles de seguridad sincronizados a medida que cambia la membresía del rol web.

Propina

Dataverse almacena en caché los privilegios efectivos de cada usuario por nodo del servidor, por lo que los cambios de rol y privilegio pueden tardar desde unos segundos hasta un par de minutos en hacer efecto tras una asignación. Ten esto en cuenta en las pruebas y en cualquier flujo que conceda acceso y luego actúa inmediatamente en consecuencia.

Visitantes anónimos

Los visitantes que han dado el registro están cubiertos por el mismo modelo. Power Pages crea automáticamente un usuario Anónimo para el sitio — un usuario gestionado por el sistema con la identidad PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — y PowerPortalsPro lo suplantó para cada solicitud no autenticada. Concede acceso anónimo de la forma de Power Pages: marca un rol web como el rol de Usuarios Anónimos del sitio en la app Power Pages Management y enlaza permisos en la tabla a él; El rol de seguridad sincronizado regula entonces lo que pueden ver los visitantes desconectados.

Nota

El usuario Anónimo se crea perezosamente por Power Pages, por lo que los sitios creados antes de la función de seguridad unificada pueden aún no tener una (se descubre a través de los registros sin powerpagesusermapping contacto del sitio — el usuario es invisible a las consultas de atributos — y un candidato solo es aceptado después de verificar su identidad con el conocido nombre de usuario Anónimo). Cuando no se puede encontrar, los visitantes anónimos recurren a los gestores de permisos del portal — es decir, no hay acceso anónimo a los datos a menos que los gestores estén registrados — y el framework registra el resultado al inicio y lo intenta periódicamente.

¿Y qué pasa con los encargados de permisos?

Las sesiones bajo este modelo se saltan ITablePermissionHandler o ITableRecordPermissionHandler se saltan por completo — exactamente como los inicios de sesión internos systemuser — porque Dataverse impone la seguridad de forma nativa a través de los roles del usuario suplantado. No necesitas escribir ni registrar ningún código de manejador de permisos. Los manejadores siguen aplicándose a sesiones que no están respaldadas por un usuario del sistema suplantado (la función deshabilitada, una sesión en la que falló la provisión y el framework volvió a la seguridad del portal, o visitantes anónimos en un sitio sin el usuario Anónimo), por lo que los portales existentes basados en manejadores pueden migrar de forma incremental.

Distinguiendo a los usuarios provisionados en tu interfaz

Las sesiones llevan una PortalUserType reclamación que contiene el valor entero del PortalUserType enum: Contact (usuario clásico del portal), SystemUser (inicio de sesión interno real), o ContactStubUser (un contacto respaldado por un usuario gestionado por el sistema provisionado); ContactStubUser las sesiones además llevan una SystemUserId reclamación con el id del usuario provisionado, resuelta a partir del registro autoritativo powerpagesusermapping . El mismo enum se devuelve por GET /api/auth/me . CurrentUserInfo.PortalUserType Usa las GetPortalUserType() extensiones y GetDataverseSystemUserId() en ClaimsPrincipal, y nunca presentes una ContactStubUser sesión como un usuario interno.

Referencia API