Configurar Shibboleth para usarlo con el inicio de sesión único

Actualizado: 25 de junio de 2015

Se aplica a: Azure, Office 365, Power BI, Windows Intune

Este tema contiene instrucciones detalladas sobre cómo configurar el proveedor de identidades de Shibboleth para federarse con Azure AD para habilitar el acceso de inicio de sesión único a uno o varios servicios en la nube de Microsoft (por ejemplo, Microsoft Intune o Office 365) mediante el protocolo SAML 2.0. El usuario de confianza de SAML 2.0 que se usa en este escenario para un servicio en la nube de Microsoft es Azure AD.

Para configurar el proveedor de identidad Shibboleth para usarlo con el inicio de sesión único, siga estos pasos:

1. Adición de metadatos de Azure AD

2. Adición de Azure AD como usuario de confianza

3. Configurar el resolvedor de atributos Shibboleth

4. Configurar el filtro de atributos de Shibboleth

5. Opcional: Instalar la extensión ECP de Shibboleth

6. Reiniciar Shibboleth y comprobar la funcionalidad

Adición de metadatos de Azure AD

El proveedor de identidad Shibboleth necesita información sobre el usuario de confianza de Azure AD. Azure AD publica los metadatos en https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Se recomienda que compruebe siempre los metadatos más recientes de Azure AD. A continuación se indica el valor actual de los metadatos:

<?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 agregar los metadatos de Azure AD al proveedor de identidad Shibboleth, puede usar el método El proveedor de metadatos Filesystem: puede descargar y almacenar metadatos manualmente en Azure AD en un archivo de la carpeta IDP_HOME/metadata.

Adición de Azure AD como usuario de confianza

Debe habilitar la comunicación entre el proveedor de identidad Shibboleth y Azure AD definiendo un nuevo elemento RelyingParty en el archivo IDP_Home/conf/relying-party.xml. Azure AD necesita cambios en la configuración predeterminada saml:SAML2Profile del elemento DefaultRelyingParty.

Inserte el texto siguiente después del elemento DefaultRelyingParty y asegúrese de que el valor id de RelyingParty coincide con el valor entityID especificado en Agregar metadatos de Azure AD, por ejemplo, "urn:federation:MicrosoftOnline". Además, asegúrese de que el valor provider coincide con el valor EntityID del proveedor de identidad Shibboleth especificado en el elemento DefaultRelyingParty tal y como se muestra en el ejemplo siguiente:

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

También debe especificar al proveedor de identidad Shibboleth dónde encontrar el archivo que contiene los metadatos de Azure AD, por ejemplo, IDP_HOME/metadata/windows-azure-ad-metadata.xml. Puede hacerlo agregando una entrada al archivo IDP_Home/conf/relying-party.xml en el nodo MetadataProvider tal y como se muestra en el ejemplo siguiente:

<!—- 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 el resolvedor de atributos Shibboleth

Azure AD necesita dos elementos de datos del proveedor de identidad Shibboleth para localizar la cuenta sombra en la plataforma de autenticación. Para informar a Shibboleth de estos requisitos, agregue las siguientes entradas al archivo IDP_HOME/conf/attribute-resolver.xml:

• Azure AD ImmutableID

  Azure AD necesita que seleccione un identificador único para cada usuario en el directorio de usuarios. También debe configurar Shibboleth para enviar este atributo en cada inicio de sesión federado a Azure AD en la aserción NameID de SAML 2.0. Este identificador no puede cambiar para este usuario durante el periodo de vida del usuario en el sistema. El Servicio de Azure AD llama a este atributo “ImmutableID”. El valor del identificador único no puede contener información de dominio y distingue entre mayúsculas y minúsculas.

  Por ejemplo, no use user@contoso.com. En el código recomendado siguiente, el valor usado será la propiedad objectGUID de Active Directory codificada en base64. Al crear cuentas, debe asegurarse de que ImmutableID se procesa de la misma manera; si no, el usuario no podrá iniciar sesión en el servicio en la nube de Microsoft. La herramienta de sincronización de Microsoft Azure Active Directory usa automáticamente el objectGUID de Active Directory para el valor immutableID y procesa immutableID de la misma manera que en el ejemplo recomendado siguiente:

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

  Actualice el conector de datos LDAP en attribute-resolver.xml para especificar objectGUID como binario.

  Asegúrese de agregar esta línea a la entrada del conector de datos LDAP; de este modo, se asegurará de que objectGUID se controla correctamente y tiene codificación en base 64.

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

  Por ejemplo:

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

• Identificador de usuario de Azure AD

  Azure AD requiere que el identificador de usuario de Azure AD, por ejemplo, , joe@contoso.comse envíe mediante la entrada personalizada, como se describe en el ejemplo siguiente. En este ejemplo, el valor se almacena en el atributo userPrincipalName de 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 el filtro de atributos de Shibboleth

El proveedor de identidad Shibboleth debe configurarse para liberar los atributos necesarios en Azure AD. Agregue el texto siguiente al archivo IDP_HOME/conf/attribute-filter.xml para liberar los atributos en Azure AD.

La configuración que se muestra aquí libera los atributos necesarios solo en Azure AD y en los servicios de Windows Live. La configuración usa identificadores de AttributeFilterPolicy específicos para indicar que Azure AD necesita los atributos.

<!-- 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 la extensión ECP de Shibboleth

Aunque opcional, este paso es recomendado. Si utilizas Shibboleth como STS, asegúrate de instalar la extensión ECP de Shibboleth Identity Provider para que el inicio de sesión único funcione con un smartphone, Microsoft Outlook u otros clientes.

La extensión cliente/proxy (ECP) mejorada se incluye en Shibboleth 2.3.3 y en versiones posteriores. Para la versión anterior de Shibboleth 2.x, puede descargar e instalar la extensión ECP. Para obtener más información, consulte: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

La extensión ECP del proveedor de identidad Shibboleth permite habilitar la integración de aplicaciones de correo electrónico de escritorio con Azure AD. La extensión implementa la especificación ECP de SAML 2.0. Al configurar el inicio de sesión único con Azure AD, puede especificar la URL de la extensión ECP, por ejemplo, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. La autenticación de la extensión ECP de Shibboleth se limita actualmente a la autenticación básica.

Complete los pasos siguientes si elige instalar la extensión ECP de Shibboleth:

1. Agregue el código siguiente al archivo de metadatos de su Azure AD local en IDP_HOME/metadata:

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

2. Agregue la entrada "saml:SAML2ECPProfile" en el nodo de configuración RelyingParty de Azure AD en relying-party.xml ubicado en 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 Shibboleth y comprobar la funcionalidad

Detenga e inicie Apache Tomcat para reiniciar el proveedor de identidad Shibboleth y asegurarse de que se han cargado los archivos XML actualizados. Se puede producir un error en el inicio de Shibboleth si hay un problema con uno o más archivos de configuración. Compruebe los archivos de registro de Shibboleth después del reinicio para asegurarse de que no se notifican errores. También recomendamos que intente iniciar sesión y acceder al proveedor de servicios de Shibboleth configurado previamente en la red.

Consulte también

Conceptos

Utilizar Shibboleth Identity Provider para implementar el inicio de sesión único