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.

Nesse modelo, o portal para de decidir o que um usuário pode fazer e o Dataverse decide em vez disso. Cada contato do portal é respaldado por seu próprio usuário do Dataverse, cada solicitação é feita como esse usuário, e o acesso é o que os papéis de segurança desse usuário permitirem — o mesmo modelo de segurança que governa um aplicativo orientado a modelos. Nada no portal é consultado, e nada no portal pode ampliá-lo. A questão é de onde vêm esses papéis: o Dataverse permite que um usuário do portal provisionado tenha apenas um papel gerado pela plataforma , e a única coisa que os gera é o Power Pages. Então, esse modelo realmente se apoia no Power Pages de uma forma que o restante do Power Portals Pro nunca faz — o passo 3 explica exatamente até onde isso vai.

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

Apoiar um contato com um usuário do Dataverse depende de uma capacidade de plataforma que só existe quando os componentes do Power Pages estão no ambiente: o usuário gerenciado pelo sistema, um registro de usuário que não custa licença e existe para ser personificado. Se o ambiente nunca hospedou um site do Power Pages, crie um agora — qualquer modelo funciona, e um site de teste serve. Veja Criar e gerenciar um site. Duas coisas surgem desses componentes: o usuário que sustenta cada contato e os papéis de segurança que esse usuário pode ocupar.

Nota

Você não precisa pagar pelo site nem mantê-lo funcionando — depois que os componentes do framework são instalados e o recurso de segurança ativado, você pode deletar o site em si. O registro do site Power Pages (powerpagesite) referenciado pela sua configuração deve permanecer, porque cada usuário provisionado é registrado em linha powerpagesusermapping — o link entre um contato e o usuário do Dataverse que o representa.

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. Conceder Acesso com Permissão de Papéis Web e Tabelas

O acesso vem dos papéis de segurança ocupados pelo usuário do Dataverse por trás de cada contato — mas esses não são papéis que você pode escrever. O Dataverse aceita apenas um papel gerado pelo sistema em um usuário provisionado do portal, e a única coisa que os gera é o recurso que você habilitou no passo 2: ele cria um papel pareado PowerPages_* para cada função web no site, e a plataforma o atribui e desatribui conforme a associação ao papel web do contato muda. O que um usuário do portal pode acessar é, portanto, moldado pelo papel web e pelas permissões da tabela associadas a ele — editados no aplicativo Power Pages Management ou, com a solução Power Portals Pro Enhanced Authorization instalada, na própria página de Papéis Web do seu portal. Esse é o único lugar no Power Portals Pro onde um conceito do Power Pages decide o que alguém pode alcançar, e é uma exigência da plataforma, não um design nosso. Quais registros um usuário acessa é decidido pelo escopo de permissão de cada tabela, não pela profundidade de propriedade: todo privilégio em um papel gerado carrega um filtro de registro de plataforma derivado dele. Ler uma tabela pode alcançar outra — ler uma conta também lê seus endereços — então essas tabelas relacionadas também precisam de permissões de tabela. Veja permissões de tabela.

Nota

Por que você não pode simplesmente atribuir um papel que você mesmo criou. Verificado em um ambiente limpo: atribuir um papel de segurança comum a um usuário de portal provisionado falha com "O tipo de usuário gerenciado pelo sistema não é válido para o papel atribuído", e criar um papel marcado como gerado pelo sistema pela API é recusado com "Operação Inválida Executada." A restrição é específica para o tipo de usuário que o portal prevê — outros usuários gerenciados pelo sistema, como um usuário de aplicativo, ocupam funções ordinárias sem reclamações.

4. Dê aos Usuários suas Funções na Web

Um contato obtém acesso a uma função web ao manter a função web. Para entregar automaticamente as funções web aos novos usuários, instale a solução Power Portals Pro Enhanced Authorization e adicione regras na página Web Roles do seu portal (WebRoleAdmin, incluída em ambos os modelos de projeto): cada regra dá uma função web para cada novo usuário, ou para aqueles que correspondem a uma regra FetchXML sobre contatos. As regras são executadas uma vez por contato — quando o portal as registra e quando um contato existente faz login pela primeira vez com um login externo — então uma função web que um administrador remove depois permanece removida. Você também pode atribuir funções web manualmente no aplicativo Power Pages Management.

Nota

A solução de Autorização Aprimorada é separada do Power Portals Pro Core porque depende do Power Pages. Para atribuir papéis web, o usuário da aplicação do portal precisa ler na tabela de configuração de papéis web, ler e anexar nos papéis web, e Read, Append e AppendTo nos componentes do site (powerpagecomponent), onde o Power Pages armazena os papéis web. A página de Papéis Web funciona como administrador logado, e o Dataverse permite apenas o que tanto eles quanto o usuário da aplicação podem fazer, então o usuário da aplicação precisa adicionalmente de Crear, Escrever, Deletar e Anexar na tabela de configuração; Crear, Escrever, Deletar e Anexar em funções web; Criar, Ler, Escrever, Deletar permissõesmspp_entitypermission (); Criar, Escrever e Deletar componentes no site; e AppendTo em sites (mspp_website), já que cada função web e permissão de tabela nomeia o site ao qual pertence.

5. Encontre o ID do Site do Seu 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.

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

7. Verifique o que um usuário realmente pode fazer

Um usuário provisionado é criado na primeira vez que seu contato faz login, então a verificação mais rápida é fazer login como usuário real do portal e tentar o que ele deve ou não conseguir fazer. O acesso deles é exatamente o que seus papéis de segurança permitem: nenhuma configuração do lado do portal fica à sua frente, e nada no portal a alarga.

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 mecanismo. A plataforma cria um usuário gerenciado pelo sistema Anônimo para o site — identidade PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — e o Power Portals Pro o personifica para cada solicitação não autenticada. Quaisquer funções de segurança que esse usuário ocupe são as que um visitante anônimo pode alcançar, então dê a ele o acesso restrito e somente leitura que um visitante desconectado deveria ter, e nada mais.

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 à segurança da mesa do portal?

Sessões sob esse modelo contornam tudo o que um registro de tabela descreve — suas operações, suas colunas, seu escopo de linha e seu carimbo de propriedade, seja você que as descreveu com AddTableAccess ou escreveu um ITablePermissionProvider — exatamente como logins internos systemuser , porque o Dataverse está aplicando a lei em vez disso. Quais linhas um usuário alcança e a quem pertence um registro ele cria cabe aos seus papéis de segurança decidir, como tudo o mais. Você não precisa escrever ou registrar nada disso. Os registros ainda bloqueiam sessões que não são respaldadas por um usuário provisionado (o recurso desativado, uma sessão onde o provisionamento falhou e o framework voltou para a segurança do lado do portal, ou visitantes anônimos em um site sem o usuário Anônimo), então portais existentes podem migrar incrementalmente. Os papéis de portal também não se aplicam a essas sessões: eles não são atribuídos nem lidos sob esse modelo.

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 . CurrentUserResponse.PortalUserTypeUse as GetPortalUserType() extensões e GetDataverseSystemUserId() em ClaimsPrincipal, e nunca apresente uma ContactStubUser sessão como um usuário interno.

Reivindicações de papéis seguem o mesmo modelo. A sessão de um usuário provisionado carrega os papéis web que ele possui — os nomes atribuídos por um administrador — junto com os PowerPages_* papéis de segurança pareados a eles, e sem papéis de portais. Gate em funções web com [AuthorizeWebRole("Dealers")] ou <PortalRoleView WebRole="Dealers"> em Blazor, e <AuthorizedView webRoles="Dealers"> no React; GET /api/auth/me os lista como webRoles.

Referência API