Login SystemUser

O Power Portals Pro reconhece registros do Dataverse systemuser logados como usuários do portal — junto com os usuários respaldados por padrão contact. Não é necessária configuração: quando um usuário faz login via autenticação Microsoft, o portal primeiro procura uma correspondência systemuser; se existir uma, a sessão roda como aquele usuário do sistema e o Dataverse impõe a segurança por meio da personificação. Se nenhum usuário do sistema correspondente for encontrado, o login retorna ao caminho de contato. O mesmo portal pode atender funcionários internos licenciados pelo Dataverse e contatos externos de clientes ao mesmo tempo.

Quando isso importa

O fluxo respaldado pelo usuário do sistema é útil quando:

• O portal atende funcionários — funcionários, agentes de suporte, parceiros com licenças Dataverse — que já estão provisionados como usuários do sistema.
• Você quer que os papéis de segurança do Dataverse sejam a única fonte de verdade sobre o que esses usuários podem ver e fazer.
• Você não quer duplicar identidade mantendo um registro paralelo contact para cada usuário da equipe.

Apenas autenticação Microsoft

Somente o provedor externo Microsoft / Entra ID pode resolver para um usuário do sistema; os usuários são pareados contra systemuser.azureactivedirectoryobjectid, e qualquer usuário do sistema com isdisabled = true é bloqueado. Nome de usuário/senha local e outros provedores externos (Google, etc.) sempre fazem login como contato.

Como funciona

Em um login da Microsoft, o portal:

1. Consulta o ID de Objeto Azure AD autenticado contra systemuser.azureactivedirectoryobjectid. Se um registro ativo coincidir, a sessão é vinculada àquele usuário do sistema.
2. Caso contrário, retorna ao fluxo de contato (correspondendo ao login externo através adx_externalidentityde ).
3. Para sessões de usuário do sistema, ServiceClient.CallerId está definido para systemuserid que toda chamada Dataverse seja executada como o usuário logado — com seus papéis de segurança, escopo da unidade de negócios e acesso em nível de linha. O lado ITablePermissionHandler do portal / ITableRecordPermissionHandler instâncias são ignorados para o pedido.
4. Grades, formulários e botões refletem os privilégios reais do usuário no Dataverse — calculados e RetrieveUserPrivilegesRequest armazenados em cache por usuário. As sessões de contato continuam a fluir pelos manipuladores registrados como antes.

Modelo de segurança

Para sessões suportadas por systemuser, porque CallerId a personificação delega a aplicação ao Dataverse:

• A segurança em nível de registro e coluna vem do(s) papel(es) de segurança do usuário logado(s) do Dataverse — não do código do portal.
• Segurança em nível de campo, propriedade hierárquica e escopo de unidades de negócios se aplicam automaticamente.
• Os manipuladores de permissões do lado do portal (ITablePermissionHandler / ITableRecordPermissionHandler) são ignorados para a solicitação. Eles continuam funcionando normalmente para sessões apoiadas por contato no mesmo portal.
• Os papéis de segurança do usuário no Dataverse são projetados no principal como ClaimTypes.Role reivindicações, então atributos e User.IsInRole(...) verificações existentes [Authorize(Roles = "…")] atuam contra eles sem uma ida e volta extra no Dataverse por requisição. As reivindicações atualizam na validação principal, então as atribuições de funções feitas no Dataverse são captadas dentro do intervalo de carimbo de segurança (~10 minutos) sem forçar um re-log-in.

Administradores: testes como contato

Os administradores do portal normalmente precisam verificar a experiência do lado do contato — a página inicial é renderizada corretamente para um cliente logado? Esse caso esconde corretamente o botão da barra de ferramentas? — sem perder a capacidade de realizar ações administrativas. O Power Portals Pro suporta isso diretamente: um administrador pode manter um login Microsoft vinculado tanto systemuser a um (conta interna deles) quanto a contact um (registro de teste, ou seu próprio registro do lado do cliente), e alternar entre os dois sem fazer logout.

• Escolha ao fazer login. Quando um login da Microsoft resolve para mais de uma identidade, a página pós-retorno mostra um seletor listando cada candidato (tipo + nome de exibição + e-mail). Escolher um faz com que o usuário fique com essa identidade pelo resto da sessão.
• Lembrei da escolha. O escolhedor escreve um pequeno cookie por chave de provedor, então os logins subsequentes pulam o prompt e vão direto para a última identidade escolhida. A seleção lembrada é atualizada sempre que o usuário troca durante a sessão, então o próximo log-in ambíguo honra a nova preferência.
• Interruptor durante a sessão. Quando o usuário logado tem uma identidade irmã, uma entrada Switch para contato / Switch para systemuser aparece no menu do perfil. Ele posta em /api/auth/switch-identity, que reemite o cookie de autenticação para a identidade alternativa — não é necessário fazer uma viagem de ida e volta de OAuth nova. O endpoint lê o id de identidade alternativa do principal (nunca do corpo da solicitação), então um clique adulterado não pode fazer o usuário entrar como outra pessoa.

Públicos mistos: projetem seus dados de acordo

Um único portal pode atender tanto usuários do sistema quanto usuários de contato na mesma implantação. Se suas personalizações incluem filtros FetchXML que definem linhas ( adx_contactid == currentUserId um padrão comum em portais apenas de contato), esses filtros não farão sentido quando o usuário logado for um usuário do sistema. Faça ramificações no código de personalização no tipo de usuário para que cada público veja os dados adequados para ele.

Caches de privilégios

O mapa de metadados de privilégios em todo o ambiente é carregado uma vez na inicialização da aplicação e armazenado em cache indefinidamente; Reinicie a aplicação (ou chamada IPrivilegeMetadataCache.InvalidateAsync) para captar novas tabelas ou alterações no esquema de privilégios. Os privilégios efetivos de cada usuário do sistema logado são armazenados em cache por 24 horas e podem ser despejados com IUserPrivilegeCache.InvalidateAsync(userId).