OpenID Connect e Login SAML

Além de Microsoft, Google e Facebook, um portal pode fazer login com pessoas por qualquer provedor de identidade OpenID Connect ou SAML 2.0 : Okta, Auth0, Microsoft Entra External ID, o próprio inquilino Entra de um cliente ou parceiro, AD FS, Ping, Google Workspace. Cada provedor configurado é um botão na página de login e não precisa de código.

Um login por meio de um desses provedores é pareado, vinculado ou cadastro como contato exatamente como um login da Microsoft ou Google. Usuários internos (usuários do sistema) fazem login com a Microsoft — veja Configuração de Login do ID Entra.

Ligue

Projetos criados a partir dos templates para usuários externos já possuem isso em Program.cs. Ele lê todos os provedores configurados sob Authentication:OpenIdConnect e Authentication:Saml2, e não adiciona nenhum até que um seja configurado:

O SAML vem do PowerPortalsPro.Identity.Saml2 pacote, que esses projetos referenciam. Um projeto criado antes desse recurso precisa da chamada e do pacote adicionado.

Endereços para registrar com o provedor

Cada provedor tem um nome — a chave de sua seção de configuração, ContosoOkta nos exemplos abaixo — e os endereços para os quais o provedor envia as pessoas de volta são feitos a partir dele em minúsculas. Registre-os exatamente, uma vez para cada host onde o portal roda.

O que Endereço
URI de redirecionamento do OpenID Connect https://your-portal.example.com/signin-{name}
Serviço ao consumidor de asserção SAML (HTTP-POST) https://your-portal.example.com/saml2/{name}/acs
ID de entidade SAML (público) https://your-portal.example.com/saml2/{name}
Metadados SAML do portal https://your-portal.example.com/saml2/{name}/metadata

Os endereços são os mesmos em todos os idiomas. Um login iniciado em uma página em outro idioma — /es/… — retorna pelo próprio endereço do site e depois para a página onde começou, naquele idioma.

Provedores OpenID Connect

Adicione uma seção para cada provedor em Authentication:OpenIdConnect. Mantenha o segredo do cliente nos segredos de usuário localmente e no Key Vault após a implantação.

Ambientação O que é
DisplayNameO nome no botão de login. O nome padrão é o do provedor.
AuthorityO emissor do provedor — o endereço sob o qual ele /.well-known/openid-configuration está. Exigido, a menos que MetadataAddress seja fornecido.
MetadataAddressO próprio endereço do documento de descoberta, para um provedor que o publica em outro lugar.
ClientId, ClientSecretO ID do cliente do portal e o segredo do provedor. Obrigatório.
ScopesEscopos para pedir além openidde , profile e email, que são sempre solicitados.
CallbackPathO caminho do URI de redirecionamento, quando /signin-{name} não serve.
TrustedEmailDomainsOs domínios de e-mail para os quais este provedor é confiável — veja Quais endereços são confiáveis abaixo. Vazio por padrão. Em uma configuração de Serviço de Aplicativo, escreva separado por vírgulas.
GetClaimsFromUserInfoEndpointSe deve ler o perfil do endpoint de informações do usuário do provedor, assim como o token ID. Ativado por padrão, já que alguns provedores não colocam e-mail no token ID.

O portal utiliza o fluxo de código de autorização com PKCE, faz login pelo cookie externo da Identity e não mantém tokens. Ele lê o ID da pessoa a partir de sub, e seu endereço e nome a partir de email, given_name e family_name.

Okta (OpenID Connect)

  1. Crie uma integração de app: OIDC - OpenID Connect, do tipo Aplicação Web, com a concessão de Código de Autorização .
  2. Adicione o URI de redirecionamento do portal como um URI de redirecionamento de login, assigne as pessoas ou grupos que possam fazer login e copie o id do cliente e o segredo.
  3. A autoridade é o emissor do seu servidor de autorização, por https://contoso.okta.com/oauth2/defaultexemplo.

Auth0

  1. Crie uma aplicação do tipo Aplicação Web Regular.
  2. Adicione o URI de redirecionamento do portal para URLs de Retorno de Chamada Permitidos e copie o id do cliente e o segredo.
  3. A autoridade é o domínio do seu locatário, por exemplo, https://contoso.us.auth0.com/ou seu domínio personalizado.

Microsoft Entra External ID

  1. No tenant externo, registre uma aplicação com o URI de redirecionamento do portal como um URI de redirecionamento Web e adicione um segredo do cliente.
  2. Crie um fluxo de usuário de cadastro e login e adicione o aplicativo a ele.
  3. A autoridade é https://<tenant subdomain>.ciamlogin.com/<tenant id>/v2.0. Quando o fluxo de usuários verifica cada endereço antes de uma conta ser criada — e-mail com senha e senha de e-mail único fazem ambos — este é um provedor de identidade que você administra para seus próprios clientes, e TrustedEmailDomains pode ser *.

Inquilino Entra de um cliente ou parceiro

Para uma organização cujas pessoas devem fazer login com suas próprias contas de trabalho, sem o botão Microsoft multi-inquilino:

  1. No locatário deles, registre uma única aplicação de tenant com o URI de redirecionamento do portal como um URI de redirecionamento Web e adicione um segredo do cliente.
  2. A autoridade é https://login.microsoftonline.com/<their tenant id>/v2.0.
  3. Liste os domínios deles em TrustedEmailDomains; um endereço em qualquer outro lugar é confirmado primeiro por e-mail. O ID do locatário chega à sessão, assim como acontece com o botão Microsoft. As próprias reivindicações de verificação do Entra (xms_edov, verified_primary_email) não são retiradas de um provedor: o locatário por trás delas administra as reivindicações enviadas.

Provedores SAML 2.0

Adicione uma seção para cada provedor em Authentication:Saml2. Os metadados do provedor fornecem ao portal seu endereço de login e os certificados com os quais suas respostas são assinadas; ele é lido novamente todos os dias, então um certificado que o provedor transfere é retirado.

Ambientação O que é
DisplayNameO nome no botão de login. O nome padrão é o do provedor.
MetadataAddressO endereço dos metadados do provedor de identidade. Exigido, e deve ser https.
IdentityProviderEntityIdO ID da entidade do provedor de identidade, cujas respostas devem ser emitidas. O padrão é o que seus metadados nomeiam.
EntityIdO próprio ID da entidade do portal. O padrão é https://{host}/saml2/{name} no host para onde a solicitação veio; configure quando o portal responde em mais de um host, para que compartilhem um registro no provedor.
CallbackPath, MetadataPathOs caminhos do serviço ao consumidor e dos metadados de afirmação, quando /saml2/{name}/acs e /saml2/{name}/metadata quando não servirão.
TrustedEmailDomainsOs domínios de e-mail para os quais este provedor é confiável — veja Quais endereços são confiáveis abaixo. Vazio por padrão. Em uma configuração de Serviço de Aplicativo, escreva separado por vírgulas.
AllowIdentityProviderInitiatedAceita logins, o provedor inicia — alguém abrindo o portal a partir de um bloco no painel do provedor. Desligado por padrão. Eles vão para a página externa de login do portal e depois para uma página local nomeada pelo RelayState (/orders ou ReturnUrl=/orders). Cada resposta é aceita uma vez por servidor.
RequireHttpsMetadataSe MetadataAddress deve ser https. Ligado por padrão; desligue apenas para tentar um provedor rodando na sua própria máquina.

As respostas devem ser assinadas por um certificado nos metadados do provedor, emitido pelo ID da entidade do portal, para o ID da entidade do portal, enviado ao serviço de consumo assertivo e, em resposta à solicitação feita pelo mesmo navegador. O NameID identifica a conta, portanto ela deve ser persistente ou o endereço de e-mail; um endereço temporário é recusado. O endereço e o nome são lidos a partir dos atributos que os provedores comumente utilizam: email, mail, emailaddress e os nomes da reivindicação WS-Federation, e givenName / firstName ou surname lastName.

Microsoft Entra ID (aplicação empresarial)

  1. Crie uma aplicação empresarial, integre qualquer outro aplicativo que você não encontrar na galeria e escolha login único SAML .
  2. Defina o Identificador (ID da Entidade) para o ID da entidade do portal e URL de resposta para o serviço consumidor de asserção.
  3. Copie a URL de Metadados da Federação de Aplicativos para MetadataAddress, e apresente os usuários ou grupos que possam fazer login.

Okta (SAML)

  1. Crie uma integração de app do tipo SAML 2.0.
  2. Defina URL de Single Log-on para o serviço consumidor de asserção e URI de Audiência (ID de Entidade SP) para o ID de entidade do portal; escolha um formato de ID de nome Persistente ou de Endereço de E-Mail, e adicione email, e lastName as instruções de atributofirstName.
  3. Copie a URL de Metadados da aplicação para o MetadataAddressarquivo .

AD FS

  1. Adicione um trust de parte confiável, importando os metadados do portal de seu endereço.
  2. Adicione regras de emissão de reivindicações que enviam o endereço de e-mail, nome e sobrenome, e um ID de nome persistente.
  3. MetadataAddress é https://<your AD FS host>/FederationMetadata/2007-06/FederationMetadata.xml.

Solicitações assinadas e asserções criptografadas

A maioria dos provedores não precisa de nenhum dos dois. Para um que exige solicitações de autenticação assinadas ou criptografa suas asserções, adicione o provedor em código com os certificados; ambos são publicados nos metadados do portal para que o provedor importe.

Quais endereços são confiáveis

Um login cujo endereço o portal confia vai direto para o contato que o possui, e uma nova conta começa com esse endereço confirmado. Qualquer outro endereço é confirmado por e-mail primeiro, uma vez; depois disso, o link entre o login e o contato é o que o encontra.

Importante

* Confia em cada endereço que o provedor reivindica. Use-o apenas para um provedor de identidade que você administra para seus próprios usuários e que verifique endereços antes de afirmá-los. Nunca o use para um provedor administrado por um cliente ou parceiro: qualquer pessoa que administre pode criar uma conta com qualquer endereço, incluindo um pertencente a um contato de outra organização, e entraria como esse contato.

Botões de login

Cada provedor é um botão na página de login, rotulado com seu nome de exibição. Mais quatro configurações na seção do provedor mudam a aparência do botão e onde ele fica:

Ambientação O que é
IconUm pequeno logo mostrado antes do nome no botão padrão — o próprio logo do cliente no login, por exemplo.
ButtonImageUma imagem mostrada em vez do botão padrão: o próprio botão "Entrar com ..." do provedor. O botão.
ButtonImageDarkA mesma imagem para o tema sombrio. Sem ela, ButtonImage é usada em ambos.
OrderOnde o botão fica: o menor vem primeiro, e botões com a mesma ordem mantêm a ordem em que seus provedores foram adicionados. 0 por padrão.

Uma imagem é um caminho a partir da raiz do site — um arquivo no wwwrootportal , como /images/contoso-logo.svg — ou um https endereço. Um caminho é servido a partir da raiz do site em cada página, em todos os idiomas. Qualquer outra coisa para o portal na inicialização, nomeando a configuração.

Qualquer outro botão de provedor, incluindo o da Microsoft e do Google, é alterado no código:

Microsoft, Google e Facebook mostram seus próprios botões "Entrar com ..." em versões claras e escuras, a menos que você configure um desses botões.

Solução de problemas