使用 SAML 2.0 識別提供者 (IdP) 來進行單一登入

文章
06/23/2024

本文件所含的資訊是關於使用符合 SAML 2.0 規範的 SP-Lite 設定檔型識別提供者，作為慣用的 Security Token Service (STS) / 識別提供者。當您已具有內部部署的使用者目錄和密碼存放區且可使用 SAML 2.0 加以存取時，這個案例非常實用。您可以使用這個現有的使用者目錄來登入 Microsoft 365 和其他受到 Microsoft Entra ID 保護的資源。 SAML 2.0 SP-Lite 設定檔是以廣為使用的安全性聲明標記語言 (SAML) 同盟身分識別標準作為基礎，以提供登入和屬性交換架構。

注意

如需已通過測試可與 Microsoft Entra ID 搭配使用的第 3 方 IdP 清單，請參閱 Microsoft Entra 同盟相容性清單

Microsoft 藉由整合 Microsoft 雲端服務 (例如 Microsoft 365) 和您已正確設定的 SAML 2.0 設定檔型 IdP，來支援此登入體驗。 SAML 2.0 識別提供者是第三方產品，因此 Microsoft 不支援與這些識別提供者有關的部署、設定和疑難排解最佳做法。適當地設定之後，就可以使用 Microsoft 連線分析程式工具，來測試與 SAML 2.0 識別提供者的整合是否已適當設定，詳情請見下面說明。如需 SAML 2.0 SP-Lite 設定檔型識別提供者的詳細資訊，請詢問提供此識別提供者的組織。

重要

在此登入案例中，只有一小部分的用戶端可與 SAML 2.0 識別提供者搭配使用，這些用戶端包括：

Web 型用戶端，例如 Outlook Web Access 和 SharePoint Online
豐富型電子郵件用戶端，其使用基本驗證和受支援的 Exchange 存取方法 (例如 IMAP、POP、Active Sync、MAPI 等)。 (必須有增強型用戶端通訊協定端點才能部署)，這些用戶端包括：
- Microsoft Outlook 2010/Outlook 2013/Outlook 2016、Apple iPhone (各種 iOS 版本)
- 各種 Google Android 裝置
- Windows Phone 7、Windows Phone 7.8 及 Windows Phone 8.0
- Windows 8 郵件用戶端和 Windows 8.1 郵件用戶端
- Windows 10 郵件用戶端

在此登入案例中，其他所有用戶端則無法與 SAML 2.0 識別提供者搭配使用。例如，若服務的設定是使用 SAML 2.0 識別提供者來進行單一登入，則 Lync 2010 桌面用戶端則無法登入該服務。

Microsoft Entra SAML 2.0 通訊協定需求

本文件詳述為了與 Microsoft Entra ID 同盟以便能夠登入一或多個 Microsoft 雲端服務 (例如 Microsoft 365)，您的 SAML 2.0 識別提供者必須實作的通訊協定和訊息格式需求。此案例所使用之 Microsoft 雲端服務的 SAML 2.0 信賴憑證者 (SP-STS) 是 Microsoft Entra ID。

建議您務必要讓 SAML 2.0 識別提供者的輸出訊息盡可能地與所提供的追蹤範例類似。此外，如有可能，也請使用來自所提供之 Microsoft Entra 中繼資料的特定屬性值。在對輸出訊息感到滿意後，您可以使用 Microsoft 連線分析程式來進行測試，方法如下所述。

您可以從下列 URL 下載 Microsoft Entra 中繼資料：https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml。若您是使用中國專屬 Microsoft 365 執行個體的中國客戶，則請使用下列同盟端點：https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml。

SAML 通訊協定需求

本節詳述如何將要求和回應訊息成對放在一起，以協助您正確地設定訊息格式。

您可以對 Microsoft Entra ID 進行設定，讓 Microsoft Entra ID 與使用 SAML 2.0 SP Lite 設定檔 (具有如下所示的某些特定需求) 的識別提供者搭配運作。透過使用 SAML 要求和回應訊息範例以及自動和手動的測試，您就可以實現與 Microsoft Entra ID 的互通性。

簽章區塊需求

在 SAML 回應訊息內，簽章節點含有訊息本身數位簽章的相關資訊。簽章區塊具有下列需求︰

判斷提示節點本身必須經過簽署
必須使用 RSA-sha1 演算法來作為 DigestMethod。不接受其他數位簽章演算法。 <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
您也可以簽署 XML 文件。
Transform Algorithm 必須符合下列範例中的值：<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
SignatureMethod Algorithm 必須符合下列範例：<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

注意

為了改善安全性，SHA-1 演算法已遭淘汰。請務必使用更安全的演算法，例如 SHA-256。如需詳細資訊，請參閱這裡。

支援的繫結

繫結就是所需的傳輸相關通訊參數。下列需求適用於繫結

HTTPS 是必要的傳輸。
Microsoft Entra ID 需要 HTTP POST 才能在登入期間提交權杖。
Microsoft Entra ID 會對識別提供者的驗證要求使用 HTTP POST，並對識別提供者的登出訊息使用 REDIRECT。

必要屬性

下表顯示 SAML 2.0 訊息中特定屬性的需求。

屬性	描述
NameID	這個判斷提示的值必須與 Microsoft Entra 使用者的 ImmutableID 相同。此值最多可以有 64 個英數字元。任何非 html 的安全字元都必須編碼，例如，"+" 字元會顯示為 ".2B"。
IDPEmail	在 SAML 回應中，系統會將使用者主體名稱 (UPN) 列為名稱是 IDPEmail 的元素，其為使用者在 Microsoft Entra ID/Microsoft 365 中的 UserPrincipalName (UPN)。此 UPN 會使用電子郵件地址格式。 Windows Microsoft 365 (Microsoft Entra ID) 中的 UPN 值。
Issuer	必須是識別提供者的 URI。請勿重複使用範例訊息中的簽發者。如果您的 Microsoft Entra 租用戶有多個頂層網域，Issuer 必須符合針對每個網域所設定的指定 URI 設定。

重要

針對 SAML 2.0，Microsoft Entra ID 目前支援下列 NameID 格式的 URI：urn:oasis:names:tc:SAML:2.0:nameid-format:persistent。

SAML 要求和回應訊息範例

下面顯示了一對用來交換登入訊息的要求和回應訊息。以下是從 Microsoft Entra ID 傳送到範例 SAML 2.0 識別提供者的範例要求訊息。 SAML 2.0 識別提供者範例是設定為使用 SAML-P 通訊協定的 Active Directory 同盟服務 (AD FS)。此範例也已經對其他 SAML 2.0 識別提供者完成互通性測試。

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

如果 isSignedAuthenticationRequestRequired 已啟用 (如 internaldomainfederation-update (英文) 中所述)，則要求看起來會像下面這個範例：

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

以下是從符合 SAML 2.0 規範的範例識別提供者傳送到 Microsoft Entra ID/Microsoft 365 的範例回應訊息。

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

設定 SAML 2.0 相容識別提供者

本節所含的指導方針會指出如何設定 SAML 2.0 識別提供者來與 Microsoft Entra ID 同盟，以便能夠使用 SAML 2.0 通訊協定，以單一登入的方式存取一或多個 Microsoft 雲端服務 (例如 Microsoft 365)。此案例所使用之 Microsoft 雲端服務的 SAML 2.0 信賴憑證者是 Microsoft Entra ID。

新增 Microsoft Entra 中繼資料

您的 SAML 2.0 識別提供者需要遵守 Microsoft Entra ID 信賴憑證者的相關資訊。 Microsoft Entra ID 會在以下位置發佈中繼資料：https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml。

當您在設定 SAML 2.0 識別提供者時，建議您一律匯入最新的 Microsoft Entra 中繼資料。

注意

Microsoft Entra ID 不會從識別提供者讀取中繼資料。

將 Microsoft Entra ID 新增為信賴憑證者

您必須啟用 SAML 2.0 識別提供者與 Microsoft Entra ID 之間的通訊。這項設定會根據您使用的特定識別提供者而有所不同，因此請參閱其相關文件。一般來說，您會將信賴憑證者識別碼設定為和來自 Microsoft Entra 中繼資料的 entityID 相同。

注意

請確認 SAML 2.0 識別提供者伺服器上的時鐘已和正確的時間來源同步。時鐘時間不正確將可能導致同盟登入失敗。

安裝 PowerShell 以使用 SAML 2.0 識別提供者來進行登入

在設定 SAML 2.0 識別提供者以便與 Microsoft Entra 登入搭配使用後，下一步是下載並安裝 Microsoft Graph PowerShell (英文) 模組。安裝完成後，您將會使用這些 Cmdlet 來將 Microsoft Entra 網域設定為同盟網域。

Microsoft Graph PowerShell 模組可供下載以用於管理 Microsoft Entra ID 中的組織資料。此模組會在 PowerShell 中安裝一組 Cmdlet；您必須執行這些 Cmdlet 來設定 Microsoft Entra ID 的單一登入存取權，進而設定您所訂閱之所有雲端服務的單一登入存取權。如需如何下載並安裝 Cmdlet 的指示，請參閱安裝 Microsoft Graph PowerShell SDK (英文)。

設定 SAML 識別提供者與 Microsoft Entra ID 的信任關係

在 Microsoft Entra 網域中設定同盟之前，您必須先設定自訂網域。您無法為 Microsoft 所提供的預設網域建立同盟關係。 Microsoft 的預設網域會以 onmicrosoft.com 結尾。您會執行一系列的 PowerShell Cmdlet，以新增或轉換用於單一登入的網域。

每個您想要使用 SAML 2.0 識別提供者來建立同盟的 Microsoft Entra 網域，都必須新增為單一登入網域，或從標準網域轉換為單一登入網域。新增或轉換網域會設定 SAML 2.0 識別提供者和 Microsoft Entra ID 之間的信任關係。

下列程序可逐步引導您將現有的標準網域轉換為使用 SAML 2.0 SP-Lite 的同盟網域。

注意

在採取此步驟之後，您的網域可能會發生可能影響使用者長達 2 小時的中斷。

在 Microsoft Entra 目錄中設定用於同盟的網域

以租用戶管理員的身分連線到您的 Microsoft Entra 目錄：
```
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
```

設定要用來搭配使用同盟功能和 SAML 2.0 的 Microsoft 365 網域：

$Domain = "contoso.com"  
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
$MyUri = "urn:uri:MySamlp2IDP"
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
$MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
$Protocol = "saml"

New-MgDomainFederationConfiguration `
  -DomainId $Domain `
  -ActiveSignInUri $ecpUrl `
  -IssuerUri $MyUri `
  -PassiveSignInUri $LogOnUrl `
  -PreferredAuthenticationProtocol $Protocol `
  -SignOutUri $LogOffUrl `
  -SigningCertificate $MySigningCert

您可以從 IDP 中繼資料檔案取得簽署憑證的 base64 編碼字串。此位置的範例提供如下，但實際位置可能會隨您的實作而有所不同。

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="signing">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
     <X509Data>
       <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
</IDPSSODescriptor>

如需詳細資訊，請參閱 New-MgDomainFederationConfiguration (英文)。

注意

只有在已經為識別提供者設定 ECP 擴充功能時，才必須使用 $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS"。 Exchange Online 用戶端 (Outlook Web App (OWA) 除外) 仰賴以 POST 為基礎的作用中端點。如果您的 SAML 2.0 STS 所實作的作用中端點，類似於 Shibboleth 以 ECP 實作的作用中端點，則這些豐富型用戶端可能可以和 Exchange Online 服務互動。

在設定同盟後，您可以切換回「非同盟」(或「受控」) 模式，不過，系統最多需要兩個小時才能完成這項變更，而且您必須對每個使用者指派新的隨機密碼以用於雲端式登入。在某些情況下，您可能需要切換回「受控」模式，以將設定中的錯誤重設。如需網域轉換的詳細資訊，請參閱 Remove-MgDomainFederationConfiguration (英文)。

將使用者主體佈建到 Microsoft Entra ID/Microsoft 365

您必須先以使用者主體 (對應到 SAML 2.0 宣告中的判斷提示) 佈建 Microsoft Entra ID，然後才能向 Microsoft 365 驗證您的使用者。如果 Microsoft Entra ID 事先不知道這些使用者主體，則無法使用它們進行同盟登入。 Microsoft Entra Connect 或 PowerShell 均可用來佈建使用者主體。

您可以使用 Microsoft Entra Connect 將主體從內部部署 Active Directory 佈建到您在 Microsoft Entra 目錄中的網域。如需詳細資訊，請參閱整合您的內部部署目錄與 Microsoft Entra ID (部分機器翻譯)。

您也可以使用 PowerShell 來自動將新的使用者新增至 Microsoft Entra ID，並從內部部署目錄同步處理變更。若要使用 PowerShell Cmdlet，您必須下載 Microsoft Graph PowerShell (英文) 模組。

此程序示範如何將單一使用者新增至 Microsoft Entra ID。

使用 Connect-MgGraph (英文)，以租用戶管理員的身分連線到您的 Microsoft Entra 目錄。

建立新的使用者主體：

$Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$PasswordProfile = @{ Password = "$Password" }

New-MgUser `
  -UserPrincipalName "elwoodf1@contoso.com" `
  -DisplayName "Elwood Folk" `
  -GivenName "Elwood" `
  -Surname "Folk" `
  -AccountEnabled `
  -MailNickName 'ElwoodFolk' `
  -OnPremisesImmutableId ABCDEFG1234567890 `
  -OtherMails "Elwood.Folk@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -UsageLocation "US"

如需詳細資訊，請參閱 New-MgUser (英文)。

注意

“UserPrincipalName” 值必須符合您會為 SAML 2.0 宣告中的 “IDPEmail” 傳送的值，“OnPremisesImmutableId” 值則必須符合 “NameID” 判斷提示中所傳送的值。

使用 SAML 2.0 IDP 驗證單一登入

若您是系統管理員，請在驗證和管理單一登入 (也稱為身分識別同盟) 之前，先檢閱相關資訊並執行下列文章中的步驟，以設定使用 SAML 2.0 SP-Lite 型識別提供者來進行的單一登入：

您已檢閱 Microsoft Entra SAML 2.0 通訊協定需求
您已設定 SAML 2.0 識別提供者
安裝 PowerShell 以使用 SAML 2.0 識別提供者來進行單一登入 (SSO)
設定 SAML 2.0 識別提供者與 Microsoft Entra ID 的信任關係
已透過 PowerShell 或 Microsoft Entra Connect，將已知的測試使用者主體佈建至 Microsoft Entra ID (Microsoft 365)。
使用 Microsoft Entra Connect (部分機器翻譯) 來設定目錄同步作業。

在設定了使用 SAML 2.0 SP-Lite 型識別提供者來進行的 SSO 後，您應該確認它是否能正常運作。如需如何測試 SAML 型 SSO 的詳細資訊，請參閱測試 SAML 型單一登入 (部分機器翻譯)。

注意

如果您轉換網域而非新增網域，系統最多可能需要 24 小時才能設定好單一登入。在驗證單一登入之前，請先完成 Active Directory 同步作業的設定、對目錄進行同步處理，並啟用已同步處理的使用者。

手動驗證系統是否已正確設定單一登入

手動驗證提供了更多的步驟供您執行，以確保您的 SAML 2.0 識別提供者在許多情況下皆可正常運作。若要驗證系統是否已正確設定單一登入，請完成下列步驟：

在已加入網域的電腦上，使用和您用於公司認證相同的登入名稱來登入雲端服務。
在密碼方塊內進行選取。如果已設定單一登入，密碼方塊會呈陰影狀，而且您會看到下列訊息：「現在您必須在 <您的公司> 登入。」
選取 [在 <您的公司> 登入] 連結。如果您能夠登入，便代表單一登入已設定完成。

後續步驟

使用 Microsoft Entra Connect 管理和自訂 Active Directory 同盟服務 (部分機器翻譯)
Microsoft Entra 同盟相容性清單
Microsoft Entra Connect 自訂安裝 (部分機器翻譯)

分享方式：