Configuración de conexión Dataverse

Tu portal se comunica con Dataverse como una aplicación en sí misma, no como el visitante que casualmente está navegando por él. Eso tiene dos partes: un registro de la app en Microsoft Entra ID que posee las credenciales, y un usuario de aplicación en tu entorno Dataverse que les da una identidad y un rol de seguridad. Esta página recorre ambas y el acceso que realmente necesita el portal.

Esta no es la app de inicio de sesión

Este registro es la identidad de servicio propia del portal: lee y escribe datos en nombre del portal, y sus credenciales van bajo D365:ClientId / D365:ClientSecret. Un segundo registro separado gestiona la entrada de usuarios con Microsoft. Manténlos separados: este no necesita URI de redirección ni permisos delegados, pero tiene mucho más poder dentro de tu entorno. Consulta la configuración de inicio de sesión de Entra ID

1. Registrar la solicitud

Crea el registro en el centro de administración de Microsoft Entra, en el tenant que posee tu entorno Dataverse.

  1. Navega por Entra ID > Registros de la app y selecciona Nuevo registro.
  2. Introduce un Nombre que identifique el portal y el entorno, por Contoso Portal — Dataverse (Production)ejemplo. Nadie ve esto en una pantalla de consentimiento, así que prefiere claridad para quien lo audite después.
  3. En Tipos de cuenta soportados, elige Solo inquilino único. Esta identidad nunca abandona tu organización.
  4. Deja el URI de redirección vacío. Ningún usuario es redirigido aquí: el portal se autentica con el flujo de credenciales del cliente, máquina a máquina, sin navegador involucrado.
  5. Selecciona Registrarse.
  6. En la página de Resumen , copia el ID de la aplicación (cliente). Ese valor se convierte D365:ClientIden , y lo necesitas de nuevo en el paso 4 para crear el usuario de la aplicación.

2. Crear un secreto para el cliente

El secreto es la única credencial del portal, así que trátalo como la clave de los datos de tu entorno.

  1. Abre Certificados y secretos en Gestionar y selecciona la pestaña de secretos del cliente.
  2. Selecciona nuevo secreto de cliente, descríbelo por entorno (por ejemplo portal-production), y elige un plazo de expiración.
  3. Copia la columna Valor inmediatamente — no el ID Secreto. Solo se muestra una vez, y se convierte D365:ClientSecreten .

Importante

Cuando el secreto expira, el portal deja de llegar a Dataverse por completo — no solo para una función, sino para cada solicitud — así que pon la fecha de caducidad en algún lugar donde la verás. Para producción, una credencial de certificado evita el precipicio de caducidad y AuthenticationType.Certificate acepta una en lugar del secreto.

3. Permisos de API: No se requieren

Este paso está deliberadamente vacío, y eso sorprende a la gente. Muchas indicaciones antiguas te dicen que añadas el permiso delegado de Dynamics CRM → user_impersonation . Ese permiso es para aplicaciones que actúan en nombre de un usuario iniciado sesión. El portal no hace eso: se autentica como él mismo, y su acceso viene íntegramente del usuario de la aplicación Dataverse que crees en el siguiente paso.

Nota

La propia guía servidor a servidor de Microsoft dice lo mismo: cuando te conectas como app, no concedes Access Dynamics 365 como usuarios de la organización, porque la aplicación está vinculada a una cuenta de usuario específica. Añadirla no rompe nada, pero otorga una capacidad que el portal nunca ejerce — déjala desactivada.

4. Crear el usuario de la aplicación en Dataverse

El registro de la app por sí solo no puede tocar los datos. Dataverse necesita un registro de usuario vinculado a él, que es lo que convierte el id del cliente en una identidad que tu entorno reconoce.

  1. Inicia sesión en el centro de administración de Power Platform.
  2. Selecciona Gestionar en el panel de navegación, luego Entornos y después tu entorno.
  3. Selecciona Configuración > Usuarios + permisos > Usuarios de la Aplicación.
  4. Seleccionar + Nuevo usuario de la app.
  5. Selecciona + Añadir una app y busca tu registro por nombre o por el ID del cliente desde el paso 1, luego selecciona Añadir. Solo aparecen registros en la app Entra en esta lista — las aplicaciones empresariales no.
  6. Elige una unidad de negocio. La unidad raíz es la respuesta habitual; una unidad hija reduce lo que el portal puede alcanzar incluso antes de que se apliquen roles de seguridad.
  7. Selecciona el icono de edición junto a Roles de Seguridad y asigna los roles que necesita el portal — el siguiente paso cubre cuáles y por qué suele haber más de uno.
  8. Selecciona Crear.

Propina

Un usuario de aplicación no consume ninguna licencia de pago, y solo puedes tener una por cada registro de una app de Entra por entorno. Usa un registro separado para cada entorno para que la revocación del acceso al desarrollo nunca afecte producción.

5. Asignar al usuario de la aplicación un rol de seguridad

El usuario de la aplicación no puede hacer nada hasta que cumpla un rol de seguridad. Hay dos vías, y cuál es la correcta depende de una sola pregunta: ¿te importaría que la credencial del portal alcance a los datos que el portal en sí nunca muestra?

La ruta rápida: Administrador del Sistema

Asignar Administrador de Sistema funciona, y donde el entorno no contiene nada que te importe exponer — una demo, un prototipo, un sandbox cuyos datos ya son públicos — es una elección razonable más que un error. Simplemente hazlo conscientemente. El portal está orientado a internet, y esta credencial es la que decide hasta dónde llega un atacante si el secreto llega a filtrarse. Administrador de Sistema significa todas las tablas del entorno, incluidas todas las que el portal nunca fue diseñado para mostrar.

La ruta con alcance: nuestro rol, más uno propio

En cualquier lugar donde existan datos reales, asigna dos roles. Los roles de seguridad son aditivos, por lo que el usuario de la aplicación acaba con la unión de ambos — y mantenerlos separados es lo que te permite revisar tus propias subvenciones sin tener que releer las nuestras.

  1. Asignar Power Portals Pro Usuario de la Aplicación, que viene incluida en la solución gestionada. Concede exactamente lo que el framework necesita para funcionar, y nada más. Luego añade el usuario de la aplicación a la columna de perfil de seguridad del mismo nombre, que viene junto a él: un rol de seguridad nunca puede conceder una columna segura, y Power Pages asegura dos columnas de contacto que el framework escribe como sí mismo, adx_identity_logonenabled y adx_identity_passwordhash. Sin el perfil, los usuarios existentes inician sesión normalmente y el primer registro falla con no tiene permisos de creación para un campo seguro Inicio de sesión habilitado. Haz lo mismo para cada usuario de aplicación que el portal conecte, incluyendo una identidad gestionada en una aplicación desplegada.
  2. Crea un segundo rol personalizado para tus propias tablas. Dataverse te permitiría añadirlas al rol de envío en su lugar, pero manteniéndolas separadas: el rol de envío es nuestro, una actualización de solución puede volver a aplicarlo y las garantías que mezcladas en él dejan de ser revisables sin leer las nuestras junto con ellas. Con el servidor MCP, create_security_role lo crea y assign_application_user_role se lo da al usuario de la aplicación.
  3. Añade tus tablas a ese rol. Si usas el servidor MCP, esto no necesita pasar por el formulario de rol de seguridad — describe_role_table_privileges muestra lo que un rol otorga actualmente en una tabla y a qué profundidad, y add_table_privileges_to_role concede lo que falta. Conceder nunca quita nada: remove_table_privileges_from_role eso hace, elimina privilegios o reduce su profundidad, y delete_security_role elimina un rol cuando nadie lo tiene. Ninguno de ellos toca un rol gestionado, incluido el asignado, así que las concesiones siempre acaban en el tuyo.

Importante

En la autorización mejorada, asigna Power Portals Pro Application User - Enhanced Authorization en su lugar. Se incluye en la solución Power Portals Pro Enhanced Authorization y es un superconjunto del rol anterior — todos los privilegios que se conceden, a la misma profundidad, más los para leer roles web y mantener la configuración de roles web. Reemplaza el rol asignado en lugar de unirse a él, por lo que asignar ambos es inofensivo pero inútil. Sin él, el portal no puede leer roles web: a los nuevos usuarios no se les asigna ninguno, y el portal no les muestra nada sin informar de un error. El perfil de seguridad de columna sigue siendo necesario de cualquier forma — ningún rol de seguridad, por amplio que sea, puede conceder una columna segura.

Lo que ya cubre el rol de shipped

Power Portals Pro Application User se deriva de las llamadas que el framework hace como él mismo, por lo que rastrea lo que realmente necesita el framework en lugar de lo que parecía prudente en ese momento:

Qué hace el portal Acceder a las necesidades del puesto
Registros y inicios de sesión en los usuarios del portal Crear, leer y escribir en contact, y Crear, Leer, Escribir y Eliminar en adx_externalidentity, que almacena el enlace entre un usuario del portal y un inicio de sesión externo.
Vincula las cuadrículas a las vistas de Dataverse y formatea los valores Sigue savedqueryleyendo, y leyendo bien organization, usersettings y transactioncurrency así fechas, números y formato de moneda correctamente.
Envía un correo de confirmación y restablecimiento de contraseña Crear, leer y escribir en email, y leer en la queue dirección del remitente configurada se resuelve.
Roles en el portal Crear, Leer, Escribir y Eliminar en ppp_portalrole y ppp_portalroleconfiguration, y Añadir/Anexar para contact que se puedan asignar roles. El propio portal solo los lee en tiempo de ejecución; los privilegios de escritura están ahí para que RoleManager<PortalRole> funcione para los hosts que gestionan roles en el código, y así las herramientas de rol del portal del servidor MCP funcionan en un proyecto que se conecta como usuario de la aplicación.
Valida la licencia del sitio web Permiso para ejecutar la ppp_ProWebsiteLicenseCheck acción y Seguir ppp_powerportalsprowebsite leyendo — la acción se ejecuta en el contexto del llamante, por lo que lee los registros web como el usuario de la aplicación. Al faltar cualquiera de los dos, todos los endpoints licenciados devuelven 402, que se lee como una licencia caducada en lugar de un privilegio perdido.
Seguridad nativa de Dataverse Crear, leer y escribir en systemuser, leer y businessunit role, Crear y leer sobre powerpagesusermapping, Leer sobre powerpagesite, y el Acto en nombre de otro usuario en el privilegio en que se basa la suplantación.

Lo que deliberadamente no cubre son tus propias tablas — ningún rol que asignamos puede saber cuáles son, que es para lo que sirve el rol personalizado anterior. Espera Crear, Leer, Escribir y Eliminar en cada tabla que exponga tu portal, en el alcance que pretendes que los visitantes alcancen. Ese es la mayor parte del trabajo y es totalmente específico para tu aplicación.

Importante

La suplantación de identidad reduce el alcance. Nunca lo amplía. Bajo la seguridad nativa de Dataverse, el portal sella cada solicitud con la identidad del visitante iniciado sesión, y Dataverse aplica la intersección entre los privilegios de ese visitante y los del usuario de la aplicación — una operación solo está permitida si ambos tienen ese privilegio. Así que el rol del usuario de la aplicación es un techo de lo que cualquier visitante puede hacer. Un visitante cuyo propio rol otorga Read en una tabla sigue sin leer nada si el usuario de la aplicación no lo tiene, y añadir una tabla a tu rol personalizado nunca otorga a un visitante más de lo que ya está permitido.

6. Guardar la configuración de conexión

El portal los lee desde la configuración en la D365 sección. Guárdalos en secretos de usuario durante el desarrollo para que nunca lleguen al control de versiones:

EmailSenderEmailAddress es la dirección desde la que se envía el correo saliente del portal. Debe coincidir con a queue o habilitado systemuser en el entorno — la cola es la opción habitual, ya que no vincula el correo del portal a una persona que podría marcharse más adelante.

Creación de la cola de remitentes

Empieza en Exchange Online: crear un buzón compartido para la dirección de la que debe provenir el correo — no-reply@yourcompany.com es la opción habitual. Un buzón compartido no necesita licencia. Luego, en el portal maker, Configuración avanzada → Gestión Empresarial → Colas → Nuevo, asigna esa dirección a la cola y guarda; Dataverse crea un registro de buzón para él contra el perfil Exchange Online del entorno. Una cola es la respuesta correcta para un remitente sin respuesta, y es mejor que apuntar el portal a la cuenta de un compañero — cuyo nombre estaría en todos los mensajes automáticos que envía el portal y cuya salida impediría que se enviara por completo.

Importante

El buzón aún tiene que ser aprobado y habilitado. Abre el registro del buzón de la cola y ejecuta Aprobar Correo — que solo puede hacer un Administrador Global de Office 365 o un Administrador de Exchange — y luego Prueba y Habilita el Buzón. Hasta que eso pase, Dataverse acepta todo lo que envía el portal y no entrega nada de ello. No llega ningún error al portal, así que esto parece exactamente como un correo funcionando hasta que alguien reporta que nunca ha recibido un mensaje de restablecimiento de contraseña. El servidor create_email_queue MCP hace la cola, la aprobación y la prueba en una sola llamada, y check_email_sender explica un remitente que no está entregando.

Propina

En entornos alojados, suministra las mismas claves que variables de entorno o desde una tienda secreta, usando un doble guion en lugar de los dos puntos — D365__ClientId, D365__Secret — porque el separador de dos puntos no es portátil entre plataformas.

Propina

Una vez desplegado en Azure puedes eliminar ClientSecret por completo. Configura D365:ManagedIdentityId el id de cliente de una identidad gestionada asignada por el usuario y el portal se autentica como esa identidad en su lugar — sin secreto, y por tanto nada que caduque. Necesita su propio usuario de aplicación, creado a partir de ese id de cliente exactamente como en el paso 4. Para un entorno en otro tenant, también se establece D365:TenantId y la identidad se convierte en la credencial del registro de la app en D365:ClientId su lugar. Consulta despliegue de Azure.

7. Conectar la conexión

El proyecto servidor se ConnectionOptions configura al registrar el framework:

La plantilla del proyecto escribe esto por ti, así que en un proyecto generado no hay nada que añadir aquí — proporciona los tres valores de configuración y la conexión funciona. Inicia el portal y navega a cualquier página respaldada por datos de Dataverse para confirmarlo.

Resolución de problemas