Configurar o Shibboleth para utilizar com o single sign-on

  • Artigo

Publicada: Junho de 2012

Atualizada: Fevereiro de 2013

Aplica-se a: Office 365, Windows Azure Active Directory, Windows Intune

Nota

Este tópico fornece conteúdo de ajuda online que é aplicável a vários serviços baseados na nuvem Microsoft, incluindo o Windows Intune e o Office 365.

Este tópico contém instruções detalhadas sobre como configurar o Fornecedor de Identidade do Shibboleth para federar com o Windows Azure AD, de modo a permitir o acesso single sign-on a um ou mais serviços baseados na nuvem Microsoft (por exemplo, Windows Intune e/ou Office 365) com o protocolo SAML 2.0. Neste cenário, o Windows Azure AD é a entidade confiadora do SAML 2.0 que se utiliza para um serviço baseado na nuvem Microsoft.

Importante

Neste cenário de single sign-on só é suportado um conjunto limitado de clientes:

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

  • Clientes de correio eletrónico avançado que usam autenticação básica e um método Exchange tal como IMAP, POP, Active Sync, MAPI, etc. (é necessário implementar o ponto de fim de protocolo de cliente avançado), incluindo:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 e 9

    • O iPhone (versões diferentes do iOS)

    • Windows Phone 7

Todos os outros clientes não são suportados neste cenário de single sign-on com o Fornecedor de Identidade do Shibboleth. Por exemplo, o cliente de ambiente de trabalho Lync 2010 não é suportado para iniciar sessão no serviço com o Fornecedor de Identidade do Shibboleth configurado para single sign-on.

Importante

Antes de completar qualquer um dos passos descritos neste tópico para configurar o Fornecedor de Identidade do Shibboleth para single sign-on, tem de rever e seguir as instruções fornecidas em Preparar o single sign-on.

Para obter informações gerais sobre o single sign-on, consulte Plano do single sign-on.

Para configurar o Fornecedor de Identidade do Shibboleth para utilização com o single sign-on, complete os seguintes passos:

  1. Adicionar metadados do Windows Azure AD

  2. Adicionar o Windows Azure AD como entidade confiadora

  3. Configurar a resolução de atributos do Shibboleth

  4. Configurar o filtro de atributos do Shibboleth

  5. Opcional: Instalar a Extensão de ECP do Shibboleth

  6. Reiniciar o Shibboleth e verificar a funcionalidade

Importante

Nos exemplos dados ao longo deste tópico, IDP_HOME é o diretório base onde instalou o Fornecedor de Identidade do Shibboleth como, por exemplo, c:\shibboleth2idp. À medida que seguir as instruções neste tópico para configurar o Shibboleth, certifique-se de que substitui IDP_HOME pelo caminho específico.

Adicionar metadados do Windows Azure AD

O Fornecedor de Identidade do Shibboleth necessita de informações sobre a entidade confiadora Windows Azure AD. O Windows Azure AD publica metadados em https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Recomenda-se que procure sempre os metadados mais recentes do Windows Azure AD. Segue-se 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 do Windows Azure AD ao Fornecedor de Identidade do Shibboleth, pode utilizar o método Fornecedor de Metadados Filesystem – pode transferir e armazenar manualmente os metadados do Windows Azure AD num ficheiro dentro da pasta IDP_HOME/metadata.

Importante

Nos exemplos dados ao longo deste tópico, IDP_HOME é o diretório base onde instalou o Fornecedor de Identidade do Shibboleth como, por exemplo, c:\shibboleth2idp. À medida que seguir as instruções neste tópico para configurar o Shibboleth, certifique-se de que substitui IDP_HOME pelo caminho específico.

Adicionar o Windows Azure AD como entidade confiadora

Tem de permitir a comunicação entre o Fornecedor de Identidade do Shibboleth e o Windows Azure AD definindo um novo elemento RelyingParty no ficheiro IDP_Home/conf/relying-party.xml. O Windows Azure AD requer alterações às predefinições de saml:SAML2Profile no elemento DefaultRelyingParty.

Insira o seguinte texto após o elemento DefaultRelyingParty e certifique-se de que o valor RelyingParty id corresponde ao valor entityID que especificou em Adicionar metadados do Windows Azure AD como, por exemplo, "urn:federation:MicrosoftOnline". Além disso, certifique-se de que o valor fornecedor corresponde ao EntityID do Fornecedor de Identidade do Shibboleth especificado no elemento DefaultRelyingParty, como se mostra no exemplo seguinte:

<!-- Windows 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 tem de especificar para o Fornecedor de Identidade do Shibboleth a localização do ficheiro que contém os metadados do Windows Azure AD como, por exemplo, IDP_HOME/metadata/wlid-metadata.xml. Para tal, adicione uma entrada ao ficheiro IDP_Home/conf/relying-party.xml no nó MetadataProvider, como se mostra no exemplo seguinte:

<!—- Windows 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 a resolução de atributos do Shibboleth

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

  • ImmutableID do Windows Azure AD

    O Windows Azure AD requer a seleção de um identificador exclusivo para cada utilizador no diretório de utilizadores. Também tem de configurar o Shibboleth para enviar este atributo em cada início de sessão federado no Windows Azure AD na asserção NameID de SAML 2.0. Este identificador não deve ser alterado para este utilizador enquanto este permanecer no sistema. O Serviço do Windows Azure AD designa este atributo por “ImmutableID”. O valor do identificador exclusivo não deve conter informações de domínio e é sensível a maiúsculas e minúsculas.

    Por exemplo, não use utilizador@contoso.com. No código recomendado abaixo, o valor utilizado será a propriedade de objectGUID do Active Directory que está codificada em base64. Quando criar contas, tem de certificar-se de que o ImmutableID é processado da mesma forma ou o utilizador não conseguirá iniciar sessão no serviço baseado na nuvem Microsoft. A ferramenta de Sincronização de Diretórios do Microsoft Online Services utiliza automaticamente o objectGUID do Active Directory para o valor do ImmutableID e processa o ImmutableID da mesma forma do que no seguinte 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; deste modo, o objectGUID é processado corretamente e codificado em 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 do Windows Azure AD

    O Windows Azure AD requer que o ID do Utilizador do Windows Azure AD como, por exemplo, luis@contoso.com, seja enviado utilizando a entrada personalizada, conforme descrito no exemplo abaixo. Neste exemplo, o valor é armazenado no atributo LDAP userPrincipalName.

    <!-- UserPrincipalName for Windows 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 do Shibboleth

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

As definições que são mostradas aqui libertam os atributos necessários apenas para os serviços do Windows Azure AD e do Windows Live. As definições utilizam ID específicos de AttributeFilterPolicy para indicar que os atributos são necessários para o Windows Azure AD.

<!-- Release userPrincipalName as Windows Azure AD User ID -->
<afp:AttributeFilterPolicy id="UserId">
   <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

</afp:AttributeFilterPolicy>


<!-- Release Immutable ID to Windows Azure AD -->
<afp:AttributeFilterPolicy id="ImmutableID">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

 </afp:AttributeFilterPolicy>

Opcional: Instalar a Extensão de ECP do Shibboleth

Embora opcional, este é um passo recomendado. Se utilizar o Shibboleth como o STS, certifique-se de que instala a extensão de ECP do Fornecedor de Identidade do Shibboleth para que o single sign-on funcione com um smartphone, com o Microsoft Outlook ou com outros clientes.

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

A extensão de ECP do Fornecedor de Identidade do Shibboleth permite ativar a integração de aplicações de correio eletrónico de ambiente de trabalho com o Windows Azure AD. Esta extensão implementa a especificação de ECP SAML 2.0. Ao configurar o single sign-on com o Windows Azure AD, pode especificar o URL para a extensão de ECP como, por exemplo, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. A autenticação da extensão de ECP do Shibboleth está atualmente limitada à autenticação básica.

Reiniciar o Shibboleth e verificar a funcionalidade

Pare e inicie o Apache Tomcat para reiniciar o Fornecedor de Identidade do Shibboleth e certifique-se de que os ficheiros XML atualizados são carregados. O Shibboleth pode não conseguir iniciar se existir um problema com um ou mais dos ficheiros de configuração. Verifique os ficheiros de registo do Shibboleth após o reinício para se certificar de que não existem erros. Recomendamos também que tente iniciar sessão e aceder a um fornecedor de serviços do Shibboleth previamente configurado na rede.

Nota

Verifique se o relógio no servidor do Shibboleth está sincronizado com uma origem de hora exata. Uma hora incorreta pode provocar a falha de inícios de sessão federados.

Ver Também

Conceitos

Utilizar o Fornecedor de Identidade do Shibboleth para implementar o single sign-on