将 Shibboleth 配置为用于单一登录

更新时间：2015 年 6 月 25 日

适用于：Azure、Office 365、Power BI、Windows Intune

本主题包含有关如何将 Shibboleth 标识提供者配置为与 Azure AD 联合的详细说明，以启用对一个或多个 Microsoft 云服务的单一登录访问 (，例如，使用 SAML 2.0 协议Microsoft Intune和/或Office 365) 。 此方案中所使用的 Microsoft 云服务的 SAML 2.0 信赖方为 Azure AD。

重要

这种单一登录方案仅支持有限的一组客户端，如下所述：

• 基于 Web 的客户端（如 Exchange Web Access 和 SharePoint Online）
  
  
• 使用基本身份验证和受支持的 Exchange 访问方法（例如 IMAP、POP、Active Sync、MAPI 等）的电子邮件富客户端（需要部署增强型客户端协议终结点），包括：
  
  
  • Microsoft Outlook 2007
    
    
  • Microsoft Outlook 2010
    
    
  • Thunderbird 8 和 9
    
    
  • iPhone（各种 iOS 版本）
    
    
  • Windows 7 Phone
    
    

使用 Shibboleth 标识提供者的此单一登录方案不支持所有其他客户端。  例如，不支持 Lync 2010 桌面客户端使用配置为单一登录的 Shibboleth 标识提供者登录到服务。

重要

在完成本主题中的任何步骤以配置 Shibboleth 标识提供者进行单一登录之前，必须查看并按照 准备单一登录中提供的说明进行操作。

有关单一登录的一般信息，请参阅 单一登录路线图。

若要将 Shibboleth 标识提供程序配置为用于单一登录，请完成以下步骤：

1. 添加 Azure AD 元数据

2. 将 Azure AD 作为信赖方添加

3. 配置 Shibboleth 属性解析程序

4. 配置 Shibboleth 属性筛选器

5. 可选：安装 Shibboleth ECP 扩展

6. 重新启动 Shibboleth 并验证功能

重要

在本主题的所有示例中，IDP_HOME 是安装 Shibboleth 标识提供程序的基目录，例如 c:\shibboleth2idp。 在按照本主题中的说明配置 Shibboleth 时，请确保将 IDP_HOME 替换为你的特定路径。

添加 Azure AD 元数据

Shibboleth 标识提供程序需要有关 Azure AD 信赖方的信息。 Azure AD 会在 https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml 上发布元数据。 建议你经常查看该网页，以获取最新的 Azure AD 元数据。 以下是当前的元数据值：

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

若要将 Azure AD 元数据添加到 Shibboleth 标识提供程序，可以使用“文件系统元数据提供程序”方法 – 你可以手动下载 Azure AD 元数据并将其存储 IDP_HOME/metadata 文件夹中的某个文件内。

重要

在本主题的所有示例中，IDP_HOME 是安装 Shibboleth 标识提供程序的基目录，例如 c:\shibboleth2idp。 在按照本主题中的说明配置 Shibboleth 时，请确保将 IDP_HOME 替换为你的特定路径。

将 Azure AD 作为信赖方添加

你必须在 IDP_Home/conf/relying-party.xml 文件中定义新的 RelyingParty 元素，以实现 Shibboleth 标识提供程序与 Azure AD 之间的通信。 Azure AD 需要更改 DefaultRelyingParty 元素中的默认 saml:SAML2Profile 设置。

在 DefaultRelyingParty 元素后面插入以下文本，并确保 RelyingParty id 值与在添加 Azure AD 元数据中指定的 entityID 值匹配，例如“urn：federation：MicrosoftOnline”。 另外，请确保你的 provider 值与 DefaultRelyingParty 元素中指定的 Shibboleth 标识提供程序的 EntityID 匹配，如以下示例中所示：

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

你还必须向 Shibboleth 标识提供程序指定要在哪个位置查找包含 Azure AD 元数据的文件，例如，IDP_HOME/metadata/wlid-metadata.xml。 你可以通过向 MetadataProvider 节点中的 IDP_Home/conf/relying-party.xml 文件添加一个条目来实现此目的，如以下示例中所示：

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

配置 Shibboleth 属性解析程序

Azure AD 需要 Shibboleth 标识提供程序中的两个数据片断，用于在身份验证平台中查找影子帐户。 若要向 Shibboleth 通知这些要求，请在 IDP_HOME/conf/attribute-resolver.xml 文件中添加以下条目：

• Azure AD ImmutableID

  Azure AD 要求你为用户目录中的每个用户选择唯一标识符。 你还必须将 Shibboleth 配置为将每个联合登录名中的此属性发送到 SAML 2.0 NameID 断言中的 Azure AD。 此用户在系统中的整个生命周期内，其所使用的这个标识符都不可发生更改。 Azure AD 服务将此属性称为“ImmutableID”。 唯一标识符的值不能包含域信息，并且区分大小写。

  例如，请勿使用 user@contoso.com。 在下面的建议代码中，使用的值将是 base64 编码的 Active Directory objectGUID 属性。 创建帐户时，必须确保用相同的方法处理 ImmutableID，否则用户将无法登录到 Microsoft 云服务。 Microsoft Azure Active Directory同步工具自动使用 Active Directory objectGUID 作为 ImmutableID 值，并按照以下建议示例中的相同方式处理 ImmutableID：

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

  重要

  更新 attribute-resolver.xml 中的 LDAP 数据连接器，以将 objectGUID 指定为二进制。

  确保将此行添加到 LDAP 数据连接器条目，这可以确保 objectGUID 会得到正确处理，并采用 base64 编码格式。

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

  例如：

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

  Azure AD 要求使用自定义条目发送 Azure AD 用户 ID， joe@contoso.com如以下示例中所述。 在此示例中，该值存储在 LDAP userPrincipalName 属性中。

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

配置 Shibboleth 属性筛选器

必须将 Shibboleth 标识提供程序配置为将所需属性发布到 Azure AD。 在 IDP_HOME/conf/attribute-filter.xml 文件中添加以下文本，以将这些属性发布到 Azure AD。

此处显示的设置仅将所需属性发布到 Azure AD 和 Windows Live 服务。 这些设置使用特定的 AttributeFilterPolicy ID 来指示 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>

可选：安装 Shibboleth ECP 扩展

这是一个可选步骤，但建议执行此步骤。 如果使用 Shibboleth 作为 STS，请确保安装 Shibboleth 标识提供程序 ECP 扩展，以便将单一登录用于智能手机、Microsoft Outlook 或其他客户端。

增强型客户端/代理 (ECP) 扩展包含在 Shibboleth 2.3.3 及更高版本中。 对于 Shibboleth 2.x 的早期版本，你可以下载并安装 ECP 扩展。 有关详细信息，请参阅：https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension。

使用 Shibboleth 标识提供程序 ECP 扩展可使桌面电子邮件应用程序与 Azure AD 相集成。 此扩展实施 SAML 2.0 ECP 规范。 在为 Azure AD 配置单一登录时，可为 ECP 扩展指定 URL，例如，https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP。 Shibboleth ECP 扩展身份验证当前限制为基本身份验证。

如果你选择安装 Shibboleth ECP 扩展，请完成以下步骤：

1. 将以下代码添加到 IDP_HOME/metadata 中的本地 Azure AD 元数据文件：

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

2. 将“saml:SAML2ECPProfile”条目添加到 IDP_HOME/config 中 relying-party.xml 内的 Azure AD RelyingParty 配置节点：

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

重新启动 Shibboleth 并验证功能

停止后又再启动 Apache Tomcat 以重新启动 Shibboleth 标识提供程序，并确保加载更新的 XML 文件。 如果一个或多个配置文件出现问题，则 Shibboleth 可能无法启动。 重新启动后检查 Shibboleth 日志文件，以确保未报告任何错误。 我们还建议你尝试在网络上登录并访问前面配置的 Shibboleth 服务提供程序。

注意

验证 Shibboleth 服务器上的时钟是否与准确的时间源同步。 时钟的时间不准确可能导致联合身份验证登录失败。

另请参阅

概念

使用 Shibboleth 标识提供程序实施单一登录