2000 年代，組織快速採用 Web 應用程式和雲端服務，帶來了新的身份驗證挑戰。員工需要存取數十個 SaaS 應用程式——Salesforce、Workday、ServiceNow 等等。每個應用程式都有自己的登入。使用者需要管理多個密碼。IT 部門在配置方面遇到困難。安全團隊擔心憑證氾濫。
Kerberos 和 Windows 整合式身份驗證在企業網路內運作良好，但在跨組織邊界時失效。遠端員工無法使用 Windows 身份驗證。SaaS 供應商沒有與 Active Directory 整合。行動裝置不支援 SPNEGO。企業需要一個新的 SSO 標準，能夠跨網際網路、跨組織、跨平台工作。
安全性判斷提示標記語言（SAML）應運而生。由 OASIS 開發並於 2002 年發布，SAML 實現了聯合身份驗證——組織可以相互信任對方的身份驗證，而無需共享使用者資料庫或憑證。員工可以向其企業身份提供者（IdP）進行一次身份驗證，然後存取數十個外部服務提供者（SP），無需額外登入。
本文深入探討 SAML 的架構、流程、優勢和局限性。理解 SAML 揭示了為什麼它主導企業 SSO 十多年，以及為什麼現代替代方案正在出現。
SAML 基礎
SAML 透過身份提供者和服務提供者之間的信任關係，將身份驗證與應用程式存取分離。
核心實體
SAML 定義了三個主要實體：
🔐 SAML 實體
身份提供者（IdP）
- 驗證使用者身份
- 頒發 SAML 判斷提示
- 管理使用者身份
- 範例：Okta、Azure AD、ADFS
服務提供者（SP）
- 提供應用程式
- 使用 SAML 判斷提示
- 信任 IdP 身份驗證
- 範例：Salesforce、Workday、ServiceNow
使用者（主體）
- 存取應用程式
- 在 IdP 處進行身份驗證
- 將判斷提示傳遞給 SP
- 瀏覽器充當中介
身份提供者處理身份驗證——驗證你是誰。服務提供者信任 IdP 關於你身份的判斷提示。這種分離實現了聯合身份驗證：SP 永遠看不到你的密碼，永遠不管理你的帳戶，也永遠不需要與你的企業目錄整合。IdP 處理所有這些。
SAML 判斷提示
SAML 判斷提示是包含使用者聲明的數位簽章 XML 文件：
📜 SAML 判斷提示類型
身份驗證判斷提示
- 確認使用者身份
- 使用的身份驗證方法
- 身份驗證時間戳記
- 工作階段過期時間
屬性判斷提示
- 使用者屬性（電子郵件、姓名、角色）
- 群組成員資格
- 自訂屬性
- 授權資料
授權決策判斷提示
- 存取權限
- 特定資源授權
- 較少使用
- 通常由應用程式處理
身份驗證判斷提示聲明：「此使用者在此時間使用此方法進行了身份驗證。」屬性判斷提示聲明：「此使用者具有這些屬性。」服務提供者使用這些判斷提示做出存取決策——授予存取權限、分配角色、個人化體驗。
判斷提示由 IdP 使用 XML 簽章進行數位簽章。服務提供者使用 IdP 的公開金鑰驗證簽章，確保判斷提示未被竄改並確實來自受信任的 IdP。
SAML 繫結
SAML 繫結定義了 SAML 訊息的傳輸方式：
🔗 SAML 繫結
HTTP 重新導向繫結
- SAML 訊息在 URL 參數中
- 瀏覽器重新導向
- 訊息大小受限
- 最常用於請求
HTTP POST 繫結
- SAML 訊息在表單欄位中
- 瀏覽器表單提交
- 支援更大訊息
- 最常用於回應
SOAP 繫結
- 直接伺服器到伺服器
- 無瀏覽器參與
- 同步通訊
- 實務中較少使用
成品繫結
- 參考而非完整判斷提示
- 後端擷取
- 減少瀏覽器暴露
- 實作更複雜
HTTP 重新導向和 HTTP POST 繫結在實務中占主導地位。IdP 將瀏覽器重新導向到帶有 SAML 請求的 SP。SP 將瀏覽器重新導向到 IdP 進行身份驗證。IdP 將 SAML 判斷提示發回 SP。瀏覽器充當中介，在 IdP 和 SP 之間傳遞訊息，而不理解其內容。
SAML 架構
SAML 的架構實現了跨組織邊界的聯合身份驗證：
企業 IdP] SP1[服務提供者 A] SP2[服務提供者 B] User -->|存取| Browser Browser <-->|重新導向進行身份驗證| IdP Browser <-->|SAML 判斷提示| SP1 Browser <-->|SAML 判斷提示| SP2 IdP -.->|信任關係| SP1 IdP -.->|信任關係| SP2 style IdP fill:#f96,stroke:#333,stroke-width:3px style Browser fill:#9cf,stroke:#333,stroke-width:2px
瀏覽器充當中介。IdP 和 SP 在身份驗證期間從不直接通訊——所有訊息都透過瀏覽器流動。這種設計跨越防火牆和組織邊界。SP 不需要網路存取 IdP。IdP 不需要提前知道所有 SP。
信任關係透過中繼資料交換建立。IdP 發布包含其公開金鑰和端點的中繼資料。SP 匯入此中繼資料，建立信任。SP 發布包含其端點和要求的中繼資料。IdP 匯入此中繼資料，實現聯合身份驗證。
SAML 身份驗證流程
SAML 支援兩種主要身份驗證流程：SP 發起和 IdP 發起。
SP 發起流程
SP 發起流程從應用程式開始：
詳細流程：
🔄 SP 發起流程步驟
1. 使用者存取應用程式
- 使用者點擊連結或輸入 URL
- 瀏覽器請求受保護資源
- SP 偵測到未驗證使用者
2. SP 產生 SAML 請求
- 建立 AuthnRequest XML
- 包含 SP 識別碼
- 指定所需屬性
- 簽章請求（選用）
3. 瀏覽器重新導向到 IdP
- SP 將瀏覽器重新導向到 IdP
- SAML 請求在 URL 或表單中
- 包含 RelayState（返回 URL）
4. 使用者在 IdP 處進行身份驗證
- IdP 檢查現有工作階段
- 如果需要，顯示登入頁面
- 使用者提供憑證
- IdP 驗證憑證
5. IdP 產生 SAML 判斷提示
- 建立判斷提示 XML
- 包含使用者身份
- 新增屬性聲明
- 使用私密金鑰簽章判斷提示
6. 瀏覽器將判斷提示傳送到 SP
- IdP 將瀏覽器重新導向到 SP
- 判斷提示在表單欄位中
- 包含 RelayState
7. SP 驗證判斷提示
- 使用 IdP 公開金鑰驗證簽章
- 檢查過期時間
- 驗證對象限制
- 擷取使用者身份和屬性
8. SP 授予存取權限
- 建立本機工作階段
- 重新導向到原始資源
- 使用者存取應用程式
SP 發起流程提供最佳使用者體驗。使用者直接為應用程式 URL 新增書籤。他們從電子郵件中點擊連結。他們從想要使用的應用程式開始。應用程式在需要時處理重新導向以進行身份驗證。
IdP 發起流程
IdP 發起流程從入口網站開始：
🔄 IdP 發起流程步驟
1. 使用者在 IdP 入口網站進行身份驗證
- 使用者存取 IdP 入口網站
- 進行一次身份驗證
- 檢視可用應用程式清單
2. 使用者點擊應用程式連結
- 從入口網站選擇應用程式
- IdP 知道 SP 端點
3. IdP 產生 SAML 判斷提示
- 為選定的 SP 建立判斷提示
- 包含使用者身份和屬性
- 簽章判斷提示
4. 瀏覽器將判斷提示傳送到 SP
- IdP 將瀏覽器重新導向到 SP
- 判斷提示在表單欄位中
5. SP 驗證判斷提示
- 驗證簽章
- 檢查過期時間
- 驗證對象
6. SP 授予存取權限
- 建立本機工作階段
- 使用者存取應用程式
IdP 發起流程適用於基於入口網站的存取。使用者在入口網站進行一次身份驗證，然後點擊連結存取多個應用程式，無需額外登入。此流程更簡單——沒有 SAML 請求，沒有 RelayState 管理。但是，它不太靈活。使用者無法直接為應用程式 URL 新增書籤。他們必須始終從入口網站開始。
流程比較
🎯 選擇 SAML 流程
使用 SP 發起流程當：
- 使用者為應用程式 URL 新增書籤
- 需要深度連結
- 更好的使用者體驗
- 標準 SAML 流程
使用 IdP 發起流程當：
- 基於入口網站的存取模型
- 實作更簡單
- 受控應用程式清單
- 舊版 SP 要求
最佳實務：
- 支援兩種流程
- 預設使用 SP 發起
- 提供入口網站以方便使用
- 讓使用者選擇
大多數現代實作支援兩種流程。SP 發起提供更好的使用者體驗。IdP 發起提供更簡單的實作。支援兩者為使用者提供靈活性。
SAML 實務
SAML 透過廣泛採用成為主導的企業 SSO 標準。
企業採用
組織部署 SAML 為員工提供對 SaaS 應用程式的無縫存取：
✅ SAML 企業用例
員工存取 SaaS
- 單一身份驗證點
- 存取數十個應用程式
- 集中配置
- 簡化存取管理
合作夥伴聯合身份驗證
- 授予合作夥伴有限存取權限
- 無共享憑證
- 受控權限
- 稽核追蹤
客戶聯合身份驗證（B2B）
- 客戶組織驗證使用者
- 服務提供者信任客戶 IdP
- 無密碼管理
- 可擴充的多租戶存取
學術聯合身份驗證
- Shibboleth 實作
- 研究協作
- 圖書館資源存取
- 跨機構 SSO
典型的企業部署如下：IT 部署 IdP（Okta、Azure AD 或 ADFS）。他們為每個 SaaS 應用程式設定 SAML 聯合身份驗證。員工向 IdP 進行一次身份驗證，然後存取所有應用程式，無需額外登入。IT 集中管理存取——配置新員工、取消離職員工、執行安全性原則。
真實案例
考慮一家擁有 5,000 名員工使用 50 個 SaaS 應用程式的公司：
🏢 企業 SAML 部署
SAML 之前
- 每位員工 50 個密碼
- 總共 250,000 個憑證
- 服務台被重設請求淹沒
- 存取控制不一致
- 稽核追蹤缺口
- 安全性漏洞
SAML 之後
- 每個工作階段一次身份驗證
- 集中存取控制
- 自動配置
- 完整稽核追蹤
- 減少服務台工單
- 改善安全性態勢
實作
- Okta 作為 SAML IdP
- 與每個 SaaS 應用程式的 SAML 聯合身份驗證
- 員工入口網站用於應用程式存取
- 透過 SCIM 自動配置
- IdP 處的 MFA
- 執行工作階段原則
轉變是巨大的。員工進行一次身份驗證即可存取所有內容。IT 在一個地方配置存取。安全性得到改善，因為身份驗證透過強控制集中化。服務台工單減少，因為密碼重設在一個地方進行。稽核追蹤得到改善，因為所有身份驗證都透過 IdP。
供應商支援
SAML 的成功來自廣泛的供應商支援：
✅ SAML 生態系統
身份提供者
- Okta
- Azure Active Directory
- ADFS（Active Directory 聯合服務）
- Ping Identity
- OneLogin
服務提供者
- Salesforce
- Workday
- ServiceNow
- Box
- Slack
- 數千個 SaaS 應用程式
開放原始碼
- Shibboleth
- SimpleSAMLphp
- OpenSAML
- 所有語言的 SAML 函式庫
幾乎每個企業 SaaS 應用程式都支援 SAML。這種無處不在的支援使 SAML 成為企業 SSO 的預設選擇。組織可以部署一個 IdP 並與所有應用程式聯合。
SAML 優勢
SAML 成功是因為它解決了實際問題：
✅ SAML 優勢
企業就緒
- 成熟、廣為理解的協定
- 廣泛的供應商支援
- 大規模驗證
- 強大的安全性屬性
聯合身份驗證能力
- 跨組織邊界工作
- 無共享憑證
- 去中心化架構
- 信任關係
安全性功能
- 數位簽章
- 加密支援
- 判斷提示過期
- 對象限制
- 重播保護
靈活性
- 多種繫結
- 屬性交換
- 自訂屬性
- 可擴充框架
SAML 的數位簽章提供強大的安全性。SP 驗證判斷提示確實來自受信任的 IdP 且未被竄改。加密保護敏感屬性。過期防止重播攻擊。對象限制確保判斷提示僅由預期接收者使用。
協定的靈活性支援多樣化的用例。組織可以交換自訂屬性。他們可以為不同場景實作不同的繫結。他們可以根據特定需求擴充協定。
SAML 局限性
儘管廣泛採用，SAML 仍有顯著局限性：
技術複雜性
SAML 基於 XML 的設計帶來複雜性：
🚫 SAML 技術挑戰
XML 冗長
- 冗長的訊息格式
- 需要複雜的剖析
- 訊息大小大
- 難以偵錯
設定複雜性
- 需要中繼資料交換
- 憑證管理
- 端點設定
- 繫結選擇
偵錯困難
- XML 剖析錯誤
- 簽章驗證失敗
- 憑證問題
- 錯誤訊息不清楚
開發者體驗
- 學習曲線陡峭
- 複雜的函式庫
- 工具有限
- 整合耗時
典型的 SAML 判斷提示有數百行 XML。偵錯需要理解 XML 命名空間、XML 簽章和 SAML 特定元素。憑證管理容易出錯——過期的憑證會悄無聲息地破壞聯合身份驗證。設定需要交換中繼資料、設定端點和測試多個流程。
開發人員經常在 SAML 整合方面遇到困難。協定複雜。錯誤訊息晦澀。偵錯工具有限。本應是簡單的 SSO 整合變成了多週專案。
行動和 API 局限性
SAML 是為基於瀏覽器的流程設計的：
🚫 SAML 行動/API 挑戰
瀏覽器依賴
- 需要瀏覽器重新導向
- 行動應用程式體驗差
- 需要嵌入式瀏覽器
- 工作階段管理問題
API 授權
- 不是為 API 設計的
- 無基於權杖的存取
- 判斷提示不適合 API 呼叫
- 需要工作階段 cookie
行動應用程式問題
- 重新導向流程破壞應用程式體驗
- 嵌入式瀏覽器安全性問題
- 工作階段持續性問題
- 平台特定挑戰
行動應用程式在 SAML 方面遇到困難。重新導向流程需要開啟瀏覽器、進行身份驗證，然後返回應用程式。這破壞了使用者體驗。嵌入式瀏覽器（WebView）帶來安全性問題——應用程式可以攔截憑證。跨應用程式和瀏覽器的工作階段管理很複雜。
API 無法有效使用 SAML。SAML 判斷提示是為基於瀏覽器的身份驗證設計的，而不是 API 授權。API 需要可以包含在 HTTP 標頭中的權杖。SAML 提供建立瀏覽器工作階段的判斷提示。這種不匹配是根本性的。
使用者體驗問題
SAML 的重新導向密集流程帶來使用者體驗問題：
🚫 SAML 使用者體驗挑戰
重新導向開銷
- 每次身份驗證多次重新導向
- 身份驗證流程緩慢
- 使用者可見
- 對非技術使用者造成困惑
登出複雜性
- 單點登出難以實作
- 登出行為不一致
- 登出後工作階段持續存在
- 安全性影響
工作階段管理
- 多個工作階段（IdP + SP）
- 不同的工作階段生命週期
- 工作階段同步問題
- 逾時不一致
錯誤處理
- 錯誤訊息不清楚
- 使用者看到 XML 錯誤
- 難以排查
- 支援負擔
使用者在身份驗證期間看到多次重新導向。瀏覽器在 SP 和 IdP 之間跳轉。這令人困惑且緩慢。登出更糟——從一個應用程式登出不會從其他應用程式登出。使用者認為他們已登出，但工作階段仍然存在。這帶來安全性風險。
SAML 與現代替代方案
SAML 主導企業 SSO 十多年，但現代替代方案出現了：
SAML 與 OpenID Connect
OpenID Connect（OIDC）解決了許多 SAML 局限性：
🎯 SAML 與 OIDC 比較
SAML 優勢
- 成熟、經過驗證的協定
- 廣泛的企業支援
- 現有基礎設施
- 監管接受度
OIDC 優勢
- JSON 而非 XML
- RESTful API
- 行動友善
- 內建 API 授權
- 更好的開發者體驗
- 現代架構
決策因素
- 舊版應用程式支援 → SAML
- 新開發 → OIDC
- 行動應用程式 → OIDC
- API 授權 → OIDC
- 供應商要求 → 可能決定選擇
OIDC 使用 JSON 而非 XML，使其更簡單、更開發者友善。OIDC 與行動應用程式和 API 配合良好。OIDC 在一個協定中結合了身份驗證和授權。對於新開發，OIDC 通常是更好的選擇。
然而，SAML 不會消失。太多企業應用程式依賴它。許多組織同時執行兩種協定——SAML 用於舊版應用程式，OIDC 用於新開發。大多數現代 IdP 支援兩種協定，實現逐步遷移。
何時選擇 SAML
SAML 在特定場景中仍然是正確的選擇：
🎯 選擇 SAML 當
舊版整合
- 應用程式僅支援 SAML
- 現有 SAML 基礎設施
- 遷移成本過高
- 監管要求
企業要求
- 供應商強制要求 SAML
- 合規標準指定 SAML
- 現有聯合身份驗證協定
- 僅瀏覽器存取
特定用例
- 學術聯合身份驗證（Shibboleth）
- 政府系統
- 醫療保健（HIPAA 要求）
- 金融服務
如果你的 SaaS 供應商僅支援 SAML，你就使用 SAML。如果你的合規要求強制要求 SAML，你就使用 SAML。如果你有執行良好的現有 SAML 基礎設施，你就繼續使用 SAML。該協定有效——只是不適合現代用例。
安全性最佳實務
安全地實作 SAML 需要注意細節：
判斷提示驗證
正確的判斷提示驗證至關重要：
⚠️ SAML 判斷提示驗證
必需檢查
- 驗證數位簽章
- 檢查判斷提示過期
- 驗證頒發者
- 驗證對象限制
- 檢查接收者
- 驗證 NotBefore/NotOnOrAfter
常見錯誤
- 跳過簽章驗證
- 忽略過期
- 不檢查對象
- 接受任何頒發者
- 不驗證就信任判斷提示內容
每個判斷提示都必須驗證。使用 IdP 的公開金鑰驗證數位簽章。檢查判斷提示是否未過期。驗證頒發者是否與你信任的 IdP 相符。檢查對象限制是否與你的 SP 識別碼相符。跳過任何這些檢查都會帶來安全性漏洞。
憑證管理
SAML 依賴憑證進行簽章：
⚠️ SAML 憑證管理
最佳實務
- 監控憑證過期
- 自動化續訂流程
- 支援多個憑證
- 測試憑證輪替
- 記錄憑證位置
常見問題
- 過期的憑證破壞聯合身份驗證
- 手動續訂流程容易出錯
- 無監控警示
- 未測試輪替
- 遺失私密金鑰
憑證過期是最常見的 SAML 故障。憑證過期，聯合身份驗證中斷，使用者無法存取應用程式。實作監控以在過期前發出警示。盡可能自動化續訂。支援多個憑證以實現平滑輪替。在生產中需要之前測試輪替流程。
工作階段安全性
SAML 工作階段需要仔細管理：
⚠️ SAML 工作階段安全性
工作階段生命週期
- 合理的工作階段持續時間
- 閒置逾時執行
- 絕對逾時限制
- 敏感操作需要重新身份驗證
登出實作
- 實作單點登出
- 清除所有工作階段
- 使判斷提示無效
- 重新導向到安全頁面
工作階段固定
- 身份驗證後產生新工作階段 ID
- 不接受來自 URL 的工作階段 ID
- 使用安全工作階段 cookie
- 實作 CSRF 保護
工作階段應具有合理的生命週期——足夠長以保證可用性，足夠短以保證安全性。實作閒置逾時。敏感操作需要重新身份驗證。正確實作單點登出——清除 IdP 工作階段和所有 SP 工作階段。透過在身份驗證後產生新工作階段 ID 來防止工作階段固定。
結論
SAML 實現了跨組織邊界的企業 SSO，解決了基於瀏覽器的應用程式的密碼氾濫問題。該協定透過數位簽章判斷提示將身份驗證（IdP）和應用程式存取（SP）分離，提供了強大的安全性並實現了大規模聯合身份驗證。
SAML 成功是因為它解決了實際問題。組織需要為數十個 SaaS 應用程式提供集中身份驗證。員工需要無縫存取，無需密碼疲勞。IT 需要簡化配置和存取管理。SAML 提供了這些好處，成為主導的企業 SSO 標準。
然而，SAML 基於 XML 的設計、以瀏覽器為中心的流程和設定複雜性揭示了其年代。行動應用程式在重新導向流程方面遇到困難。API 無法有效使用 SAML 判斷提示。開發人員發現整合困難。OpenID Connect 等現代替代方案透過 JSON、RESTful API 和更好的行動支援解決了這些局限性。
SAML 不會消失——太多企業應用程式依賴它。但新開發應考慮 OIDC，以獲得更好的開發者體驗、行動支援和 API 授權。許多組織同時執行兩種協定，SAML 用於舊版整合，OIDC 用於新開發。
實作 SAML 時，專注於安全性基礎：正確驗證判斷提示、仔細管理憑證、實作安全工作階段處理。這些實務可防止常見漏洞並確保可靠的聯合身份驗證。
SAML 和現代替代方案之間的選擇取決於你的環境。舊版應用程式整合需要 SAML。新開發受益於 OIDC。行動應用程式需要 OIDC。基於瀏覽器的企業應用程式與兩者都配合良好。根據你的要求選擇，而不是協定偏好。
SAML 代表了身份驗證的關鍵演變——從基於網路的協定到網際網路規模的聯合身份驗證。理解 SAML 的優勢和局限性有助於你就身份驗證架構做出明智決策。無論你選擇 SAML 還是現代替代方案，目標都是相同的：實現業務目標的安全、可用的身份驗證。