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.

En este modelo, el portal deja de decidir qué puede hacer un usuario y es Dataverse quien decide en su lugar. Cada contacto del portal está respaldado por su propio usuario de Dataverse, cada solicitud se hace como ese usuario, y el acceso es lo que permitan los roles de seguridad de ese usuario — el mismo modelo de seguridad que gobierna una aplicación basada en modelos. Nada en el portal se consulta, y nada en el portal puede ampliarlo. La clave es de dónde vienen esos roles: Dataverse permite que un usuario provisionado del portal solo tenga un rol generado por la plataforma , y lo único que los genera son Power Pages. Así que este modelo se apoya en Power Pages de una manera que el resto de Power Portals Pro nunca hace — el paso 3 explica exactamente hasta dónde llega eso.

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

Respaldar un contacto con un usuario de Dataverse depende de una capacidad de plataforma que solo existe una vez que los componentes de Power Pages están en el entorno: el usuario gestionado por el sistema, un registro de usuario que no cuesta licencia y existe para ser suplantado. Si el entorno nunca ha alojado un sitio de Power Pages, crea uno ahora — cualquier plantilla funciona, y un sitio de prueba está bien. Consulta Crear y gestionar un sitio. De esos componentes surgen dos cosas: el usuario que respalda cada contacto y los roles de seguridad que ese usuario puede desempeñar.

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, porque cada usuario provisionado se registra en línea — powerpagesusermapping el enlace entre un contacto y el usuario de Dataverse que lo representa.

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. Conceder acceso con permisos de roles web y tablas

El acceso proviene de los roles de seguridad que desempeña el usuario de Dataverse detrás de cada contacto — pero estos no son roles que puedas escribir. Dataverse solo acepta un rol generado por el sistema en un usuario provisionado del portal, y lo único que los genera es la función que activaste en el paso 2: crea un rol emparejado PowerPages_* para cada rol web en el sitio, y la plataforma lo asigna y desasigna conforme cambia la membresía del rol web del contacto. Por tanto, lo que un usuario del portal puede alcanzar está condicionado por el rol web y los permisos de tabla asociados a él — editados en la aplicación Power Pages Management o, con la solución Power Portals Pro Enhanced Authorization instalada, en la propia página de Roles Web de tu portal. Ese es el único lugar en Power Portals Pro donde un concepto de Power Pages decide a qué puede llegar alguien, y es un requisito de la plataforma más que nuestro diseño. A qué registros accede un usuario se decide por el alcance de permisos de cada tabla, no por la profundidad de propiedad: cada privilegio en un rol generado lleva un filtro de registros de plataforma derivado de él. Leer una tabla puede llegar a otra — leer una cuenta también lee sus direcciones — por lo que esas tablas relacionadas también necesitan permisos de tabla. Ver permisos de tabla.

Nota

Por qué no puedes simplemente asignar un rol que tú mismo creaste. Verificado en un entorno limpio: asignar un rol de seguridad ordinario a un usuario de portal provisionado falla con "El tipo de usuario gestionado por el sistema no es válido para el rol asignado", y crear un rol marcado como generado por el sistema a través de la API se rechaza con "Operación inválida realizada." La restricción es específica del tipo de usuario que prevé el portal — otros usuarios gestionados por el sistema, como un usuario de aplicación, desempeñan roles ordinarios sin queja.

4. Asignar a los usuarios sus roles web

Un contacto obtiene el acceso de un rol web manteniendo el rol web. Para entregar automáticamente los roles web a nuevos usuarios, instala la solución Power Portals Pro Enhanced Authorization y añade reglas en la página de Roles Web de tu portal (WebRoleAdminincluida en ambas plantillas de proyecto): cada regla da un rol web a cada nuevo usuario, o a quienes coinciden con una regla FetchXML sobre contactos. Las reglas se ejecutan una vez por contacto — cuando el portal las registra y cuando un contacto existente inicia sesión con un inicio de sesión externo — por lo que un rol web que un administrador elimina después permanece eliminado. También puedes asignar roles web manualmente en la aplicación Power Pages Management.

Nota

La solución de Autorización Mejorada es independiente de Power Portals Pro Core porque depende de Power Pages. Para asignar roles web, el usuario de la aplicación del portal necesita Read en la tabla de configuración de roles web, Read y AppendTo en roles web, y Read, Append y AppendTo en los componentes del sitio (powerpagecomponent), donde Power Pages almacena los roles web. La página de Roles Web funciona como administrador iniciado sesión, y Dataverse solo permite lo que tanto ellos como el usuario de la aplicación pueden hacer, por lo que el usuario de la aplicación necesita además Crear, Escribir, Eliminar y Añadir en la tabla de configuración; Crear, Escribir, Eliminar y Añadir en roles web; Crear, Leer, Escribir, Eliminar, Añadir y Añadir en la tabla permisos (mspp_entitypermission); Crear, Escribir y Eliminar en componentes del sitio; y AppendTo en sitios web (mspp_website), ya que cada rol web y permiso de tabla nombra el sitio al que pertenece.

5. 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.

6. Habilitar la aprovisionació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.

7. Comprueba lo que realmente puede hacer un usuario

Un usuario provisionado se crea la primera vez que su contacto inicia sesión, así que la comprobación más rápida es iniciar sesión como usuario real del portal y probar qué debería o no debe poder hacer. Su acceso es exactamente lo que permiten sus roles de seguridad: no hay ninguna configuración en el lado del portal delante de él, y nada en el portal la amplía.

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 desconectado están cubiertos por el mismo mecanismo. La plataforma crea un usuario gestionado por el sistema Anónimo para el sitio — identidad PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — y Power Portals Pro lo suplantan para cada solicitud no autenticada. Cualesquiera que sean los roles de seguridad que desempeñe ese usuario son los que puede acceder un visitante anónimo, así que dale el acceso limitado y de solo lectura que debe tener un visitante desconectado, y nada más.

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 la seguridad de la mesa del portal?

Las sesiones bajo este modelo saltan todo lo que describe un registro de tabla — sus operaciones, sus columnas, su alcance de fila y su estampado de propiedad, ya sea que los hayas descrito o AddTableAccess escrito un ITablePermissionProvider — exactamente como los inicios de sesión internos systemuser , porque Dataverse está aplicando en su lugar. A qué filas llega un usuario y a quién pertenece un registro que crea son responsabilidad de sus roles de seguridad, como todo lo demás. No necesitas escribir ni registrar nada de eso. Los registros siguen bloqueando sesiones que no están respaldadas por un usuario provisionado (la función deshabilitada, una sesión donde el provisionamiento falló 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 pueden migrar de forma incremental. Los roles de portal tampoco se aplican a estas sesiones: no se asignan ni se leen bajo este modelo.

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 desde el registro autorizado powerpagesusermapping . El mismo enum se devuelve como GET /api/auth/me CurrentUserResponse.PortalUserType. Utiliza las GetPortalUserType() extensiones y GetDataverseSystemUserId() en ClaimsPrincipal, y nunca presentas una ContactStubUser sesión como un usuario interno.

Las reivindicaciones de rol siguen el mismo modelo. La sesión de un usuario provisionado lleva los roles web que posee — los nombres asignados por un administrador — junto con los PowerPages_* roles de seguridad asociados a ellos, y no hay roles de portal. Gate en roles web con [AuthorizeWebRole("Dealers")] o <PortalRoleView WebRole="Dealers"> en Blazor, y <AuthorizedView webRoles="Dealers"> en React; GET /api/auth/me los lista como webRoles.

Referencia API