4.1 密鑰管理#

在任何 FAL 中，IdP 應確保 RP 無法透過使用經批准的加密技術的簽章和金鑰來保護斷言，從而在另一個 RP 處模擬 IdP。如果斷言受使用非對稱金鑰的數位簽章保護，則 IdP 可以使用相同的公鑰和私鑰對向多個 RP 簽署主張。 IdP 可以以可驗證的方式發佈其公鑰，例如在眾所周知的位置的受 HTTPS 保護的 URL 上。如果斷言由使用共用金鑰的 MAC 保護，則 IdP 應為每個 RP 使用不同的共用金鑰。

在 AAL2 上斷言身份驗證的政府運營的 IdP 以及在 AAL3 上斷言身份驗證的所有 IdP 應使用在FIPS 140 1 級或更高級別驗證的機制來保護用於簽署或加密這些斷言的密鑰。

4.2 運行時決策#

各方聯邦的事實不應被解釋為允許傳遞訊息。是否可以進行認證或是否可以傳遞屬性的決定可以透過使用白名單、黑名單或授權方的運行時決定來確定。

IdP 可以建立授權接收來自 IdP 的身份驗證和屬性的 RP 白名單，而無需訂閱者在執行時做出決定。 IdP 白名單中的所有 RP 應遵守 SP 800–63 套件中的規定和要求。 IdP 應依照第 9.2 節所述向訂戶提供白名單。 IdP 還可以建立未經授權從 IdP 接收身份驗證或屬性的 RP 黑名單，即使是在訂閱者請求時也是如此。白名單和黑名單都透過網域或其他足夠獨特的識別碼來識別 RP，具體取決於所使用的聯邦協議。預設情況下，不在白名單或黑名單上的每個 RP 應置於灰色區域，其中執行時授權決策將由授權方（通常是訂戶）做出。 IdP 可以記住訂閱者授權給定 RP 的決定，前提是 IdP 應允許訂閱者在將來撤銷此類記住的存取。

RP 可以建立 IdP 白名單，RP 將接受其中的身份驗證和屬性，而無需訂閱者進行運行時決策。 RP 白名單中的所有 IdP 應遵守 800–63 套件中的規定和要求。 RP 還可以建立 IdP 黑名單，即使訂閱者請求，RP 也不會接受來自的身份驗證或屬性。白名單和黑名單都透過網域或其他足夠獨特的識別碼來識別 IdP，具體取決於所使用的聯邦協議。預設情況下，不在白名單或黑名單上的每個 IdP 應置於灰色區域，其中執行時授權決策將由授權方（通常是訂戶）做出。 RP 可以記住訂閱者授權給定 IdP 的決定，前提是 RP 應允許訂閱者在將來撤銷此類記住的存取。

訂閱者的資訊應僅在身份聯邦交易或支援功能（例如第 5.2 節中討論的受損帳戶識別）之間在 IdP 和 RP 之間傳輸。訂戶的資訊不得出於任何其他目的而傳輸，即使這些方已列入白名單。

為了降低未經授權暴露敏感資訊（例如，肩窺）的風險，預設情況下，IdP 應封鎖向訂閱者顯示的敏感資訊。 IdP 應提供訂閱者暫時取消封鎖此類資訊的機制，以便訂閱者查看完整值。 IdP 應提供有效的機制來糾正申請人的投訴或問題（例如，訂戶識別出不準確的屬性值）。有關遮蔽和糾正的更多詳細資訊，請參閱第 10 節有關可用性注意事項的內容。

當訂閱者參與執行階段決策時，訂閱者應接收明確的通知，並能夠在有關訂閱者的任何屬性傳輸到任何 RP 之前提供肯定的確認。通知至少應由能夠提供最有效通知並獲得確認的一方提供，與第 9.2 節一致。如果使用的協定允許可選屬性，則訂戶應有權決定是否將這些屬性傳輸到 RP。 IdP 可以採用機制來記住準確的屬性包並將其重新傳輸到相同 RP。

5.1 聯邦模型#

提供身份驗證服務的 IdP 和使用這些服務的 RP 稱為聯邦成員。從 IdP 的角度來看，聯邦是由它所服務的 RP 所組成。從 RP 的角度來看，聯邦由其使用的 IdP 組成。本節提供目前使用的常見身份聯邦模型的概述和要求。在每個模型中，聯邦成員之間建立了關係。

5.1.1 手動註冊#

在手動註冊模型中，IdP 和 RP 手動提供有關他們期望與其進行互通的各方的組態資訊。 IdP 可以使用明確白名單來設定 RP，允許這些 RP 接收驗證和屬性資訊作為驗證事務的一部分。在 RP 未列入白名單的情況下，IdP 應要求授權方（例如訂戶）在發布使用者資訊之前做出執行時間決策（請參閱第 4.2 節）。

圖5–2 手動註冊

如圖5–2所示，手動註冊分為三個步驟：

1. RP 的系統管理員與 IdP 的系統管理員共用 RP 的屬性，後者將這些屬性與 RP 關聯。
2. IdP 的系統管理員與 RP 的系統管理員共用 IdP 的屬性，RP 的系統管理員將這些屬性與 IdP 關聯。
3. 然後 IdP 和 RP 使用標準聯邦協定進行通訊。

IdP 和 RP 可以作為自己的權威來決定與誰結盟，或者可以將這些權威決策外部化給外部方，如第 5.1.3 節所示。

需要傳輸金鑰資訊的協定應在註冊過程中使用安全方法來交換操作聯邦關係所需的金鑰訊息，包括任何共享秘密或公鑰。在這種關係中使用的任何對稱密鑰對於一對聯邦參與者來說應該是唯一的。

聯邦關係應建立與聯邦關係相關的預期和可接受的 IAL 和 AAL 的參數。

5.1.2 動態註冊#

在聯邦的動態註冊模型中，聯邦成員之間的關係可以在交易時進行協商。此程序允許 IdP 和 RP 連接在一起，而無需使用手動註冊在它們之間手動建立連接（請參閱第 5.1.1 節）。支援動態註冊的 IdP 應以盡量減少系統管理員參與的方式提供其設定資訊（例如動態註冊端點）。

圖 5–3 動態註冊

如圖5–3所示，動態註冊分為四個步驟：

1. 發現。 RP 前往 IdP 的眾所周知的位置來尋找 IdP 的元資料。
2. 證實。 RP 和 IdP 決定彼此的有效性。這可以透過密鑰資訊、元資料、軟體語句或其他方式來完成。
3. 註冊RP屬性。 RP 將其屬性傳送給 IdP，IdP 將這些屬性與 RP 相關聯。
4. 聯邦協議。然後 IdP 和 RP 使用標準聯邦協定進行通訊。

需要傳輸金鑰資訊的協定應在註冊過程中使用安全方法來建立操作聯邦關係所需的金鑰訊息，包括任何共享秘密或公鑰。在這種關係中使用的任何對稱密鑰對於一對聯邦參與者來說應該是唯一的。

IdP 應要求授權方（例如訂戶）在發布使用者資訊之前做出執行時間決策（請參閱第 4.2 節）。接受動態註冊 RP 的 IdP 可能會限制此類 RP 可用的屬性類型和其他資訊。能夠動態註冊的 RP 可以限制它願意接受來自哪些 IdP。

動態註冊模式中的各方通常事先並不認識對方。在可能的情況下，應該透過軟體聲明來增強，允許聯邦方以加密方式驗證動態註冊的 RP 的某些屬性。軟體聲明是描述 RP 軟體的屬性列表，由權威機構（IdP 本身、第 5.1.3 節中的聯邦權威機構或其他受信任方）進行加密簽署。這種可加密驗證的聲明允許在聯邦方之間建立或提升連接，而無需僅依賴自斷言的屬性。 （有關軟體語句的一種協議實現的更多資訊，請參閱RFC 7591第 2.3 節。）

5.1.3 聯邦當局#

有些聯邦各方服從一個稱為聯邦權威的機構來協助聯邦決策並建立各方之間的工作關係。在此模型中，聯邦機構通常會對聯邦中的每一方進行一定程度的審查，以驗證是否符合預定的安全性和完整性標準。審查的層級（如果確實發生的話）對於聯邦內使用的用例和模型來說是獨特的。這種審查如圖 5–4左側所示。

聯邦當局批准國內流離失所者在某些 IAL、AAL 和 FAL 中運作。如圖5–4右側所示，依賴方使用此資訊來確定哪些身份提供者符合其要求。

聯邦當局應建立與它們啟用的聯邦關係有關的預期和可接受的 IAL、AAL 和 FAL 的參數。聯邦當局應單獨審查聯邦的每個參與者，以確定他們是否遵守預期的安全、身份和隱私標準。

圖 5–4 聯邦權威

IdP 和 RP 的審查至少應確定：

• IdP 產生的斷言符合第 6 節中的要求。
• RP 遵守 IdP 處理訂戶屬性資料的要求，例如保留、聚合和向第三方揭露。
• RP 和 IdP 系統使用經過核准的聯邦協定設定檔。

聯邦當局可以協助成員之間的技術連接和組態過程，例如透過發布 IdP 的組態資料或為 RP 發佈軟體聲明。

大多數透過當局管理的聯邦都有​​一個簡單的成員模式：各方要麼在聯邦中，要麼不在聯邦中。更複雜的聯邦可能有多個會員級別，聯邦各方可以使用這些級別來判斷聯邦中的其他各方是否經過了更徹底的審查。 IdP 可以決定某些訂戶資訊只能發佈給較高層中的 RP，而 RP 可以決定僅接受來自較高層中的 IdP 的某些資訊。

5.1.4 代理聯邦#

在代理聯邦中，IdP 和 RP 之間的通訊以阻止雙方之間直接通訊的方式進行中介。有多種方法可以達到這種效果。常見組態包括：

• 充當聯邦代理（或經紀人）的第三方
• 分發通訊的節點網絡

在使用代理的情況下，它們在一側充當 IdP，在另一側充當 RP。因此，適用於 IdP 和 RP 的所有規範性要求應適用於各自角色的代理。

圖 5–5 聯邦代理

代理聯邦模型可以提供多種好處。聯邦代理可以透過提供通用的整合介面來簡化 RP 和 IdP 之間的技術整合。此外，在某種程度上，代理商有效地使 RP 和 IdP 無法相互瞭解，它可以為想要保護其訂戶清單免受彼此影響的組織提供一定的商業機密性。代理還可以減輕下文第 5.2 節中所述的一些隱私風險。

有關致盲技術、其用途和限制的更多資訊，請參閱第 9.5 節。

5.2 隱私要求#

聯邦涉及從不參與交易的第三方（即 IdP）轉移個人屬性。聯邦也可能使 IdP 能夠廣泛瞭解訂戶活動。因此，存在與聯邦相關的特定隱私要求。

RP 和 IdP 之間的通訊可以向 IdP 透露訂閱者正在何處進行交易。與多個 RP 的通訊允許 IdP 建構訂閱者事務的設定檔案，如果沒有聯邦，則該設定檔就不會存在。這種聚合可以為訂閱者追蹤和使用並不總是符合訂閱者隱私利益的個人資料資訊提供新的機會。

如果 IdP 向任何一方披露 RP 上的訂戶活動資訊，或出於身份證明、身份驗證或屬性斷言（統稱為“身份服務”）、相關欺詐緩解、遵守法律或其他目的以外的任何目的處理訂戶資訊，在法律程序中，或在特定使用者要求傳輸資訊的情況下，IdP 應採取措施來保持與額外處理產生的隱私風險相稱的可預測性和可管理性。措施可以包括提供明確的通知、取得訂戶同意或允許選擇性使用或揭露屬性。當 IdP 使用同意措施時，IdP 不得將同意額外處理作為身份識別服務的條件。 IdP 應採用技術措施，例如使用第 6.3 節中所述的成對假名識別碼或隱私增強加密協議，以提供可分離性並阻止訂戶活動追蹤和分析。

出於安全目的，IdP 可以向聯邦內的其他 RP 披露有關訂戶活動的資訊，例如受損訂戶帳戶的通訊。

以下要求特別適用於聯邦機構：

1. 該機構應諮詢其高級隱私機構官員 (SAOP) 進行分析，確定《隱私法》的要求是否由充當 IdP 的機構、充當 RP 的機構或兩者共同觸發（參見第 9.4 節）。
2. 本機構應發布或確定記錄系統通知 (SORN) 的覆蓋範圍（如適用）。
3. 該機構應諮詢其 SAOP 進行分析，以確定電子化政府法案的要求是否由充當 IdP 的機構、充當 RP 的機構或兩者觸發。
4. 該機構應發布或確定隱私影響評估 (PIA) 的覆蓋範圍（如適用）。

5.3 聯邦環境中的重新身份驗證和會話要求#

在聯邦環境中，RP 與 IdP 上的任何會話分開管理其會話。當 RP 處理來自 IdP 的聯邦協定時，RP 上的會話開始。在共同登入時，訂閱者可以在 IdP 上擁有現有會話，該會話可以用作 RP 驗證過程的一部分。 IdP 應傳達其擁有的有關 IdP 上最新身份驗證事件時間的任何資訊，並且 RP 可以使用此資訊來確定其訪問策略。根據所使用的聯邦協議的功能，IdP 應允許 RP 請求訂戶在 IdP 處重新進行身份驗證，作為聯邦請求的一部分。

由於聯邦系統的分散特性，訂戶能夠獨立地終止與 IdP 和 RP 的會話。 RP 不應假定訂閱者在建立聯邦登入後在 IdP 上具有活動會話。

有關會話管理要求的更多資訊，請參閱SP 800–63B 第 7 部分。

6.1 斷言綁定#

斷言綁定可以根據主張者提出的斷言或斷言引用是否足以綁定到訂戶，或者 RP 是否需要額外的證據來證明斷言綁定到訂戶進行分類。

6.1.1 承載斷言#

任何一方都可以提出不記名斷言作為不記名人身份的證明。如果攻擊者可以捕獲或製造代表訂戶的有效斷言或斷言引用，並且可以成功地將該斷言或引用呈現給 RP，那麼攻擊者就能夠在該 RP 處冒充訂戶。

請注意，僅僅擁有不記名斷言或引用並不總是足以冒充訂戶。例如，如果在反向通道聯合模型中提出斷言（第 7.1 節中描述），則可以對交易進行額外的控制（例如 RP 的識別和斷言注入保護），以幫助進一步保護 RP 免受欺詐活動。

6.1.2 密鑰持有者斷言#

密鑰持有者斷言包含對由訂閱者擁有並代表訂閱者的密鑰的引用。金鑰持有者中引用的金鑰代表訂閱者，而不是系統中的任何其他方，包括瀏覽器、IdP 或 RP。請注意，對密鑰的引用由斷言的發布者斷言（並簽署）。

當 RP 收到金鑰持有者斷言時，訂閱者直接向 RP 證明擁有斷言中引用的金鑰。雖然訂戶也可以使用基於金鑰的方式向 IdP 進行身份驗證，但 IdP 處的主要身份驗證和 RP 處的聯合身份驗證是分開考慮的，並且不假定使用相同的金鑰或相關會話。

在證明擁有 RP 訂戶金鑰時，索賠人還以一定程度的保證證明他們是該主張的合法主體。對於攻擊者來說，使用發布給訂戶的被盜密鑰持有者斷言更加困難，因為攻擊者還需要竊取所引用的密鑰材料。

以下要求適用於所有密鑰持有者斷言：

1. 除了聲明本身的呈現之外，訂戶還應證明擁有 RP 的金鑰。
2. 包含對訂戶持有的密鑰的引用的斷言，如果密鑰擁有尚未被證明，則應被RP 視為不記名斷言。
3. 對給定密鑰的引用應與斷言中的所有其他資訊處於同一級別受信任。
4. 該斷言不應包含與金鑰持有者表示一起使用的未加密的私鑰或對稱金鑰。
5. 此金鑰可以不同於訂閱者用於向 IdP 進行身份驗證的任何金鑰。
6. 金鑰可以是對稱金鑰或與私鑰相對應的公鑰。
7. RP 可以與 IdP 一起驗證索賠人是否擁有金鑰，例如，透過請求 IdP 驗證索賠人回應密碼質詢而計算的簽章或 MAC。

6.2 斷言保護#

獨立於綁定機制（第 6.1 節中討論）或用於獲取它們的聯合模型（第 5.1 節中描述），斷言應包括一組保護措施，以防止攻擊者製造有效的斷言或在不同的RP 上重用捕獲的斷言。所需的保護取決於所考慮的用例的詳細資訊，此處列出了建議的保護。

6.2.1 斷言標識符#

斷言應足夠唯一，以允許目標 RP 進行唯一識別。斷言可以透過使用嵌入的隨機數、發佈時間戳記、斷言標識符或這些或其他技術的組合來實現這一點。

6.2.2簽名斷言#

斷言應由頒發者 (IdP) 進行加密簽章。 RP 應根據發行者的金鑰驗證每個此類斷言的數位簽章或 MAC。該簽名應涵蓋整個斷言，包括其識別碼、發行者、受眾、主題和過期時間。

斷言簽章應為使用非對稱金鑰的數位簽章或使用 RP 和發行者之間共用的對稱金鑰的 MAC。 IdP 為此目的使用的共享對稱金鑰應獨立於它們向其發送斷言的每個 RP，並且通常在 RP 註冊期間建立。用於驗證數位簽章的公鑰可以由 RP 在執行時間以安全方式取得，例如透過 IdP 託管的 HTTPS URL。應使用經批准的加密技術。

6.2.3加密斷言#

當加密斷言時，IdP 應使用 RP 的公鑰或共用對稱金鑰來加密斷言的內容。 IdP 為此目的使用的共享對稱金鑰應獨立於它們向其發送斷言的每個 RP，並且通常在 RP 註冊期間建立。用於加密的公鑰可以由 IdP 在運行時以安全方式獲取，例如透過 RP 託管的 HTTPS URL。

所有斷言加密應使用經批准的加密技術。

當斷言透過第三方（例如瀏覽器）傳遞時，實際斷言應被加密。例如，可以使用 XML 加密對 SAML 斷言進行加密，或者可以使用 JSON Web 加密 (JWE) 對 OpenID Connect ID 令牌進行加密。對於直接在 IdP 和 RP 之間傳遞的斷言，實際斷言可以加密。如果不是，則斷言應透過經過驗證的受保護通道發送。

注意：FAL2 和 FAL3 需要斷言加密。

6.2.4 觀眾限制#

斷言應使用受眾限制技術來允許 RP 識別它是否是已發布斷言的預期目標。所有 RP 應檢查斷言的受眾是否包含其 RP 的標識符，以防止在另一個 RP 上註入和重播為一個 RP 產生的斷言。

6.3 成對假名標識符#

在某些情況下，希望防止 IdP 處的訂戶帳戶透過使用公共識別碼而在多個 RP 處輕易連結。

6.3.1 一般要求#

當在 IdP 為 RP 產生的斷言中使用成對假名主體標識符時，IdP 應為每個 RP 產生不同的標識符，如下文第 6.3.2 節所述。

當成對假名標識符與 RP 以及屬性一起使用時，多個共謀的 RP 仍然有可能透過使用這些身份屬性的系統之間的關聯來重新識別訂戶。例如，如果兩個獨立的RP 各自看到用不同的成對假名標識符標識的同一訂閱者，他們仍然可以透過比較成對假名標識符附帶的姓名、電子郵件地址、實際地址或其他識別屬性來確定該訂閱者是同一個人。隱私策略應該禁止這種關聯，並且成對的假名識別碼可以透過增加管理屬性關聯的管理工作來提高這些策略的有效性。

請注意，在代理聯合模型中，初始 IdP 可能無法為最終 RP 產生成對的假名標識符，因為代理可能會使 IdP 矇蔽，無法知道訂閱者正在存取哪個 RP。在這種情況下，通常在 IdP 和聯合代理本身之間建立成對的假名識別碼。充當 IdP 的代理本身可以向下游 RP 提供成對的假名識別碼。根據協定的不同，聯合代理可能需要將成對的假名標識符對應回來自上游 IdP 的關聯標識符，以便允許身份協定發揮作用。在這種情況下，代理將能夠追蹤並確定哪些成對假名標識符代表不同 RP 處的相同訂戶。代理不得向第三方披露成對假名標識符與任何其他標識符之間的對應，也不得將該資訊用於除聯合身份驗證、相關欺詐緩解、遵守法律或法律程序或在以下情況之外的任何目的：特定使用者對資訊的請求。

6.3.2 成對假名標識符生成#

成對假名標識符不應包含有關訂戶的識別資訊。有權存取某些識別訂戶資訊的一方也無法猜測它們。成對假名標識符可以隨機產生並由IdP 分配給訂戶，或者可以從其他訂戶資訊中導出，如果導出是以不可逆、不可猜測的方式完成的（例如，使用帶有密鑰的密鑰雜湊函數）。通常，標識符應僅由一對端點（例如，IdP-RP）知道和使用。然而，IdP 可以根據這些 RP 的請求為多個 RP 上的訂戶產生相同的標識符，前提是：

• 這些 RP 具有可證明的關係，可以證明相關性的操作需求是合理的，例如共享安全域或共享合法所有權；和
• 所有共享標識符的 RP 都同意以這種方式關聯。

RP 應進行隱私風險評估，以考慮與請求通用識別碼相關的隱私風險。有關進一步的隱私注意事項，請參閱第 9.2 節。

IdP 應確保僅關聯預期的 RP；否則，流氓 RP 可以透過欺騙性地冒充一組相關 RP 的一部分來瞭解該群組的假名標識符。

7.1 後台頻道呈現#

在反向通道模型中，通常透過前通道向訂閱者提供要呈現給 RP 的斷言參考。斷言引用本身不包含有關訂閱者的資訊，並且應防止攻擊者篡改和偽造。 RP 向 IdP 提供斷言引用，通常連同 RP 本身的身份驗證一起，以獲得斷言。

圖 7–1 反向通道演示

如圖7–1所示，反向通道呈現模型由三個步驟組成：

1. IdP 透過前端通道向訂閱者發送斷言參考。
2. 訂閱者透過前通道將斷言引用發送給RP。
3. RP 透過反向通道向 IdP 提供斷言參考及其 RP 憑證。 IdP 驗證憑證並傳回斷言。

斷言參考：

1. 應僅限於單一 RP 使用。
2. 應為一次性使用。
3. 應該有時間限制，生命週期很短，只有幾秒鐘或幾分鐘。
4. 應與 RP 的身份驗證一起提供。

在此模型中，RP 直接向 IdP 請求斷言，最大限度地減少第三方（包括訂閱者本身）攔截和操縱的機會。

此方法還允許 RP 向 IdP 查詢有關未包含在斷言本身中的訂閱者的其他屬性，因為在完成初始驗證事務後，反向通道通訊可以繼續發生，而無需將使用者傳送回 IdP。該查詢使用與斷言一起發布的授權元件來進行，如第 6 節所述。

反向通道方法需要更多的網路交易，但資訊僅限於那些需要它的各方。由於 RP 期望僅直接從 IdP 獲得斷言，因此減少了攻擊面。因此，將斷言直接注入 RP 更加困難。

RP 應透過使用跨站點腳本保護或其他可接受的技術來保護自身免受製造或捕獲的斷言引用的注入。

斷言中的元素應由 RP 驗證，包括：

• 頒發者驗證：確保斷言是由 RP 期望的 IdP 發出的。
• 簽章驗證：確保斷言的簽章對應於傳送斷言的 IdP 相關的金鑰。
• 時間驗證：確保過期和發佈時間在目前時間戳記的可接受範圍內。
• 受眾限制：確保此 RP 是斷言的預期接收者。

從 IdP 到訂戶以及從訂戶到 RP 的斷言引用的傳送應通過經過身份驗證的受保護通道進行。從 RP 到 IdP 的斷言參考傳送，以及從 IdP 到 RP 的斷言，應透過經過驗證的受保護通道進行。

當提出斷言參考時，IdP 應驗證提出斷言引用的一方與請求身份驗證的一方是同一方。 IdP 可以透過要求 RP 在向 IdP 提供斷言參考時驗證自身身份或透過其他類似方式（請參閱RFC 7636以瞭解一種協定的 RP 識別方法）來實現此目的。

請注意，在第 5.1.4 節中描述的聯合代理中，IdP 受眾將斷言引用和斷言限制為代理，並且代理將任何新建立的斷言引用或斷言限制為下游 RP。

7.2 前台演示#

在前通道模型中，IdP 建立斷言並在身份驗證成功後將其發送給訂閱者。訂閱者通常透過訂閱者瀏覽器內的機制使用該斷言來向 RP 進行身份驗證。

圖 7–2 前置通道演示

在前通道方法中，斷言對於訂閱者是可見的，這可能會導致斷言中包含的系統資訊的洩漏。此外，在此模型中，RP 在提出斷言後向 IdP 查詢附加屬性更加困難。

由於斷言處於訂閱者的控制之下，因此前通道呈現方法還允許訂閱者向非預期方提交單一斷言，可能是透過瀏覽器在多個 RP 重播斷言。即使該斷言受到受眾限制並被非預期 RP 拒絕，其在非預期 RP 上的呈現也可能導致有關訂戶及其線上活動的資訊洩露。儘管可以有意創建一個旨在呈現給多個 RP 的斷言，但這種方法可能會導致對斷言本身的受眾限制寬鬆，進而可能導致跨這些 RP 的訂閱者的隱私和安全漏洞。不建議使用這種多RP。相反，鼓勵 RP 提出自己的個人主張。

RP 應透過使用跨站點腳本保護或其他可接受的技術來保護自己免受製造或捕獲的斷言的注入。

斷言中的元素應由 RP 驗證，包括：

• 頒發者驗證：確保斷言是由預期的 IdP 發出的。
• 簽章驗證：確保斷言的簽章對應於與做出斷言的 IdP 相關的金鑰。
• 時間驗證：確保過期和發佈時間在目前時間戳記的可接受範圍內。
• 受眾限制：確保此 RP 是斷言的預期接收者。

從 IdP 到訂戶以及從訂戶到 RP 的斷言傳送應透過經過驗證的受保護通道進行。

請注意，在第 5.1.4 節中描述的聯合代理中，IdP 受眾將斷言限制為代理，並且代理將任何新建立的斷言限制為下游 RP。

7.3 保護訊息#

IdP 和 RP 之間的通訊應使用經過驗證的受保護通道在傳輸過程中受到保護。訂閱者與 IdP 或 RP（通常透過瀏覽器）之間的通訊應使用經過驗證的受保護通道進行。

請注意，IdP 可能有權存取對 RP 執行安全性原則有用的資訊，例如裝置身份、位置、系統運作狀況檢查和組態管理。如果是這樣，在第 9.2 節中描述的訂戶隱私偏好範圍內將此資訊傳遞給 RP 可能是個好主意。

有關使用者的其他屬性可以包含在斷言本身之外，作為從 RP 到 IdP 的單獨授權請求的一部分。存取這些屬性的授權可以與斷言本身一起發布。以這種方式分割使用者資訊有助於保護使用者隱私，並允許在身份驗證斷言本身的基本資訊之上有限地公開識別屬性。

在可行的情況下，RP 應請求屬性引用而不是第 9.3 節中所述的完整屬性值。 IdP 應支援屬性參考。

8.1 聯邦威脅#

與非聯邦身份驗證一樣，攻擊者的動機通常是獲得對 RP 提供的資源或服務的存取（或更高層級的存取）。攻擊者也可能嘗試冒充訂閱者。流氓或受損的 IdP、RP、使用者代理（例如瀏覽器）以及典型聯邦事務之外的各方都是潛在的攻擊者。為了完成攻擊，他們可能攔截或修改斷言和斷言引用。此外，兩個或更多實體可能試圖透過直接損害斷言資料的完整性或機密性來破壞聯邦協議。就這些類型的威脅而言，任何試圖超越其特權的授權方都被視為攻擊者。

在某些情況下，訂閱者會收到一些秘密訊息，以便 RP 能夠識別他們。瞭解此資訊可以將訂戶與希望冒充他們的攻擊者區分開來。在金鑰持有者斷言的情況下，可以在啟動聯邦協定之前與 IdP 建立此秘密。

表8–1 聯邦威脅

8.2 聯邦威脅緩解策略#

表8–2的列表有助於解除上述威脅的機制。

表8–2 共享威脅

9.1 最小化追蹤與分析#

聯邦為 RP 和訂閱者提供了許多好處，但要求訂閱者信任聯邦參與者。第 5 節、第 5.1.4 節和第 6.3節涵蓋了許多技術要求，其目的是最大限度地減少因追蹤和分析訂戶能力增強而產生的隱私風險。例如，使用相同 IdP 向多個 RP 進行驗證的訂閱者允許 IdP 建立訂閱者事務的設定檔案，而如果沒有聯邦，則該設定檔不會存在。此類數據的可用性使其容易受到訂戶可能未預期或期望的使用的影響，並可能阻礙訂戶採用聯邦服務。

第 5.2 節要求IdP 使用措施來維持可預測性（使個人、所有者和運營商能夠對PII 及其透過資訊系統的處理進行可靠假設）和可管理性（提供對PII 進行精細管理的能力，包括更改、刪除的能力）的目標和選擇性披露）與出於身份證明、身份驗證、授權或屬性斷言、相關欺詐緩解或遵守法律或法律程序以外的目的處理屬性可能產生的隱私風險相當[ NISTIR8062 ] 。

IdP 可能具有處理屬性的各種業務目的，包括向訂閱者提供非身份識別服務。然而，當個人不期望或不適應額外的處理時，出於與原始收集目的不同的目的處理屬性可能會產生隱私風險。 IdP 可以根據額外處理產生的隱私風險來確定適當的措施。例如，在缺乏適用的法律、法規或政策的情況下，在處理屬性以提供訂閱者請求的非身份服務時可能不需要獲得同意，儘管通知可以幫助訂閱者保持有關處理的可靠假設（可預測性）。對屬性的其他處理可能會帶來不同的隱私風險，需要獲得同意或允許訂閱者更好地控制特定屬性的使用或揭露（可管理性）。訂閱者的同意必須是有意義的；因此，當 IdP 確實使用同意措施時，他們不能將訂閱者接受額外使用作為提供身份識別服務的條件。

如果對提議的處理是否超出允許的處理範圍或適當的隱私風險緩解措施有疑問，請諮詢 SAOP。

第 5.2 節還鼓勵使用技術措施來提供可分離性（允許在不與超出系統操作要求的個人或設備關聯的情況下處理 PII 或事件）並防止訂閱者活動追蹤和分析NISTIR8062。技術措施（例如第 5.1.4 節中關於代理聯邦的技術措施和第 6.3 節中關於成對假名標識符的技術措施）可以透過使追蹤或分析超出操作要求的訂戶變得更加困難來提高策略的有效性。

9.2 通知和同意#

為了建立訂閱者對聯邦的信任，訂閱者需要能夠對其資訊的處理方式做出可靠的假設。例如，訂閱者瞭解將傳輸哪些資訊、交易的哪些屬性是必需的以及可選的，以及能夠決定是否將可選屬性傳輸到 RP 是有幫助的。因此，第 7 節要求在將有關訂戶的任何屬性傳輸到任何 RP 之前獲得訂戶的肯定確認。在確定一組 RP 何時應共享公共的成對假名標識符（如第 6.3.2 節中所述）時，IdP 會考慮訂戶對此類RP 分組的理解以及通知在協助這種理解中的作用。有效的通知將考慮使用者體驗設計標準和研究，以及對資訊處理可能產生的隱私風險的評估。有多種因素需要考慮，包括訂戶可能對聯邦中涉及的不同實體的處理和角色的假設的可靠性。然而，大量訂閱者沒有閱讀或理解的複雜、法律隱私政策或一般條款和條件的連結絕不是有效的通知。

第 7 條沒有具體規定哪一方應提供通知。在某些情況下，聯邦中的一方可能無法與訂戶直接連接以提供通知並獲得同意。儘管多方可以選擇提供通知，但各方可以透過合約或透過信任框架政策提前確定哪一方將提供通知並獲得確認，只要該確定是基於以下因素：使訂閱者能夠關注該通知並做出明智的選擇。

如果 IdP 使用第 4.2 節中所述的 RP 白名單，則在身份驗證事務期間，該清單上的任何 RP 都不會呈現給訂閱者。由於IdP 不會在執行時向訂閱者提供通知，因此IdP 會將其列入白名單的RP 清單提供給訂閱者，以便訂閱者可以看到白名單上的哪些RP 可以在身份驗證事務中存取訂閱者的哪些屬性。由於 IdP 無法在涉及訂戶的身份驗證事務之外與列入白名單的 RP 共享訂戶的身份驗證資訊或屬性（請參閱第 5.2 節），因此IdP 清單中RP 的存在並不表明訂戶的資訊將被共享。但是，如果訂閱者使用 IdP 登入任何列入白名單的 RP，則指示的屬性將作為身份驗證事務的一部分進行共用。

如果訂閱者的執行時間決策由 IdP 儲存以方便將來的事務，則 IdP 還需要允許訂閱者查看和撤銷先前在執行時間決策期間批准的任何 RP。此清單包含有關哪些屬性已獲得批准的資訊。

9.3 數據最小化#

聯邦使暴露給 RP 的資料最小化，從而增強了訂戶的隱私。儘管 IdP 可能會收集超出 RP 其用例所需的其他屬性，但 IdP 只會傳輸 RP 明確請求的那些屬性。在某些情況下，RP 不需要屬性的完整值。例如，RP 可能需要知道訂戶是否超過 13 歲，但不需要完整的出生日期。為了最大限度地減少潛在敏感 PII 的收集，RP 可以請求屬性參考（例如，問題：訂戶是否超過 13 歲？答案：Y/N 或通過/失敗）。這可以最大限度地減少 RP 收集的潛在敏感和不必要的 PII。因此，第 7.3 節要求 RP 在可行的情況下請求屬性引用而不是完整的屬性值。為了支援此 RP 要求，IdP 又需要支援屬性參考。

9.4 特定機構的隱私合規性#

第 5.2 節確定了機構要求諮詢其 SAOP 以確定隱私合規要求。讓該機構的SAOP 參與數位認證系統開發的最早階段，以評估和減輕隱私風險，並就合規義務向該機構提供建議，例如聯邦是否觸發1974 年隱私法或2002 年電子化政府法要求，這一點至關重要進行 PIA。例如，如果該機構在聯邦中充當 IdP，則很可能會觸發《隱私法》要求，並要求新的或現有的《隱私法》記錄系統覆蓋，因為憑證將由 IdP 代表維護與其聯邦的任何 RP。但是，如果該機構是 RP 並且使用第三方 IdP，則數位身份驗證可能不會觸發《隱私法》的要求，具體取決於從 RP 傳遞的資料由該機構作為 RP 維護（在這種情況下，機構可能有更廣泛的程序化SORN 來涵蓋此類數據）。

SAOP 可以類似地協助該機構確定是否需要 PIA。這些注意事項不應被視為制定單獨使用聯邦憑證的隱私法 SORN 或 PIA 的要求。在許多情況下，起草包含整個數位身份驗證流程的 PIA 和 SORN 是最有意義的，或者將數位身份驗證流程作為更大的程序化 PIA 的一部分，討論機構正在建立線上存取的計劃或好處。

由於數位身份驗證包含許多組件，因此 SAOP 瞭解和理解每個單獨的組件非常重要。例如，其他隱私權工件可能適用於提供或使用聯邦 IdP 或 RP 服務的機構，例如資料使用協定、電腦配對協定等。此外，對數位身份驗證各個組成部分的透徹理解將使 SAOP 能夠透過合規流程或其他方式徹底評估和減輕隱私風險。

9.5 代理聯邦中的致盲#

雖然某些代理結構（通常主要是為了簡化整合而存在的代理結構）可能無法提供額外的訂戶隱私保護，但其他代理結構透過一系列致盲技術為訂戶提供不同程度的隱私。隱私策略可以規定IdP、RP和聯邦代理程式對訂戶屬性和認證事務資料（例如，最終IdP和RP的身份）的適當使用。諸如盲法之類的技術手段可以透過使數據更難以取得來提高這些政策的有效性。隨著致盲程度的增加，技術和操作實施的複雜性可能會增加。代理需要將交易對應到任何一方的適當各方，並管理交易中所有各方的金鑰。

即使使用盲技術，盲方仍然可以透過發佈的屬性資料或元資料（例如透過對時間戳記、屬性包大小或屬性簽署者資訊的分析）來推斷受保護的訂戶資訊。 IdP 可以考慮其他隱私增強方法，以降低洩露參與聯邦的實體的身份資訊的風險。

下表說明了代理聯邦中使用的一系列致盲實作。表格僅供說明之用，既不全面也不特定於技術。

表 9–1 聯邦代理

10.1 一般可用性注意事項#

聯邦身份系統應該：

• 最大限度地減少使用者負擔（例如，挫折感、學習曲線）
  ○ 最大限度地減少所需的使用者操作數量。
  ○ 允許使用者使用單一 IdP 在多個帳戶中快速輕鬆地進行選擇。例如，帳戶選擇器等方法允許使用者從他們最近訪問過的帳戶清單中進行選擇，而不是透過從潛在 IdP 清單中選擇其 IdP 來啟動聯邦過程。
  ○ 平衡最小化使用者負擔與提供足夠資訊以使用戶做出明智決策的需求。
• 盡量減少使用不熟悉的技術術語和細節（例如，如果基本概念明確解釋，使用者不需要瞭解術語 IdP 和 RP）。
• 努力在 IdP 和 RP 中實現一致且整合的使用者體驗。
• 透過提供使用者圖形、插圖、常見問題、教學和範例等資源，幫助使用者建立對身份的理解。資源應解釋如何處理使用者資訊以及交易各方（例如 RP、IdP 和經紀人）如何相互關聯。
• 提供使用者清晰、誠實且有意義的溝通（即溝通應明確且易於理解）。
• 為使用者提供獨立於位置和設備的線上服務。
• 向使用者明確信任關係，以促進明智的信任決策。信任關係通常是動態的並且依賴於上下文。使用者可能比其他人更有可能信任具有某些屬性或交易的某些 IdP 和 RP。例如，使用者可能會更猶豫是否在包含有價值的個人資訊（例如財務或健康）的網站上使用聯邦身份識別系統。根據對使用者個人資料的感知敏感性，使用者可能不太願意將社交網路供應商視為 IdP，因為人們通常擔心社交網路實現的廣播性質。
• 對於任何面向使用者的資訊，請遵循SP 800–63A 第 9 節中指定的可用性注意事項。
• 清楚地傳達如何以及在哪裡獲得技術援助。例如，向使用者提供線上自助服務功能連結、聊天會話或幫助台支援電話號碼等資訊。避免在交易方（例如 RP、IdP 和經紀人）之間來回重新導向使用者以獲得技術協助。
• 在適當的環境中與代表性使用者和實際任務一起執行全面和持續的可用性評估，以確保從使用者的角度來看聯邦身份系統的成功。

10.2 具體可用性考量因素#

本節討論聯邦身份識別系統已確定的特定可用性注意事項。本節並非試圖詳盡介紹與聯邦身份系統相關的所有可用性因素。相反，它關注可用性文獻中更大、更普遍的主題，主要是使用者對身份、使用者採用、信任和聯邦身份空間的看法的看法。在某些情況下，提供了實施範例。但沒有規定具體的解決方案。所提到的實施是鼓勵創新技術方法來滿足特定可用性需求的範例。有關其他範例，請參閱系統設計和編碼標準、規範、API 和當前最佳實踐（例如 OpenID 和 OAuth）。實施對許多因素很敏感，這些因素阻礙了一刀切的解決方案。

10.2.1 使用者對線上身份的看法#

即使使用者熟悉聯邦身份識別系統，聯邦身份也有不同的方法（特別是在隱私和資訊共享方面），這使得有必要對如何處理使用者資料建立可靠的期望。使用者和實施者有不同的身份概念。使用者將身份視為登入並存取自己的私人空間。實施者根據身份驗證器和斷言、保證等級以及提供服務所需的一組身份屬性來考慮身份。鑑於使用者和實施者的身份概念之間存在脫節，因此在應用於聯邦身份系統時幫助使用者形成準確的身份概念至關重要。良好的身份模型為使用者提供了瞭解聯邦系統的好處和風險的基礎，並鼓勵使用者採用和信任這些系統。

身份的許多屬性都會影響使用者在聯邦內部和聯邦之間管理身份的方式。就像使用者根據網路空間以外的上下文管理多個身份一樣，使用者必須學會在聯邦環境中管理自己的身份。因此，使用者必須清楚如何使用身份和上下文。應考慮以下因素：

• 為使用者提供必要的上下文和範圍，以便區分不同的使用者角色。例如，使用者是代表自己還是代表他人（例如其僱主）行事。
• 為使用者提供唯一的、有意義的、描述性的識別碼來區分實體。
• 向使用者提供有關資料所有權和有權進行更改的資訊。身份以及與其相關的數據有時可以由多個參與者更新和更改。例如，一些醫療保健數據由患者更新和擁有，而一些數據僅由醫院或醫生的診所更新。
• 為使用者提供輕鬆驗證、檢視和更新屬性的能力。身份和使用者角色是動態的而不是靜態的；它們隨著時間的推移而變化（例如，年齡、健康和財務數據）。更新屬性或做出屬性發布決定的能力可能會也可能不會同時提供。確保使用者更改屬性的過程眾所周知、記錄在案且易於執行。
• 為使用者提供更新資料的方法，即使關聯的實體不再存在。
• 為用戶提供完全刪除其身份的方法，刪除有關其自身的所有資訊，包括交易歷史記錄。考慮可能阻止此類行動的適用審計、法律或政策限制。在某些情況下，完全停用比刪除更合適。
• 為使用者提供清晰、易於找到的網站/應用程式資料保留策略資訊。
• 根據組織的資料存取策略，為使用者提供適當的匿名和假名選項，以及根據需要在此類身份選項之間進行切換的能力。
• 為使用者提供管理每個 IdP 到 RP 連線的方法，包括完全分離以及刪除 RP 對一個或多個屬性的存取。

10.2.2 使用者對信任和利益的看法#

許多因素都會影響使用者對聯邦身份識別系統的採用。與任何技術一樣，使用者可能比其他因素更重視某些因素。使用者在做出技術採用決策之前通常會權衡感知到的效益與風險。 IdP 和 RP 為使用者提供足夠的資訊以使他們能夠做出明智的決策至關重要。信任和信任層級的概念（聯邦身份系統的基本原則）可以推動使用者採用。最後，積極的使用者體驗也可能導致使用者對聯邦的需求增加，從而引發 RP 的採用增加。

本小節主要關注用戶信任以及用戶對收益與風險的看法。

為了鼓勵使用者採用，IdP 和 RP 需要與使用者建立信任，並讓他們瞭解採用的好處和風險。應考慮以下因素：

• 允許使用者控制其資訊揭露並透過適當使用通知來提供明確同意（請參閱 SP 800–63C，第 9.2 節，通知和同意）。平衡通知的內容、大小和頻率對於避免粗心的用戶點擊至關重要。
• 對於屬性共享，請考慮以下事項：
  ○ 為使用者提供一種驗證將共享的屬性和屬性值的方法。遵循良好的安全實務（請參閱第 7 節）。
  ○ 使用戶能夠同意部分屬性列表，而不是全有或全無的方法。即使用戶不同意共享所有資訊，也允許用戶進行某種程度的線上訪問。
  ○ 允許使用者更新對其共享屬性清單的同意。
  ○ 盡量減少向使用者提供不必要的資訊。例如，不要顯示系統產生的屬性（例如成對假名標識符），即使它們作為身份驗證回應的一部分與 RP 共用。
  ○ 最大限度地減少用戶步驟和導航。例如，將屬性同意建置到協定中，這樣它們就不是聯邦事務的外部功能。範例可以在 OAuth 或 OpenID Connect 等標準中找到。
  ○ 提供有效且有效率的補救方法，以便使用者可以從 IdP 聲明的無效屬性資訊中復原（請參閱第 7 節）。
  ○ 最大限度地減少要求使用者同意屬性共享的次數。限制同意請求的頻率可以避免使用者因多次請求共享相同屬性而感到沮喪。
• 收集資訊僅限於有限用途，並盡量減少資訊外洩（請參閱第 9.3 節）。在未經用戶明確同意的情況下，不必要和多餘的資訊收集和揭露或用戶追蹤會削弱用戶信任。例如，僅向使用者要求與目前事務相關的屬性，而不是使用者在 RP 上可能存取或可能不存取的所有可能事務。
• 清晰、誠實地向使用者傳達使用聯邦身份的潛在好處和風險。使用者看重的好處包括節省時間、易於使用、減少管理密碼數量以及提高便利性。

使用者對風險的擔憂可能會對採用聯邦身份系統的意願產生負面影響。用戶可能有信任問題、隱私問題、安全問題和單點故障問題。例如，如果單一 IdP 暫時或永久不可用，使用者可能會擔心失去對多個帳戶的存取權。此外，使用者可能會對學習新的身份驗證過程感到擔憂或困惑。為了促進聯邦身份系統的採用，感知到的好處必須大於感知到的風險。

10.2.3 使用者模型與信念#

使用者的信念和看法使他們傾向於期望某些結果並以某些方式行事。這些信念、看法和傾向在社會科學中被稱為心理模型。例如，人們有一種外出用餐的心理模型，該模型指導他們在每個場所（例如快餐店、自助餐廳和更正式的餐廳）的行為和期望。因此，沒有必要熟悉每個機構來瞭解如何在每個機構中進行適當的互動。

幫助使用者建立良好且完整的聯邦心智模型，使用戶能夠超越單一的特定實現進行概括。如果聯邦身份系統不是從使用者的角度設計的，使用者可能會形成不正確或不完整的心理模型，從而影響他們採用這些系統的意願。應考慮以下因素：

• 清楚解釋交易方（例如 RP、IdP 和經紀人）之間的工作關係和資訊流，以避免使用者誤解。在說明中使用實體的實際名稱，而不是使用通用術語 IdP 和 RP。
  ○ 提供突出的視覺提示和訊息，以便使用者理解為什麼看似不相關的實體具有工作關係。例如，由於缺乏對聯邦身份系統中資訊流的瞭解，用戶可能擔心將線上個人活動與政府服務混合在一起。
  ○ 當 RP 需要將控制權從其網站重新導向到 IdP 時，向使用者提供有關重新導向的突出視覺提示和資訊。例如，在 IdP 使用者介面中顯示 RP 品牌，以通知使用者何時使用其 IdP 登入以存取目標 RP。
• 為使用者提供清晰可用的方式（例如視覺保證）來確定交易方（例如 RP、IdP 和經紀人）的真實性。這也將有助於減輕使用者對將一個網域轉移到另一個網域的擔憂，特別是在根網域發生變化（例如，.gov 變更為 .com）時。例如，顯示 IdP 的 URL，以便使用者可以驗證他們沒有受到惡意網站的網路釣魚。
• 為用戶提供有關隱式登入和明確登出的清晰資訊，包括視覺提示。根據實施情況，使用 IdP 帳戶登入 RP 可能會向 IdP 和 RP 驗證使用者身份。使用者可能沒有意識到，結束與 RP 的會話並不一定會結束與 IdP 的會話；用戶需要明確「註銷」IdP。使用者需要明確的資訊來提醒他們是否需要明確登出才能結束其 IdP 會話。

11.1 安全性斷言標記語言（SAML）#

SAML 是一種基於 XML 的框架，用於透過 Internet 在受信任實體之間建立和交換身份驗證和屬性資訊。截至撰寫本文時，SAML的最新規範是 2005 年 3 月 15 日發布的 SAML v2.0。

SAML 的建置區塊包括：

• 斷言 XML 架構，定義斷言的結構。
• SAML 協議，用於請求斷言和工件（第 7.1 節中描述的間接模型中使用的斷言引用）。
• 綁定，定義底層通訊協定（例如 HTTP 或 SOAP），可用於傳輸 SAML 斷言。

上述三個元件定義了與特定用例（例如「Web 瀏覽器 SSO」）相對應的 SAML 設定檔。

SAML 斷言以 XML 模式進行編碼，最多可以攜帶三種類型的語句：

• 認證語句包括有關斷言發布者、經過認證的訂閱者、有效期限和其他認證資訊的資訊。例如，身份驗證斷言將聲明訂閱者「John」於 2004 年 6 月 6 日晚上 10:32 使用密碼進行了身份驗證。
• 屬性語句包含與訂戶相關的特定附加特徵。例如，主題“John”與值為“Manager”的屬性“Role”相關聯。
• 授權語句標識訂閱者有權存取的資源。這些資源可能包括特定設備、檔案和特定網路伺服器上的資訊。例如，「Webserver1002」上的操作「閱讀」的主題「John」給出了證據「角色」。

授權聲明超出了本文檔的範圍，不再討論。

11.2 Kerberos 票證#

Kerberos 網路驗證服務[RFC 4120]旨在為本地共用網路上使用對稱金鑰加密的用戶端/伺服器應用程式提供強式驗證。 Kerberos 的擴充可以支援在協定的選定步驟中使用公鑰加密。 Kerberos 還支援訂戶和 RP 之間的會話資料的機密性和完整性保護。儘管 Kerberos 使用斷言，但它是為在共享網路上使用而設計的，因此並不是真正的聯合協定。

Kerberos 支援使用一個或多個 IdP 透過不受信任的共用本機網路對訂戶進行驗證。訂閱者透過展示解密 IdP 為訂閱者加密的隨機會話金鑰的能力來隱式向 IdP 進行身份驗證。 （某些 Kerberos 變體還要求訂戶明確向 IdP 進行身份驗證，但這並不通用。）除了加密的會話金鑰之外，IdP 還產生另一個稱為 Kerberos 票證的加密物件。該票證包含相同的會話金鑰、向其頒發會話金鑰的訂戶的身份以及會話金鑰不再有效的到期時間。票證的機密性和完整性受到預先建立的金鑰的保護，該金鑰在明確設定階段在 IdP 和 RP 之間共用。

為了使用會話金鑰進行身份驗證，訂閱者將票證連同加密資料一起傳送到 RP，以證明訂閱者擁有嵌入在 Kerberos 票證中的會話金鑰。會話金鑰用於產生新票證或用於加密和驗證訂戶與 RP 之間的通訊。

要開始這個過程，訂閱者會向身份驗證伺服器 (AS) 發送身份驗證請求。 AS 使用訂戶的長期憑證來加密訂戶的會話金鑰。長期憑證可以是 AS 和訂閱者之間共享的金鑰，也可以是 Kerberos 的 PKINIT 變體中的公鑰憑證。大多數 Kerberos 變體都基於訂閱者和 IdP 之間的共用金鑰，該金鑰是從使用者產生的密碼中衍生出來的。因此，除非使用靈活身份驗證安全隧道 (FAST) [ RFC 6113 ] 或其他一些隧道和防護機制，否則它們很容易受到被動竊聽者的離線字典攻擊。

除了將會話金鑰傳遞給訂閱者之外，AS 還使用與票證授予伺服器 (TGS) 共用的金鑰來頒發票證。此票證稱為票證授予票證 (TGT)，因為驗證者使用 TGT 中的會話金鑰來頒發票證，而不是明確驗證驗證者。 TGS使用TGT中的會話金鑰為訂閱者加密新的會話金鑰，並使用與RP共享的金鑰產生與新會話金鑰對應的票證。訂閱者解密會話金鑰並使用票證和新會話金鑰一起向 RP 進行身份驗證。

當 Kerberos 驗證是基於密碼時，已知該協定容易受到竊聽者捕獲初始使用者與 KDC 交換的離線字典攻擊。較長的密碼長度和複雜性可以在一定程度上緩解此漏洞，但足夠長的密碼對使用者來說往往很麻煩。然而，當在 FAST（或類似）隧道中使用基於 Kerberos 密碼的身份驗證時，還需要成功的中間人攻擊才能執行字典攻擊。

11.3 OpenID 連接#

OpenID Connect [ OIDC ] 是一種互聯網規模的聯合身份和身份驗證協議，建構在 OAuth 2.0 授權框架和 JSON 物件簽署和加密 (JOSE) 加密系統之上。

OpenID Connect 建構在 OAuth 2.0 授權協定之上，使訂閱者能夠授權 RP 存取訂閱者的身份和身份驗證資訊。 OpenID Connect 和 OAuth 2.0 中的 RP 稱為客戶端。

在成功的 OpenID Connect 交易中，IdP 會頒發一個 ID 令牌，它是 JSON Web 令牌 (JWT) 格式的簽章斷言。客戶端解析 ID 令牌以瞭解 IdP 上的訂戶和主要驗證事件。該令牌至少包含以下有關訂閱者和身份驗證事件的資訊：

• iss- 識別發出斷言的 IdP 的 HTTPS URL。
• sub- 代表訂戶的 IdP 特定主題識別碼。
• aud- IdP 特定的受眾標識符，等於 IdP 處客戶端的 OAuth 2.0 用戶端識別符。
• exp- ID 令牌過期的時間戳，在此之後用戶端將不再接受該 ID 令牌。
• iat- 發出 ID 令牌的時間戳記以及用戶端不得接受該 ID 令牌之前的時間戳記。

除了 ID 令牌之外，IdP 還向客戶端頒發 OAuth 2.0 存取令牌，該令牌可用於存取 IdP 處的 UserInfo 端點。此端點傳回 JSON 對象，表示有關訂閱者的一組屬性，包括但不限於訂閱者的姓名、電子郵件地址、實際地址、電話號碼和其他個人資料資訊。雖然 ID 令牌內的資訊反映了身份驗證事件，但 UserInfo 端點中的資訊通常更穩定且可以更通用。從 UserInfo 端點對不同屬性的存取是透過使用一組專門定義的 OAuth 範圍 、openid、profile、email和phone來控制的address。附加範圍offline_access，用於管理刷新令牌的發布，這允許 RP 在訂閱者不存在時存取 UserInfo 端點。對 UserInfo 端點的存取被建構為 API，並且當訂閱者不在場時可以使用。因此，對 UserInfo 端點的存取不足以證明訂閱者的存在並在 RP 上建立經過驗證的會話。