從昨天之後，我們已經學到以下知識：

• SAML 的基礎（Day 21）：它是基於 XML 的身分驗證標準。
• SAML vs OIDC（Day 22）：SAML 偏向企業 SSO，OIDC 偏向現代 Web/App。

今天要解釋的是：如果要在 Spring Boot 中整合 SAML，應用（Service Provider, SP）要準備什麼？與 IdP 怎麼對接？

什麼是 Spring Security SAML？

Spring Security 本身以 OAuth2 / OIDC 支援最完整，但 SAML 也能整合，常見做法有兩種：

1. Spring Security SAML Extensions
   • Spring 官方早期提供的擴展，能讓 Spring 應用充當 SAML SP（Service Provider）。
   • 雖然更新頻率不高，但在企業場景仍廣泛使用。
2. 第三方整合庫（例如 Spring SAML2 Service Provider 支援）
   • Spring Security 5.2 起逐步提供 原生 SAML 2.0 SP 支援。
   • 功能：與 IdP 交換 Metadata、處理 SAML Response、驗證簽章、建立 SecurityContext。

SP 與 IdP 對接需要哪些元素？

在 SAML 世界裡，SP 與 IdP 要「互相交換 Metadata」，才能建立信任關係。

1. SP（你的 Spring 應用）需要準備：

• EntityID：你的應用在 SAML 中的唯一識別（通常是一個 URL）。
• Assertion Consumer Service (ACS) URL：IdP 登入成功後要回傳 SAML Response 的網址（通常類似 /saml2/authenticate/{registrationId}）。
• Metadata XML：描述你的 SP 設定，包括 ACS URL、EntityID、公開金鑰等。

2. IdP（例如 Okta, ADFS, Azure AD）需要準備：

• SSO URL：你的應用需要導向這個網址，才能觸發 IdP 登入。
• IdP EntityID：IdP 的唯一識別。
• X.509 憑證：用來驗證 IdP 簽署的 SAML Response。
• Metadata XML：完整描述 IdP 的設定（包含上述資訊）。

SAML 登入流程

1. 使用者請求受保護資源
   • 例如 /dashboard。
2. SP（你的應用）發出 AuthnRequest
   • Spring Security 自動生成一份 XML，透過瀏覽器重導到 IdP。
3. IdP 驗證使用者
   • 使用者輸入公司帳密，或如果已經登入過，直接通過。
4. IdP 回傳 SAML Response
   • 包含 Assertion（使用者身分屬性，如 Email、Name、Role）。
   • Response 由 IdP 簽名並 POST 回 SP 的 ACS URL。
5. Spring Security 驗證 Response
   • 檢查簽章、NotBefore/NotOnOrAfter 時效。
   • 驗證成功後，將使用者資訊封裝成 Authentication，存入 SecurityContext。
6. 使用者成功登入
   • 之後請求 API 時，應用能直接拿到使用者屬性（通常是 Email / 部門 / Role）。

Spring Security 配置思路

Spring Boot 配合 Spring Security SAML，常見需要配置：

• application.yml / application.properties
  • 註冊 SAML Relying Party（SP）
  • 指定 IdP Metadata（通常是一個 URL 或 XML 檔案）
  • 定義 SP 的 EntityID、ACS URL
• SecurityFilterChain
  • 啟用 .saml2Login() 取代 .oauth2Login()
  • 保護路徑：哪些要登入才能進入
• 憑證管理
  • 驗證 IdP 的簽章憑證（通常在 Metadata 中）
  • SP 也要有自己的金鑰（供 IdP 建立信任關係）

與 OIDC 的不同點

• OIDC：只要設定 issuer-uri，Spring Security 會自動 Discovery → 取得金鑰與端點 → 幫你處理 Token。
• SAML：沒有 Discovery，需要手動交換 Metadata XML。
• OIDC：ID Token 是 JWT（輕量），驗證簡單。
• SAML：Response 是 XML（重量級），必須做 XML 簽章驗證。

實際案例介紹

假設你的公司要把 Spring Boot 應用接入 Okta：

1. 在 Okta 建立一個 SAML Application，下載它的 Metadata XML。
2. 在你的 Spring Boot application.yml 中設定：
   • SP EntityID
   • ACS URL
   • IdP Metadata 位置（本地檔案或 URL）
3. 啟用 .saml2Login()。
4. 使用者訪問 /me → 被導向 Okta → 登入 → Okta 回傳 Assertion → Spring Security 驗證後登入成功。

一日小結

今天我們了解了 Spring Security 與 SAML 整合的觀念：

• Spring Security 可以扮演 SAML SP。
• SP 與 IdP 必須交換 Metadata，建立信任關係。
• 登入流程：SP AuthnRequest → IdP Response → 驗證 Assertion → 建立 Session。
• 與 OIDC 不同，SAML 沒有 Discovery，需要手動設定。

看到這裡，相信大家已經更加了解SAML的知識，雖然因為SAML比較複雜，這次30天並沒有實際展示，但我相信大家可以把這個當作是挑戰題，利用剛剛教的知識去實作SAML。

到這裡，所有關於驗證的歷史，驗證的技術演練就到這裡了，在這裡要恭喜大家，已經走過了資安近幾十年來的巨大演變，也實作了一些驗證與加密的技術，真的是非常的厲害！

明天開始，我們就會開始教大家關於授權的觀念。今天就教到這裡，讓我們明天見囉！