Partilhar via

Configure Shibboleth para uso com um único sinal

  • Artigo

Atualizado: 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 Shibboleth Identity Provider para federar com Azure AD para permitir o acesso único a um ou mais serviços de nuvem da Microsoft (por exemplo, Microsoft Intune e/ou Office 365) utilizando o protocolo SAML 2.0. O partido de confiação SAML 2.0 para um serviço de cloud da Microsoft utilizado neste cenário é Azure AD.

Importante

Apenas um conjunto limitado de clientes são suportados neste único cenário de inscrição, da seguinte forma:

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

  • Clientes ricos em e-mail que utilizam a autenticação básica e um método de acesso Exchange suportado, tais como IMAP, POP, Ative Sync, MAPI, etc. (o ponto final do protocolo de cliente melhorado é necessário para ser implementado), incluindo:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 e 9

    • O iPhone (várias versões iOS)

    • Windows Phone 7

Todos os outros clientes não são apoiados neste único cenário de login com o Shibboleth Identity Provider.  Por exemplo, o cliente de desktop Lync 2010 não é suportado para iniciar sessão no serviço com o Shibboleth Identity Provider configurado para um único login.

Importante

Antes de completar qualquer um dos passos deste tópico para configurar o Shibboleth Identity Provider para um único sinal, deve rever e seguir as instruções fornecidas em Prepare-se para um único sinal.

Para obter informações gerais sobre um único sinal, consulte o roteiro de inscrição única.

Para configurar o Shibboleth Identity Provider para utilização com um único sinal, complete os seguintes passos:

  1. Adicionar metadados Azure AD

  2. Adicione Azure AD como uma festa de confiação

  3. Configure o atributo Shibboleth resolver

  4. Configure o filtro de atributos Shibboleth

  5. Opcional: Instalar a extensão Shibboleth ECP

  6. Reinicie Shibboleth e verifique a funcionalidade

Importante

Nos exemplos ao longo deste tópico, IDP_HOME é o diretório base onde instalou o Shibboleth Identity Provider, por exemplo, c:\shibboleth2idp. Ao seguir as instruções deste tópico para configurar Shibboleth, certifique-se de que substitui IDP_HOME pelo seu caminho específico.

Adicionar metadados Azure AD

Shibboleth Identity Provider precisa de informações sobre o Azure AD parte. Azure AD publica metadados em https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Recomenda-se que verifique sempre os metadados Azure AD mais recentes. Aqui está o valor atual dos 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 Azure AD ao Fornecedor de Identidade Shibboleth, pode utilizar o método The Filesystem Metadata Provider – pode descarregar e armazenar manualmente metadados Azure AD num ficheiro na pasta IDP_HOME/metadados.

Importante

Nos exemplos ao longo deste tópico, IDP_HOME é o diretório base onde instalou o Shibboleth Identity Provider, por exemplo, c:\shibboleth2idp. Ao seguir as instruções deste tópico para configurar Shibboleth, certifique-se de que substitui IDP_HOME pelo seu caminho específico.

Adicione Azure AD como uma festa de confiação

Tem de ativar a comunicação entre o Shibboleth Identity Provider e o Azure AD definindo um novo elemento RelyingParty no ficheiro IDP_Home/conf/relying-party.xml. Azure AD requer alterações nas definições de saml padrão:SAML2Profile no elemento DefaultRelyingParty.

Insira o seguinte texto após o elemento DefaultRelyingParty e certifique-se de que o valor do id DaD Desemagurado corresponde ao valor de entityID especificado nos metadados Add Azure AD, por exemplo, "urna:federação:MicrosoftOnline". Além disso, certifique-se de que o valor do seu fornecedor corresponde à EntityID do seu Fornecedor de Identidade Shibboleth especificado no elemento DefaultRelyingParty , como mostrado 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>

Também deve especificar ao Fornecedor de Identidade Shibboleth onde encontrar o ficheiro que contém os metadados Azure AD, por exemplo, IDP_HOME/metadados/windows-azure-ad-metadata.xml. Pode fazê-lo adicionando uma entrada no ficheiro IDP_Home/conf/relying-party.xml no nó MetadataProvider , como mostrado no seguinte exemplo:

<!—- 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"/>

Configure o atributo Shibboleth resolver

Azure AD requer dois dados do Shibboleth Identity Provider para localizar a conta sombra na plataforma de autenticação. Para informar a Shibboleth destes requisitos, adicione as seguintes entradas no ficheiro IDP_HOME/conf/attribute-resolver.xml:

  • Imutável Azure AD

    Azure AD requer que selecione um identificador único para cada utilizador no seu diretório de utilizador. Também deve configurar Shibboleth para enviar este atributo em cada login federado para Azure AD na afirmação DOM 2.0 NameID. Este identificador não deve ser alterado para este utilizador ao longo da vida útil do utilizador que se encontre no seu sistema. O Serviço Azure AD chama a este atributo o "ImuttableID". O valor para o identificador único não deve conter informações de domínio e é sensível a casos.

    Por exemplo, não utilize user@contoso.com. No código recomendado abaixo, o valor utilizado será a propriedade Ative Directory objectGUID que está codificada com base64. Ao criar contas, deve garantir que o ImuttableID é processado da mesma forma ou o utilizador não poderá iniciar scontabilidade no serviço de cloud da Microsoft. A ferramenta sync Microsoft Azure Ative Directory utiliza automaticamente o objeto Ative DirectoryGUID para o valor ImmutableID e processa o ImuttableID da mesma forma que no exemplo recomendado:

    <!-- 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

    Atualize o Conector de Dados LDAP em attribute-resolver.xml para especificar o objectGUID como binário.

    Certifique-se de que adiciona esta linha à entrada do Conector de Dados LDAP, isto garantirá que o objectGUID é manuseado corretamente e está codificado com base64.

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

  • ID do utilizador Azure AD

    Azure AD requer que o ID do utilizador Azure AD, por exemplo, joe@contoso.comseja enviado usando a entrada personalizada como descrito no exemplo abaixo. Neste exemplo, o valor é armazenado no atributo Nome De Nome Do Utilizador 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>

Configure o filtro de atributos Shibboleth

O Fornecedor de Identidade Shibboleth deve ser configurado para libertar os atributos necessários à Azure AD. Adicione o seguinte texto ao ficheiro IDP_HOME/conf/attribute-filter.xml para libertar os atributos à Azure AD.

As definições que são mostradas aqui libertam os atributos necessários apenas aos serviços Azure AD e Windows Live. As definições utilizam IDs de Política de Atributos específicos para indicar que os atributos são exigidos por Azure AD.

<!-- 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 Shibboleth ECP

Embora opcional, este é um passo recomendado. Se estiver a utilizar o Shibboleth como SEU STS, certifique-se de instalar a extensão ECP do Fornecedor de Identidade Shibboleth para que um único login funcione com um telefone inteligente, Microsoft Outlook ou outros clientes.

A extensão melhorada do cliente/proxy (ECP) está incluída no Shibboleth 2.3.3 e posteriormente. Para a versão anterior do Shibboleth 2.x, pode descarregar e instalar a extensão ECP. Para obter mais informações, consulte: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

A extensão ECP do Fornecedor de Identidade Shibboleth permite-lhe permitir a integração de aplicações de e-mail de desktop com Azure AD. Esta extensão implementa a especificação SAML 2.0 ECP. Ao configurar um único sinal com Azure AD, pode especificar o URL para a extensão ECP, por exemplo, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. A autenticação da extensão Shibboleth ECP está atualmente limitada à autenticação básica.

Complete os seguintes passos se optar por instalar a extensão Shibboleth ECP:

  1. Adicione o seguinte código ao seu ficheiro de metadados Azure AD local localizado no IDP_HOME/metadados:

    <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 Azure AD RelyingParty em relying-party.xml localizado em 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>

Reinicie Shibboleth e verifique a funcionalidade

Pare e inicie o Apache Tomcat para reiniciar o Shibboleth Identity Provider e certifique-se de que os ficheiros XML atualizados estão carregados. Shibboleth pode não começar se houver um problema com um ou mais dos ficheiros de configuração. Verifique os ficheiros de registo de Shibboleth após o reinício para garantir que não são reportados erros. Recomendamos também que tente iniciar sposição e aceder a um prestador de serviços Shibboleth previamente configurado na sua rede.

Nota

Verifique se o relógio do seu servidor Shibboleth está sincronizado com uma fonte de tempo precisa. Um tempo de relógio impreciso pode fazer com que os logins federados falhem.

Consulte também

Conceitos

Use o Fornecedor de Identidade Shibboleth para implementar um único sinal de saúde