設定要用於單一登入的 Shibboleth

  • 發行項

更新日期：2015 年 6 月 25 日

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

本主題包含有關如何設定 Shibboleth Identity Provider 以與 Azure AD 同盟的詳細指示，以啟用一或多個 Microsoft 雲端 (服務的單一登入存取，例如，使用 SAML 2.0 通訊協定Microsoft Intune和/或Office 365) 。 此案例所使用之 Microsoft 雲端服務的 SAML 2.0 信賴憑證者是 Azure AD。

重要

此單一登入案例僅支援有限的用戶端集合，如下所述：

  • Web 用戶端，例如 Exchange Web Access 和 SharePoint Online

  • 使用基本驗證和 IMAP、POP、Active Sync、MAPI 等支援之 Exchange 存取方法的電子郵件用戶端 (須部署加強型用戶端通訊協定端點)，包括：

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 和 9

    • iPhone (各個 iOS 版本)

    • Windows Phone 7

此單一登入案例中不支援使用 Shibboleth Identity Provider 的所有其他用戶端。   例如，不支援 Lync 2010 桌面用戶端使用設定為單一登入的 Shibboleth Identity Provider 登入服務。

重要

您必須先檢閱並遵循 準備單一登入中提供的指示，才能完成本主題中的任何步驟來設定 Shibboleth Identity Provider。

如需單一登入的一般資訊，請參閱 單一登入藍圖。

若要設定 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 身分識別提供者，您可以使用 Filesystem 中繼資料提供者方法 – 您可以手動下載 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 識別碼值符合您在新增 Azure AD 中繼資料中指定的entityID值，例如「urn：federation：MicrosoftOnline」。 此外，請確定您的提供者值符合 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/windows-azure-ad-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 物件GUID 作為 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 使用者識別碼

    Azure AD 要求使用自訂專案傳送 Azure AD 使用者識別碼， 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 識別碼，指出 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 Identity Provider ECP 延伸模組，以便透過智慧型手機、Microsoft Outlook 或其他用戶端進行單一登入。

Shibboleth 2.3.3 和更新版本包含增強的用戶端/Proxy (ECP) 延伸模組。 如需舊版的 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. 在位於 IDP_HOME/config 的 relying-party.xml 中，將 "saml:SAML2ECPProfile" 項目新增至 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 Identity Provider 來實作單一登入