Configuração de Segurança Dataverse-Native

Prévia

Esse modelo de segurança está atualmente em pré-visualização — tanto o recurso unificado de segurança Dataverse da Microsoft quanto o suporte do Power Portals Pro para ele. O Power Portals Pro segue o cronograma de lançamentos da Microsoft: assim que o recurso atingir a disponibilidade geral da Microsoft, o suporte do Power Portals Pro também será exibido em prévia. A designação de pré-visualização existe para considerar quaisquer mudanças que a Microsoft possa fazer durante a fase de pré-visualização.

O modelo de segurança nativo do Dataverse permite que o próprio Dataverse impeça segurança para os usuários do seu portal por meio de papéis de segurança padrão, configurados exatamente da mesma forma que o Power Pages os configura — funções web e permissões de tabelas. Esta página explica toda a configuração, de ponta a ponta.

Para saber como o modelo funciona e como ele se relaciona com manipuladores de permissões, veja o Visão geral de segurança

1. Instalar os componentes do framework Power Pages

O modelo de segurança unificado roda em componentes que a Microsoft instala no seu ambiente Dataverse quando um site Power Pages é criado. Se o ambiente nunca hospedou um site Power Pages, crie um agora — qualquer modelo funciona, e um site de teste serve. Veja Criar e gerenciar sites na documentação do Power Pages.

Nota

Você não precisa pagar pelo site nem mantê-lo funcionando — depois que os componentes do framework estiverem instalados e o recurso de segurança ativado, você pode deletar o site em si. O registro do site do Power Pages (powerpagesite) referenciado pela sua configuração deve permanecer no ambiente, já que os mapeamentos de usuário e a sincronização de papéis de segurança resolvem contra ele.

2. Habilitar a Segurança Unificada do Dataverse para o Site

Ative o recurso unificado de segurança do Dataverse da Microsoft para o site seguindo os passos do Unificar a segurança do Power Pages com o Dataverse. Uma vez habilitada, a plataforma cria um papel de segurança Dataverse pareado (nomeado PowerPages_*) para cada função web no site e o mantém sincronizado.

3. Configurar Papéis Web e Permissões de Tabela

No aplicativo Power Pages Management , crie (ou ajuste) as permissões web e as permissões de tabela do site, e vincule cada permissão de tabela para as funções web que devem recebê-las. Essa é a única forma suportada de conceder acesso nesse modelo — a plataforma traduz as permissões da tabela vinculada em privilégios para cada função de segurança sincronizada da web. Os escopos funcionam exatamente como em Power Pages (Global, Contato, Conta, ...), então regras de acesso em nível de registro também são configuradas aqui.

4. Encontre o ID do Site do Power Pages

O PowerPortalsPro precisa do id do registro do powerpagesite site. Você pode consultá-lo diretamente — por exemplo, abrir <your org url>/api/data/v9.2/powerpagesites?$select=name em um navegador e copiar o powerpagesiteid site do seu site.

5. Habilitar o Provisionamento no Power Portals Pro

Configure SecurityOptions no seu servidor Program.cs:

A configuração é validada na inicialização — quando ProvisionSystemUsers ativada, PowerPagesSiteId deve ser definida e resolvida para um registro existente powerpagesite , caso contrário a aplicação não inicia com orientação. A partir desse momento, o PowerPortalsPro automaticamente fornece um sistema gerenciado pelo sistema (C2) systemuser e um powerpagesusermapping registro para cada contato do portal — no registro para novos contatos e preguiçosamente no login para os existentes — e se passa por esse usuário em cada chamada Dataverse.

6. Atribuir Funções Web aos Contatos

Conceda acesso a usuários individuais atribuindo funções web aos seus contatos — no aplicativo Power Pages Management ou programaticamente através do powerpagecomponent_mspp_webrole_contact relacionamento. A plataforma atribui e remove automaticamente os papéis de segurança sincronizados conforme a membresia do papel web muda.

Dica

O Dataverse armazena em cache os privilégios efetivos de cada usuário por nó do servidor, então mudanças de função e privilégio podem levar de alguns segundos até alguns minutos para entrar em vigor após uma atribuição. Leve isso em conta nos testes e em qualquer fluxo que conceda acesso e então aja imediatamente sobre isso.

Visitantes Anônimos

Visitantes desconectados são cobertos pelo mesmo modelo. O Power Pages cria automaticamente um usuário Anônimo para o site — um usuário gerenciado pelo sistema com a identidade PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — e o PowerPortalsPro o imita para cada solicitação não autenticada. Conceda acesso anônimo da forma Power Pages: marque um papel web como o papel de Usuários Anônimos do site no aplicativo Power Pages Management e permita a tabela de links para ele; O papel de segurança sincronizado então determina o que os visitantes desconectados podem ver.

Nota

O usuário Anonymous é criado preguiçosamente pelo Power Pages, então sites criados antes do recurso de segurança unificada podem ainda não ter um (ele é descoberto pelos registros sem powerpagesusermapping contato do site — o usuário em si é invisível a consultas de atributos — e um candidato só é aceito após sua identidade ser verificada contra o conhecido nome de usuário Anonymous). Quando não pode ser encontrado, visitantes anônimos recorrem a manipuladores de permissões do portal — ou seja , não há acesso anônimo a dados a menos que os manipuladores estejam registrados — e o framework registra o resultado na inicialização e tenta novamente periodicamente.

E quanto aos responsáveis pelas permissões?

Sessões sob esse modelo contornam ITablePermissionHandler / ITableRecordPermissionHandler são completamente ignoradas — exatamente como logins internos systemuser — porque o Dataverse impõe a segurança nativamente por meio dos papéis do usuário se passando. Você não precisa escrever ou registrar nenhum código de manipulador de permissões. Os handlers ainda se aplicam a sessões que não são suportadas por um usuário do sistema se passando (o recurso desativado, uma sessão em que o provisionamento falhou e o framework voltou para a segurança do portal, ou visitantes anônimos em um site sem o usuário Anônimo), então portais baseados em handlers existentes podem migrar incrementalmente.

Distinguindo Usuários Provisionados na Sua Interface

As sessões carregam uma PortalUserType reivindicação contendo o valor inteiro do PortalUserType enum: Contact (usuário clássico do portal), SystemUser (login interno real) ou ContactStubUser (um contato respaldado por um usuário gerenciado pelo sistema provisionado); ContactStubUser as sessões também carregam uma SystemUserId reivindicação com o ID do usuário provisionado, resolvida a partir do registro autoritativo powerpagesusermapping . O mesmo enum é retornado por GET /api/auth/me . CurrentUserInfo.PortalUserType Use as GetPortalUserType() extensões e GetDataverseSystemUserId() em ClaimsPrincipal, e nunca apresente uma ContactStubUser sessão como um usuário interno.

Referência API