Configuração de Conexão Dataverse

Seu portal se comunica com o Dataverse como uma aplicação própria, não como o visitante que está navegando nele. Isso requer duas partes: um registro de aplicativo no Microsoft Entra ID que possui as credenciais, e um usuário de aplicação no seu ambiente Dataverse que dá identidade e papel de segurança a essas credenciais. Esta página percorre ambos, e também pelo acesso que o portal realmente precisa.

Este não é o aplicativo de login

Esse registro é a identidade de serviço do portal — ele lê e escreve dados em nome do portal, e suas credenciais ficam sob D365:ClientId / D365:ClientSecret. Um segundo registro separado gerencia o login dos usuários com a Microsoft. Mantenha os usuários separados: este não precisa de URI de redirecionamento nem permissões delegadas, mas tem muito mais poder dentro do seu ambiente. Veja Configuração de Login do Entra ID

1. Registrar a Inscrição

Crie o registro no centro de administração do Microsoft Entra, no tenant que é dono do seu ambiente Dataverse.

  1. Navegue até Entra ID > Inscrições no aplicativo e selecione Novo registro.
  2. Insira um Nome que identifique o portal e o ambiente, por Contoso Portal — Dataverse (Production)exemplo. Ninguém vê isso na tela de consentimento, então prefira clareza para quem auditar depois.
  3. Em Tipos de conta suportados, escolha Apenas inquilino único. Essa identidade nunca sai da sua organização.
  4. Deixe o URI de Redirecionamento vazio. Nenhum usuário é redirecionado aqui — o portal autentica com o fluxo de credenciais do cliente, máquina para máquina, sem envolver navegador.
  5. Selecione Registrar.
  6. Na página de Visão Geral , copie o ID da aplicação (cliente). Esse valor se torna D365:ClientId, e você precisa dele novamente na etapa 4 para criar o usuário da aplicação.

2. Criar um Segredo do Cliente

O segredo é a única credencial do portal, então trate-a como a chave para os dados do seu ambiente.

  1. Abra Certificados e segredos em Gerenciar e selecione a aba Segredos do Cliente .
  2. Selecione novo segredo do cliente, descreva por ambiente (por exemplo portal-production), e escolha um vencimento.
  3. Copie imediatamente a coluna Valor — não o ID Secreto. Ela é mostrada apenas uma vez, e se torna D365:ClientSecret.

Importante

Quando o segredo expira, o portal para de chegar ao Dataverse completamente — não apenas para um recurso, mas para cada solicitação — então coloque a data de expiração em algum lugar onde você a verá. Para produção, uma credencial de certificado evita o precipício de validade e AuthenticationType.Certificate aceita uma no lugar do segredo.

3. Permissões de API: Nenhuma Necessária

Essa etapa é deliberadamente vazia, e isso surpreende as pessoas. Muitas orientações antigas dizem para adicionar o Dynamics CRM → user_impersonation permissão delegada. Essa permissão é para aplicações que atuam em nome de um usuário logado. O portal não faz isso — ele autentica como ele mesmo, e seu acesso vem inteiramente do usuário da aplicação Dataverse que você cria na próxima etapa.

Nota

A própria orientação servidor para servidor da Microsoft diz o mesmo: quando você se conecta como um aplicativo, não concede o Access Dynamics 365 como usuários da organização, porque o aplicativo está vinculado a uma conta de usuário específica. Adicioná-lo não quebra nada, mas concede uma funcionalidade que o portal nunca exerce — deixe-a desligada.

4. Criar o Usuário da Aplicação no Dataverse

O registro do app sozinho não pode tocar em dados. O Dataverse precisa de um registro de usuário vinculado a ele, que é o que transforma o ID do cliente em uma identidade que seu ambiente reconhece.

  1. Faça login no centro de administração da Power Platform.
  2. Selecione Gerenciar no painel de navegação, depois Ambientes, e então seu ambiente.
  3. Selecione Configurações > Usuários + permissões > Usuários de Aplicativos.
  4. Selecionar + Novo usuário do app.
  5. Selecione + Adicionar um aplicativo e encontre seu registro pelo nome ou pelo ID do cliente na etapa 1, depois selecione Adicionar. Apenas registros no app Entra aparecem nesta lista — aplicativos empresariais não.
  6. Escolha uma unidade de negócios. A unidade de negócios raiz é a resposta usual; uma unidade filha restringe o que o portal pode alcançar mesmo antes de aplicarem funções de segurança.
  7. Selecione o ícone de edição ao lado de papéis de Segurança e atribua os papéis que o portal precisa — o próximo passo cobre quais e por que geralmente há mais de um.
  8. Selecione Criar.

Dica

Um usuário de aplicação não consome nenhuma licença paga, e você só pode ter uma por registro de app Entra por ambiente. Use um registro separado para cada ambiente para que a revogação do acesso ao desenvolvimento nunca toque a produção.

5. Atribuir ao usuário da aplicação um papel de segurança

O usuário da aplicação não pode fazer nada até assumir um papel de segurança. Existem duas rotas, e qual delas está correta depende de uma única pergunta: você se importaria que a credencial do portal alcance dados que o próprio portal nunca mostra?

A rota rápida: Administrador de Sistema

Atribuir Administrador de Sistema funciona, e onde o ambiente não contém nada que você se importe de expor — uma demo, um protótipo, um sandbox cujos dados já são públicos — é uma escolha razoável, não um erro. Apenas faça isso conscientemente. O portal é voltado para a internet, e essa credencial é o que decide até onde um atacante vai se o segredo vazar. Administrador de Sistema significa todas as tabelas do ambiente, incluindo todas as que o portal nunca foi criado para mostrar.

A rota com escopo: nosso papel, mais um do seu próprio

Em qualquer lugar onde existam dados reais, atribui dois papéis. Os papéis de segurança são aditivos, então o usuário da aplicação acaba com a união dos dois — e mantê-los separados é o que permite revisar suas próprias bolsas sem precisar reler as nossas.

  1. Atribuir Power Portals Pro Usuário de Aplicação, que vem na solução gerenciada. Ela concede exatamente o que o framework precisa para rodar, e nada mais. Depois, adicione o usuário da aplicação ao perfil de segurança da coluna de mesmo nome, que vem ao lado: um papel de segurança nunca pode conceder uma coluna segura, e o Power Pages garante duas colunas de contato que o framework escreve como ele mesmo, adx_identity_logonenabled e adx_identity_passwordhash. Sem o perfil, usuários existentes fazem login normalmente e o primeiro registro falha com não tem permissões de criação para um campo seguro Login Habilitado. Faça o mesmo para cada usuário de aplicativo com o qual o portal se conecta, incluindo identidades gerenciadas em um app implantado.
  2. Crie um segundo papel personalizado para suas próprias tabelas. O Dataverse permitiria que você adicionasse eles ao papel de shipped, mas mantendo separados: o papel de shipped é nosso, uma atualização de solução pode reaplicá-lo, e os compromissos misturados deixam de ser revisáveis sem ler o nosso junto com eles. Com o servidor MCP, create_security_role faz e assign_application_user_role entrega ao usuário da aplicação.
  3. Adicione suas tabelas a essa função. Se você usar o servidor MCP, isso não precisa de viagens pelo formulário de papel de segurança — describe_role_table_privileges mostra o que um papel atualmente concede em uma tabela e em que profundidade, e add_table_privileges_to_role concede o que estiver faltando. Conceder nunca tira nada: remove_table_privileges_from_role faz isso, remove privilégios ou diminui a profundidade deles, e delete_security_role exclui um papel quando ninguém o ocupa. Nenhum deles toca um papel gerenciado, incluindo o enviado em missão, então as concessões sempre caem no seu.

Importante

Na autorização aprimorada, atribua Power Portals Pro Application User - Enhanced Authorization em vez disso. Ele vem na solução Power Portals Pro Enhanced Authorization e é um superconjunto do papel acima — todos os privilégios que se concedem, na mesma profundidade, mais os para ler papéis web e manter a Configuração do Papel Web. Ele substitui o papel enviado em vez de se juntar a ele, então atribuir ambos é inofensivo, mas inútil. Sem ele, o portal não pode ler papéis web: novos usuários não recebem nenhum, e o portal não mostra nada sem reportar um erro. O perfil de segurança da coluna ainda é necessário de qualquer forma — nenhum papel de segurança, por mais amplo que seja, pode conceder uma coluna segura.

O que o papel de shipped já cobre

Power Portals Pro Application User é derivado das chamadas que o framework faz como ele mesmo, então ele acompanha o que o framework realmente precisa, em vez do que parecia prudente na época:

O que o portal faz Acesse as necessidades do cargo
Usuários do portal se registram e fazem login Criar, ler e escrever em contact, e Criar, Ler, Escrever e Excluir em adx_externalidentity, que armazena o link entre um usuário do portal e um login externo.
Vincula grades às visualizações do Dataverse e formata valores Continue savedquerylendo, e continue organizationlendo, usersettings e transactioncurrency assim datas, números e formato de moeda corretamente.
Envia e-mail de confirmação e redefinição de senha Criar, ler e escrever em email, e ler no queue endereço do remetente configurado para se resolver.
Funções no portal Criar, ler, escrever e excluir em ppp_portalrole e ppp_portalroleconfiguration, e Append/AppendTo em contact para que os papéis possam ser atribuídos. O próprio portal só lê esses em tempo de execução; os privilégios de escrita estão lá para que RoleManager<PortalRole> funcione para hosts que gerenciam papéis no código, e assim as ferramentas de papel de portal do servidor MCP funcionam em um projeto que se conecta como usuário da aplicação.
Valida a licença do site Permissão para executar a ppp_ProWebsiteLicenseCheck ação e Continuar ppp_powerportalsprowebsite a ler — a ação roda no contexto do chamador, então ela lê os registros do site como usuário da aplicação. A ausência de qualquer um faz com que todos os endpoints licenciados retornem o 402, que parece uma licença expirada, e não um privilégio ausente.
Segurança nativa do Dataverse Criar, ler e escrever em systemuser, continuar businessunit lendo e role, criar e ler em powerpagesusermappingcima , ler sobre powerpagesite, e a lei em nome de outro privilégio de usuário em que a personificação se baseia.

O que ele deliberadamente não cobre são suas próprias tabelas — nenhum cargo que nós fornecemos pode saber quais são, que é para isso que serve o papel personalizado acima. Espere Criar, Ler, Escrever e Excluir em cada tabela que seu portal expor, no escopo que você pretende que os visitantes atinjam. Esse é o principal do trabalho, e é totalmente específico para sua aplicação.

Importante

A personificação reduz o escopo. Nunca o amplia. Sob a segurança nativa do Dataverse, o portal carimba cada solicitação com a identidade do visitante logado, e o Dataverse aplica a interseção entre os privilégios desse visitante e os do usuário da aplicação — uma operação só é permitida se ambos tiverem esse privilégio. Portanto, o papel do usuário da aplicação é um teto para o que qualquer visitante pode fazer. Um visitante cujo próprio papel concede Read em uma tabela ainda não lê nada se o usuário da aplicação não tiver essa função, e adicionar uma tabela ao seu papel personalizado nunca concede a um visitante mais do que o seu próprio cargo já permitido.

6. Armazene as configurações de conexão

O portal lê esses itens a partir da configuração na D365 seção. Mantenha-os em segredos de usuário durante o desenvolvimento para que nunca cheguem ao controle de versão:

EmailSenderEmailAddress é o endereço de onde o e-mail de saída do portal é enviado. Ele deve corresponder a queue ou a habilitar systemuser no ambiente — uma fila é a escolha usual, já que não vincula a correspondência do portal a uma pessoa que pode sair depois.

Criação da fila de remetente

Comece no Exchange Online: criar uma caixa de correio compartilhada para o endereço de onde o portal deve vir a correspondência — no-reply@yourcompany.com é a escolha usual. Uma caixa de correio compartilhada não precisa de licença. Depois, no portal maker, configurações avançadas → Gestão de Negócios → Filas → Novo, dê esse endereço à fila e salve; O Dataverse cria um registro de caixa de correio para ela contra o perfil Exchange Online do ambiente. Uma fila é a resposta certa para um remetente sem resposta, e é melhor do que apontar o portal para a conta de um colega — cujo nome estaria em todas as mensagens automáticas enviadas pelo portal, e cuja saída impediria o envio de tudo.

Importante

A caixa de correio ainda precisa ser aprovada e ativada. Abra o registro da caixa de correio da fila e execute o Aprovar E-mail — que apenas um Administrador Global do Office 365 ou um Administrador do Exchange pode fazer — depois Teste e Habilite a Caixa de Correio. Até que isso seja aprovado, o Dataverse aceita tudo que o portal envia e não entrega nada disso. Nenhum erro chega ao portal, então isso parece exatamente como um e-mail funcionando até que alguém relate nunca ter recebido uma mensagem de redefinição de senha. O servidor create_email_queue MCP faz a fila, a aprovação e o teste em uma única ligação, e check_email_sender explica um remetente que não está entregando.

Dica

Em ambientes hospedados, forneça as mesmas chaves que variáveis de ambiente ou de um armazenamento secreto, usando um duplo sublinhado no lugar do dois-pontos — D365__ClientId, D365__Secret — porque o separador de dois-pontos não é portátil entre plataformas.

Dica

Uma vez implantado no Azure, você pode cancelar ClientSecret completamente. Defina D365:ManagedIdentityId para o id de cliente de uma identidade gerenciada atribuída pelo usuário e o portal autentica como essa identidade — sem segredo, e assim nada para expirar. Ele precisa de seu próprio usuário de aplicação, criado a partir desse id de cliente exatamente como no passo 4. Para um ambiente em outro tenant, defina D365:TenantId também e a identidade se torna a credencial do registro do app em. D365:ClientId Veja implantação Azure.

7. Ligue a conexão

O projeto servidor se configura ConnectionOptions ao registrar o framework:

O modelo do projeto escreve isso para você, então em um projeto gerado não há nada a adicionar aqui — forneça os três valores de configuração e a conexão funciona. Inicie o portal e navegue até qualquer página com dados do Dataverse para confirmar.

Solução de problemas