SAML 2.0 設定：中繼資料與無中繼資料

本文涵蓋在兩個 SAML 2.0 Federation 伺服器之間建立信任時使用 SAML 2.0 中繼資料的優點，而不是透過輸入 / 複製 / 貼上 URL、憑證手動提供和輸入資訊。

建立信任

在 SAML 2.0 WebSSO 的相關資訊環境中建立信任是設定 SAML 2.0 識別提供者和 SAML 2.0 服務提供者的動作，讓它們可以執行聯合 SSO 作業。

建立信任涉及下列步驟：

• 在 SAML 2.0 身分識別提供者建立夥伴項目，代表具有下列資訊的遠端服務提供者

• SP 的 EntityID 或 ProviderID 是參照 SP 的唯一 ID

• IdP 以 SAML 宣告重導使用者時的「宣告用戶服務 URL」

• 每個 URL 可能有不同的連結 (例如 urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact、urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST 或 urn:oasis:names:tc:SAML:2.0:bindings:PAOS)

• IdP 在 SAML 2.0 登出交換期間重新導向使用者的「登出服務 URL」

• 每個連結都有不同的連結 (例如 urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)

• 每個服務可能會有不同的 URL 可接收 LogoutRequest 訊息和 LogoutResponse 訊息

• 與 SP 用來簽署外送 SAML 2.0 訊息 (例如 AuthnRequest) 之私密金鑰對應的 X.509 憑證

• LogoutRequest/LogoutResponse 或 ArtifactResolve 訊息

• 與 SP 用來解密遠端 IdPs 加密之內送 SAML 2.0 訊息 (使用憑證) 對應的 X.509 憑證，例如 SSO 回應內的宣告 /NameID/Attribute 元素

• 在 SAML 2.0 服務提供者建立夥伴項目，此項目代表具有下列資訊的遠端身分識別提供者

• IdP 的 EntityID 或 ProviderID，這是參照 IdP 的唯一 ID

• SP 重新導向使用者與 SAML AuthnRequest 的單一登入服務 URL

• 每個 URL 可能有不同的連結 (例如 urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST 或 urn:oasis:names:tc:SAML:2.0:bindings:SOAP)

• SP 在 SAML 2.0 登出交換期間重新導向使用者的「登出服務 URL」

• 每個連結都有不同的連結 (例如 urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)

• 每個服務可能會有不同的 URL 可接收 LogoutRequest 訊息和 LogoutResponse 訊息

• 與 IdP 用來簽署外送 SAML 2.0 訊息之私密金鑰對應的 X.509 憑證，例如宣告、LogoutRequest/LogoutResponse 或 ArtifactResponse 訊息

• 與 IdP 使用之私密金鑰對應的 X.509 憑證，以解密遠端 SP 加密的內送 SAML 2.0 訊息 (例如「登出要求」內的 NameID 元素)

以上只涵蓋「聯合 SSO」設定。如果「同盟」夥伴支援其他服務 (例如「屬性授權單位」和「屬性要求者」)，則需要交換更多的「服務 URL」和憑證資訊。

手動處理

如您所見，負責管理「聯合」伺服器的管理員之間可能會交換許多資訊，而任何次要的錯誤都可能導致未正確設定「聯合」協議，並造成執行時期錯誤。

手動建立信任可能發生的錯誤如下：

• 使用的憑證錯誤

• 不正確的服務 URL/ 連結組合，例如只用於「使用者自建物件」連結的「宣告用戶服務 URL」是用於 HTTP-POST 連結

• URL 中輸入

• 在服務 URL 中指定主機名稱不正確：由於 Cookie 會在進行聯合 SSO 作業時使用。使用者用來存取聯合伺服器的公用端點，是使用相同完整主機名稱的原始名稱。(IP 位址或非完整主機名稱導致錯誤)

• ProviderIDs 中的輸入內容

• 缺少網址

這些錯誤會導致：

• 使用不正確的憑證伺服器發出錯誤時，發生簽名驗證或解密失敗，因為

  • 認證無效

  • 行使的功能遺漏 URL (例如遺漏「登出 URL」)

  • 使用了不一致的主機名稱 (完整與 IP 位址 vs 不完整) ProviderID 不明，是由打字所造成

  • 因為使用了不一致的主機名稱，所以使用無限迴圈

上面列出的錯誤比人們所假設的還要多，這使得時間花在追查「聯合 SSO」為何無法正確運作，幾乎指向「聯合信任」機構錯誤。

使用 SAML 2.0 描述資料

SAML 2.0 規格定義描述資料文件，其中包含伺服器必須知道的所有資訊，才能與遠端夥伴執行聯合作業。

這些資訊包括：

• 服務 URL

• 服務的 SAML 組合

• 簽章和加密作業的憑證

• 哪些訊息將被簽署 (AuthnRequest、宣告)

• Federation Server 支援的角色 (IdP、SP、屬性授權 ...)

SAML 2.0 描述資料通常是由聯合伺服器本身產生，並由夥伴的聯合伺服器使用：因此不會有手動介入來建立及使用此文件，進而減少潛在的錯誤數目。

使用 SAML 2.0 描述資料有下列優點：

• 所有資訊都包含在單一文件中

• 文件由聯合伺服器產生及使用 (簽章可用來防止竄改)

• 未省略任何資訊

• 資料一致 (所有 URL 中使用的主機名稱相同)

更重要的是，它可減少聯邦信任建立期間發生錯誤的可能性，以節省時間，以便稍後執行階段錯誤的機會較少。

其他學習資源

探索 docs.oracle.com/learn 上的其他實驗室，或存取 Oracle Learning YouTube 頻道上的更多免費學習內容。此外，瀏覽 education.oracle.com/learning-explorer 成為 Oracle Learning Explorer。

如需產品文件，請造訪 Oracle Help Center 。

---

標題與版權資訊

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.