Configure o Shibboleth para usá-lo com o logon único

  • Artigo

Atualizado em: 25 de junho de 2015

Aplica-se a: Azure, Office 365, Power BI Windows Intune

Este tópico contém instruções detalhadas sobre como configurar o Provedor de Identidade shibboleth para federar com Azure AD para habilitar o acesso de logon único a um ou mais serviços de nuvem da Microsoft (por exemplo, Microsoft Intune e/ou Office 365) usando o protocolo SAML 2.0. A terceira parte confiável SAML 2.0 para o serviço de nuvem da Microsoft neste cenário é o Azure AD.

Importante

Somente um conjunto limitado de clientes é suportado neste cenário de logon único, como segue:

  • Clientes baseados na Web, como o Exchange Web Access e o SharePoint Online

  • Clientes de email avançados que usam autenticação básica e um método de acesso do Exchange compatível tal como IMAP, POP, Active Sync, MAPI etc. (é necessário implantar o ponto de extremidade do Protocolo Aprimorado do Cliente), incluindo:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 e 9

    • iPhone (várias versões iOS)

    • Windows Phone 7

Todos os outros clientes não têm suporte neste cenário de logon único com o Provedor de Identidade Shibboleth.  Por exemplo, o cliente da área de trabalho do Lync 2010 não tem suporte para fazer logon no serviço com o Provedor de Identidade Shibboleth configurado para logon único.

Importante

Antes de concluir qualquer uma das etapas deste tópico para configurar o Shibboleth Identity Provider para logon único, você deve examinar e seguir as instruções fornecidas em Preparar para logon único.

Para obter informações gerais sobre o logon único, consulte o roteiro de logon único.

Para configurar o Provedor de Identidade Shibboleth para o uso com logon único, complete as seguintes etapas:

  1. Adicionar metadados do Azure AD

  2. Adicionar o Azure AD como uma terceira parte confiável

  3. Configurar o resolvedor de atributos Shibboleth

  4. Configurar o filtro de atributos Shibboleth

  5. Opcional: instalar a extensão do Shibboleth ECP

  6. Reiniciar o Shibboleth e verificar a funcionalidade

Importante

Nos exemplos através deste tópico, o IDP_HOME é o diretório base onde você instalou o Provedor de Identidade Shibboleth, por exemplo, c:\shibboleth2idp. Enquanto você segue as instruções neste tópico para configurar o Shibboleth, certifique-se de substituir o IDP_HOME com seu caminho específico.

Adicionar metadados do Azure AD

O Provedor de Identidade Shibboleth necessita informações sobre a terceira parte confiante do AD do Azure. O Azure AD publica metadados em https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. É recordável que você sempre verifique os últimos metadados do AD do Azure. Aqui está o valor atual de metadados.

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:federation:MicrosoftOnline">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0" isDefault="true"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://login.microsoftonline.com/login.srf" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf" index="2" />
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    </NameIDFormat>
    <NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    </NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

Para adicionar os metadados do AD do Azure ao Provedor de Identidade Shibboleth, você pode usar o método O Provedor de Metadados do Filesystem - você pode baixar manualmente e armazenar os metadados do AD do Azure em um arquivo na pasta do IDP_HOME/metadados.

Importante

Nos exemplos através deste tópico, o IDP_HOME é o diretório base onde você instalou o Provedor de Identidade Shibboleth, por exemplo, c:\shibboleth2idp. Enquanto você segue as instruções neste tópico para configurar o Shibboleth, certifique-se de substituir o IDP_HOME com seu caminho específico.

Adicionar o Azure AD como uma terceira parte confiável

Você tem que habilitar a comunicação entre o Provedor de Identidade Shibboleth e o AD do Azure definindo um novo elemento RelyingParty no arquivo IDP_Home/conf/relying-party.xml. O AD do Azure necessita alterações nas configurações padrão do saml:SAML2Profile no elemento DefaultRelyingParty.

Insira o texto a seguir após o elemento DefaultRelyingParty e verifique se o valor da ID De RelyingParty corresponde ao valor entityID especificado em Adicionar metadados Azure AD, por exemplo, "urn:federation:MicrosoftOnline". Também, garanta-se que o valor do seuprovedor corresponde a EntityID do seu Provedor de Identidade Shibboleth especificado no elemento DefaultRelyingParty como se mostra no seguinte exemplo:

<!-- Azure AD -->
<rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.com/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
         
     <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
signAssertions="conditional"
encryptAssertions="never"
encryptNameIds="never" />
             
</rp:RelyingParty>

Você também deve especificar o Provedor de Identidade Shibboleth para encontrar o arquivo que contenha os metadados do AD do Azure, por exemplo, IDP_HOME/metadata/windows-azure-ad-metadata.xml. Você pode fazer isto adicionando uma entrada no arquivo IDP_Home/conf/relying-party.xml no nó MetadataProvider como se mostra no exempli a seguir:

<!—- Azure AD Metadata -->
<metadata:MetadataProvider id="OrgID" xsi:type="metadata:ResourceBackedMetadataProvider">
<metadata:MetadataResource xsi:type="resource:FilesystemResource" file="C:\opt\shibboleth-idp/metadata/WindowsAzureAD-metadata.xml"/>

Configurar o resolvedor de atributos Shibboleth

O AD de Azure requer duas partes de dados do Provedor de Identidade Shibboleth para localizar a conta sombra na plataforma de autenticação. Para informar a Shibboleth destes requisitos, adicione as seguintes entradas ao arquivo IDP_HOME/conf/attribute-resolver.xml:

  • ImmutableID do AD do Azure

    O AD de Azure necessita que você selecione um identificador para cada usuário no seu diretório de usuário. Você também deve configurar o Shibboleth para enviar este atributo em cada logo federado ao AD do Azure na declaração Name ID do SAML 2.0. Este identificador não deve ser alterado para este usuário no tempo de vida útil que seu usuário esteja no seu sistema. O Serviço de AD do Azure chama a este atributo de "ImmutableID". Este valor para o identificador único não deve conter as informações de domínio e é diferencia maiúsculas de minúsculas.

    Por exemplo, não use user@contoso.com. No código recomendado abaixo, o valor usado será a propriedade objectGUID do Active Directory que é codificada em base64. Ao criar contas, você deve verificar que o ImmutableID seja processado da mesma maneira ou o usuário não será capaz de se conectar no serviço de nuvem de Microsoft. A ferramenta Microsoft Azure Active Directory Sync usa automaticamente o objetoGUID do Active Directory para o valor ImmutableID e processa a ImmutableID da mesma maneira que no exemplo recomendado a seguir:

    <!-- Use AD objectGUID for ImmutableID -->
<resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
          sourceAttributeID="objectGUID">
   <resolver:Dependency ref="myLDAP" />

   <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
   nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
  </resolver:AttributeDefinition>

    Importante

    Atualizar o Conector de Dados do LDAP no attribute-resolver.xml para especificar o objectGUID como um binário.

    Certifique-se de adicionar esta linha na sua entrada de Conector de Dados do LDAP, isto garantirá que o objectGUID seja manipulado corretamente e seja codificado em base 64.

    <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

    Por exemplo:

    <!-- ========================================== -->
<!--      Data Connectors                       -->
<!-- ========================================== -->
<!-- Live@edu LDAP Connector -->
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                   ldapURL="ldap://MyADServer:389"
                   baseDN="CN=Users,DC=MyDomain,DC=ORG"
                   principal="CN=Administrator,CN=Users,DC=MyDomain,DC=ORG"
                   principalCredential="A.useful.p!w.d">
  <FilterTemplate>
    <![CDATA[
                (uid=$requestContext.principalName)
            ]]>
  </FilterTemplate>

  <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

</resolver:DataConnector>

  • Azure AD ID do usuário

    Azure AD requer que a ID do usuário Azure AD, por exemplo, joe@contoso.comseja enviada usando a entrada personalizada, conforme descrito no exemplo abaixo. Neste exemplo, o valor é armazenado no atributo userPrincipalName do LDAP.

    <!-- UserPrincipalName for Azure AD User ID -->
<resolver:AttributeDefinition id="UserId" xsi:type="ad:Simple" sourceAttributeID="userPrincipalName">
      <resolver:Dependency ref="myLDAP" />
      <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="IDPEmail" friendlyName="UserId" />
</resolver:AttributeDefinition>

Configurar o filtro de atributos Shibboleth

O Provedor de Identidade Shibboleth deve ser configurado para liberar os atributos requeridos ao AD do Azure. Adicione o seguinte texto ao arquivo IDP_HOME/conf/attribute-filter.xml para liberar os atributos ao AD do Azure.

As configurações que são mostradas aqui liberam os atributos requeridos apenas ao AD do Azure e aos serviços do Windows Live. As configurações usam as IDs AttributeFilterPolicy específicas para indicar se os atributos são requeridos pelo AD do Azure.

<!-- Attribute Filter Policy for Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />

<!-- Release userPrincipalName as Azure AD User ID -->
      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Release Immutable ID to Azure AD -->
      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Note: it is not recommended to send transientId to Azure AD -->
<afp:AttributeRule attributeID="transientId">
   <afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

Opcional: instalar a extensão do Shibboleth ECP

Mesmo sendo opcional, esta é uma etapa recomendada. Se você está usando o Shibboleth como seu STS, assegure-se de instalar a extensão ECP do Provedor de Identidade Shibboleth para que o logon único funcione com um smart phone, Microsoft Outlook ou outros clientes.

A extensão do cliente/proxy (ECP) aprimorada é incluída no Shibboleth 2.3.3 e posterior. Para versões recentes do Shibboleth 2.x você pode baixar e instalar a extensão do ECP. Para saber mais, confira https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

A extensão do ECP do Provedor de Identidade Shibboleth lhe permite habilitar a integração dos aplicativos de email da área de trabalho com o AD do Azure. Esta extensão implanta a especificação do ECP do SAML 2.0. Quando você configura o logon único com o AD do Azure, você pode especificar a URL para a extensão do ECP, por exemplo, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. A autenticação de extensão do ECP Shibboleth é atualmente limitada para autenticação básica.

Complete os passos a seguir se você escolhe instalar a extensão do ECP Shibboleth:

  1. Adicione o código a seguir para seu arquivo de metadados do AD do Azure localizado no IDP_HOME/metadata:

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>

  2. Adicione a entrada "saml:SAML2ECPProfile" ao nó de configuração RelyingParty do AD do Azure no relying-party.xml localizado no IDP_HOME/config:

    <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">  
                <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
                                signAssertions="conditional" 
                                encryptAssertions="never"                          
                                encryptNameIds="never" />                                                      
                <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile"                                                           
                                signAssertions="always"                  
                                encryptAssertions="never"                  
                                encryptNameIds="never"/>                                                             
</rp:RelyingParty>

Reiniciar o Shibboleth e verificar a funcionalidade

Parar e iniciar o Apache Tomcat para reiniciar o Provedor de Identidade Shibboleth e garantir que os arquivos XML atualizados sejam carregados. O Shibboleth pode falhar a iniciar se há um problema com um ou mais dos arquivos de configuração. Verifique os arquivos de log do Shibboleth para garantir que não se reportem erros. Também recomendamos que você tente se conectar e acessar um provedor de serviço de Shibboleth previamente configurado na sua rede.

Observação

Verifique que o relógio do seu servidor de Shibboleth esteja sincronizado com uma fonte de tempo precisa. Um relógio com horário impreciso pode fazer com que os logons federados falhem.

Consulte Também

Conceitos

Usar provedores de identidade Shibboleth para implementar o logon único