Utilizar um Fornecedor de Identidade (IdP) SAML 2.0 para Início de Sessão Único

Este documento contém informações sobre como usar um provedor de identidade baseado em perfil SP-Lite compatível com SAML 2.0 como o STS (Serviço de Token de Segurança) / provedor de identidade preferido. Esse cenário é útil quando você já tem um diretório de usuário e um armazenamento de senha no local que podem ser acessados usando o SAML 2.0. Esse diretório de usuário existente pode ser usado para fazer logon no Microsoft 365 e outros recursos protegidos por ID do Microsoft Entra. O perfil SAML 2.0 SP-Lite é baseado no padrão de identidade federada SAML (Security Assertion Markup Language) amplamente usado para fornecer uma estrutura de logon e troca de atributos.

A Microsoft oferece suporte a essa experiência de logon como a integração de um serviço de nuvem da Microsoft, como o Microsoft 365, com seu IdP baseado em perfil SAML 2.0 configurado corretamente. Os provedores de identidade SAML 2.0 são produtos de terceiros e, portanto, a Microsoft não fornece suporte para as práticas recomendadas de implantação, configuração e solução de problemas relacionadas a eles. Uma vez configurada corretamente, a integração com o provedor de identidade SAML 2.0 pode ser testada para a configuração adequada usando a ferramenta Microsoft Connectivity Analyzer Tool, que é descrita com mais detalhes abaixo. Para obter mais informações sobre seu provedor de identidade baseado em perfil SAML 2.0 SP-Lite, pergunte à organização que o forneceu.

Todos os outros clientes não estão disponíveis neste cenário de início de sessão com o seu Fornecedor de Identidade SAML 2.0. Por exemplo, o cliente de área de trabalho do Lync 2010 não consegue entrar no serviço com seu provedor de identidade SAML 2.0 configurado para logon único.

Requisitos do protocolo Microsoft Entra SAML 2.0

Este documento contém requisitos detalhados sobre o protocolo e a formatação de mensagens que seu provedor de identidade SAML 2.0 deve implementar para federar com o Microsoft Entra ID para habilitar o logon em um ou mais serviços de nuvem da Microsoft (como o Microsoft 365). A terceira parte confiável SAML 2.0 (SP-STS) para um serviço de nuvem da Microsoft usado neste cenário é o Microsoft Entra ID.

É recomendável garantir que as mensagens de saída do provedor de identidade SAML 2.0 sejam o mais semelhantes possível aos rastreamentos de exemplo fornecidos. Além disso, use valores de atributos específicos dos metadados fornecidos do Microsoft Entra sempre que possível. Quando estiver satisfeito com as mensagens de saída, você poderá testar com o Analisador de Conectividade da Microsoft, conforme descrito abaixo.

Os metadados do Microsoft Entra podem ser baixados deste URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Para clientes na China que usam a instância específica da China do Microsoft 365, o seguinte ponto de extremidade de federação deve ser usado: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Requisitos do protocolo SAML

Esta seção detalha como os pares de mensagens de solicitação e resposta são montados para ajudá-lo a formatar suas mensagens corretamente.

O Microsoft Entra ID pode ser configurado para trabalhar com provedores de identidade que usam o perfil SAML 2.0 SP Lite com alguns requisitos específicos, conforme listado abaixo. Usando as mensagens de solicitação e resposta SAML de exemplo, juntamente com testes automatizados e manuais, você pode trabalhar para obter interoperabilidade com o Microsoft Entra ID.

Requisitos de bloco de assinatura

Na mensagem de resposta SAML, o nó Assinatura contém informações sobre a assinatura digital da própria mensagem. O bloco de assinatura tem os seguintes requisitos:

1. O próprio nó de asserção deve ser assinado
2. O algoritmo RSA-sha1 deve ser usado como DigestMethod. Outros algoritmos de assinatura digital não são aceitos. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
3. Você também pode assinar o documento XML.
4. O algoritmo de transformação deve corresponder aos valores no exemplo a seguir: <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
5. O algoritmo SignatureMethod deve corresponder ao seguinte exemplo: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Ligações suportadas

As ligações são os parâmetros de comunicação relacionados ao transporte que são necessários. Os seguintes requisitos aplicam-se às vinculações:

1. HTTPS é o transporte necessário.
2. O Microsoft Entra ID requer HTTP POST para envio de token durante o login.
3. O Microsoft Entra ID usa HTTP POST para a solicitação de autenticação para o provedor de identidade e REDIRECT para a mensagem de saída para o provedor de identidade.

Atributos obrigatórios

Esta tabela mostra os requisitos para atributos específicos na mensagem SAML 2.0.

Exemplos de mensagens de solicitação e resposta SAML

Um par de mensagens de solicitação e resposta é mostrado para a troca de mensagens de logon. A seguir está uma mensagem de solicitação de exemplo que é enviada do Microsoft Entra ID para um provedor de identidade SAML 2.0 de exemplo. O provedor de identidade SAML 2.0 de exemplo é os Serviços de Federação do Ative Directory (AD FS) configurados para usar o protocolo SAML-P. Os testes de interoperabilidade também foram concluídos com outros provedores de identidade SAML 2.0.

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Se isSignedAuthenticationRequestRequired estiver habilitado conforme explicado em internaldomainfederation-update, a solicitação será semelhante a este exemplo:

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

A seguir está uma mensagem de resposta de exemplo que é enviada do provedor de identidade compatível com SAML 2.0 de exemplo para o Microsoft Entra ID / Microsoft 365.

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

Configure seu provedor de identidade compatível com SAML 2.0

Esta seção contém diretrizes sobre como configurar seu provedor de identidade SAML 2.0 para federar com o Microsoft Entra ID para habilitar o acesso de logon único a um ou mais serviços de nuvem da Microsoft (como o Microsoft 365) usando o protocolo SAML 2.0. A terceira parte confiável SAML 2.0 para um serviço de nuvem da Microsoft usado neste cenário é o Microsoft Entra ID.

Adicionar metadados do Microsoft Entra

Seu provedor de identidade SAML 2.0 precisa aderir às informações sobre a terceira parte confiável do Microsoft Entra ID. O Microsoft Entra ID publica metadados em https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

É recomendável que você sempre importe os metadados mais recentes do Microsoft Entra ao configurar seu provedor de identidade SAML 2.0.

Adicionar ID do Microsoft Entra como uma terceira parte confiável

Você deve habilitar a comunicação entre seu provedor de identidade SAML 2.0 e o Microsoft Entra ID. Essa configuração depende do seu provedor de identidade específico e você deve consultar a documentação para isso. Normalmente, você definiria o ID da terceira parte confiável como o mesmo que o entityID dos metadados do Microsoft Entra.

Instalar o PowerShell para logon com o provedor de identidade SAML 2.0

Depois de configurar seu provedor de identidade SAML 2.0 para uso com o logon do Microsoft Entra, a próxima etapa é baixar e instalar o módulo do Microsoft Graph PowerShell . Uma vez instalados, você usará esses cmdlets para configurar seus domínios do Microsoft Entra como domínios federados.

O módulo Microsoft Graph PowerShell é um download para gerenciar os dados de suas organizações no Microsoft Entra ID. Este módulo instala um conjunto de cmdlets no PowerShell; você executa esses cmdlets para configurar o acesso de logon único à ID do Microsoft Entra e, por sua vez, a todos os serviços de nuvem nos quais você está inscrito. Para obter instruções sobre como baixar e instalar os cmdlets, consulte Instalar o SDK do Microsoft Graph PowerShell.

Configurar uma relação de confiança entre seu provedor de identidade SAML e a ID do Microsoft Entra

Antes de configurar a federação em um domínio do Microsoft Entra, ele deve ter um domínio personalizado configurado. Não é possível federar o domínio padrão fornecido pela Microsoft. O domínio padrão da Microsoft termina com onmicrosoft.com. Você executará uma série de cmdlets do PowerShell para adicionar ou converter domínios para logon único.

Cada domínio do Microsoft Entra que você deseja federar usando seu provedor de identidade SAML 2.0 deve ser adicionado como um domínio de logon único ou convertido para ser um domínio de logon único de um domínio padrão. Adicionar ou converter um domínio configura uma relação de confiança entre seu provedor de identidade SAML 2.0 e o ID do Microsoft Entra.

O procedimento a seguir orienta você na conversão de um domínio padrão existente em um domínio federado usando o SAML 2.0 SP-Lite.

Configurando um domínio no diretório do Microsoft Entra para federação

1. Conecte-se ao seu diretório do Microsoft Entra como administrador de locatário:

   Connect-MgGraph -Scopes "Domain.ReadWrite.All"
   

2. Configure o domínio desejado do Microsoft 365 para usar a federação com SAML 2.0:

   $Domain = "contoso.com"  
   $LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
   $LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
   $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
   $MyUri = "urn:uri:MySamlp2IDP"
   $idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
   $MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
   $Protocol = "saml"
   
   New-MgDomainFederationConfiguration `
     -DomainId $Domain `
     -ActiveSignInUri $ecpUrl `
     -IssuerUri $MyUri `
     -PassiveSignInUri $LogOnUrl `
     -PreferredAuthenticationProtocol $Protocol `
     -SignOutUri $LogOffUrl `
     -SigningCertificate $MySigningCert
   

3. Você pode obter a cadeia de caracteres codificada base64 do certificado de assinatura do seu arquivo de metadados IDP. Um exemplo desse local é fornecido abaixo, mas pode diferir ligeiramente com base na sua implementação.

   <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
     <KeyDescriptor use="signing">
       <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
         </X509Data>
       </KeyInfo>
     </KeyDescriptor>
   </IDPSSODescriptor>
   

Para obter mais informações, consulte New-MgDomainFederationConfiguration.

Depois que a federação estiver configurada, você poderá voltar para "não federado" (ou "gerenciado"), no entanto, essa alteração leva até duas horas para ser concluída e requer a atribuição de novas senhas aleatórias para entrada baseada em nuvem para cada usuário. Voltar para "gerenciado" pode ser necessário em alguns cenários para redefinir um erro em suas configurações. Para obter mais informações sobre conversão de domínio, consulte Remove-MgDomainFederationConfiguration.

Provisionar entidades de usuário para o Microsoft Entra ID / Microsoft 365

Antes de autenticar seus usuários no Microsoft 365, você deve provisionar o Microsoft Entra ID com entidades de usuário que correspondam à afirmação na declaração SAML 2.0. Se essas entidades de usuário não forem conhecidas pela ID do Microsoft Entra com antecedência, elas não poderão ser usadas para entrada federada. O Microsoft Entra Connect ou o PowerShell podem ser usados para provisionar entidades de usuário.

O Microsoft Entra Connect pode ser usado para provisionar entidades de segurança para seus domínios no diretório do Microsoft Entra a partir do Ative Directory local. Para obter informações mais detalhadas, consulte Integrar seus diretórios locais com o Microsoft Entra ID.

O PowerShell também pode ser usado para automatizar a adição de novos usuários ao Microsoft Entra ID e sincronizar alterações do diretório local. Para usar os cmdlets do PowerShell, você deve baixar o módulo do Microsoft Graph PowerShell .

Este procedimento mostra como adicionar um único usuário ao Microsoft Entra ID.

1. Conecte-se ao seu diretório do Microsoft Entra como administrador de locatário usando o Connect-MgGraph.

2. Crie uma nova entidade de usuário:

   $Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
   $PasswordProfile = @{ Password = "$Password" }
   
   New-MgUser `
     -UserPrincipalName "elwoodf1@contoso.com" `
     -DisplayName "Elwood Folk" `
     -GivenName "Elwood" `
     -Surname "Folk" `
     -AccountEnabled `
     -MailNickName 'ElwoodFolk' `
     -OnPremisesImmutableId ABCDEFG1234567890 `
     -OtherMails "Elwood.Folk@contoso.com" `
     -PasswordProfile $PasswordProfile `
     -UsageLocation "US"
   

Para obter mais informações, consulte New-MgUser.

Verificar o logon único com seu IDP SAML 2.0

Como administrador, antes de verificar e gerenciar o logon único (também chamado de federação de identidades), revise as informações e execute as etapas nos seguintes artigos para configurar o logon único com seu provedor de identidade baseado no SAML 2.0 SP-Lite:

1. Você analisou os requisitos do protocolo Microsoft Entra SAML 2.0
2. Você configurou seu provedor de identidade SAML 2.0
3. Instalar o PowerShell para logon único (SSO) com o provedor de identidade SAML 2.0
4. Configurar uma relação de confiança entre o provedor de identidade SAML 2.0 e a ID do Microsoft Entra
5. Provisionado um usuário de teste conhecido para o Microsoft Entra ID (Microsoft 365) por meio do PowerShell ou do Microsoft Entra Connect.
6. Configure a sincronização de diretórios usando o Microsoft Entra Connect.

Depois de configurar o SSO com seu provedor de identidade baseado em SAML 2.0 SP-Lite, você deve verificar se ele está funcionando corretamente. Para obter mais informações sobre como testar o SSO baseado em SAML, consulte Testar logon único baseado em SAML.

Verifique manualmente se o logon único foi configurado corretamente

A verificação manual fornece mais etapas que você pode executar para garantir que seu provedor de identidade SAML 2.0 esteja funcionando corretamente em muitos cenários. Para verificar se o logon único está configurado corretamente, conclua as seguintes etapas:

1. Num computador associado a um domínio, inicie sessão no seu serviço na nuvem utilizando o mesmo nome de início de sessão que utiliza para as suas credenciais empresariais.
2. Selecione dentro da caixa de senha. Se o logon único estiver configurado, a caixa de senha será sombreada e você verá a seguinte mensagem: "Agora você precisa entrar na <sua empresa>".
3. Selecione o link Entrar na <sua empresa> . Se conseguir iniciar sessão, o início de sessão único está configurado.

Passos Seguintes

• Gerenciamento e personalização dos Serviços de Federação do Ative Directory com o Microsoft Entra Connect
• Lista de compatibilidade de federação do Microsoft Entra
• Instalação personalizada do Microsoft Entra Connect