使用 NET Core 建置 SAML2 SSO 站台 - 基本概念篇

-

前言

上一篇文章 幫自己的 NET.Core 站台加上 TOTP 雙因子驗證吧 ，有提到如何幫自己的網站加上 MFA 驗證，但說到身分認證系統服務，就不得不提一下 SAML。


SAML 維基百科的定義

安全主張標記式語言（英語：Security Assertion Markup Language，簡稱 SAML）是一個基於 XML 的開源標準資料格式，它在當事方之間交換身分驗證和授權資料，尤其是在身分提供者和服務提供者之間交換。SAML 是 OASIS 安全服務技術委員會的一個產品，始於2001年。其最近的主要更新發布於2005 年，但協定的增強仍在通過附加的可選標準穩步增加。

SAML規範定義了三個角色：委託人（通常為一名使用者）、身分提供者（IdP），服務提供者（SP）。在用SAML解決的使用案例中，委託人從服務提供者那裡請求一項服務。服務提供者請求身分提供者並從那裡並獲得一個身分主張。服務提供者可以基於這一主張進行存取控制的判斷——即決定委託人是否有權執行某些服務。

簡單來說，傳統的網站都是各自管理自己的會員登入檢查，SAML 的架構則是有一個身分提供者的廠商(太抽象的話，也可以理解 IdP 就是類似 Google OAuth 登入服務)，統一管理登入的作業，下圖是一個簡單的登入差異流程。


SAML 運作流程

在當前資安意識抬頭的年代，企業不斷面對著越來越多不同種類的網路攻擊，因此促使企業開始大規模導入多因子驗證，然而，訪間有許多的身分驗證服務廠商，如 OKTA、Google 等，這些服務商主要的任務是協助企業將各種資訊系統的身分驗證整合在一起。

你應該也可以想像，隨著企業的發展，內部的資訊系統一定非常多，若缺乏統一的標準，企業在整合單一登入 (SSO - Single Sign-On) 時將面臨重重困難，這就是為什麼需要 SAML 來規範了，目前 SAML 穩定的版本為 SAML2。

SAML 的登入流程包含了底下四個重要的步驟

  1. 進入服務：使用者進入要使用的服務/站台（SP）。
  2. 產生 SAML Request：服務（SP）發現使用者沒有權限，會產生一個 SAML Request 請求，並轉址到身分提供者（IdP）的登入頁面。
  3. 身分驗證：使用者通過身分提供者（IdP）的登入畫面進行身分驗證。
  4. 回應 SAM Response：通過驗證後 Idp 會將 SAML Response 回應給 SP。

網路上有許多不同版本的 SAML SSO 流程圖，原則上都脫離不了上述四個重要的步驟，下圖是 Google 提供的 SAML SSO 流程圖，有興趣的可自行參考該網站詳細說明。

圖片來源 : https://support.google.com/cloudidentity/answer/6262987?hl=zh-Hant

整合 SAML 的前置作業

在開始開發之前，我們必須先準備好身分提供者（IdP）和自己應用程式（SP）簽名用的憑證。

  1. 建置自己的身分提供者（IdP）環境！？ 但...... 這是一個範圍非常廣泛且複雜的工作，因此，我建議使用知名的身分驗證提供商 Okta 來實作這一部分，如果你還沒有 Okta 的開發者帳號，請先到 Okta 註冊一個 Workforce Identity Cloud 的開發者帳號。Okta 也提供許多程式範例，支援多種語言，方便大家整合自己的系統，至於 Okta 的環境設定我會在下一篇文章中說明。
  2. 接下來，你需要產生服務提供者（SP）的憑證，因為是 Demo 網站，我們可以直接使用自簽憑證。如果不知道如何產生自簽憑證，可以在網路上搜尋相關資料，或者參考我之前的筆記 建立本地端 (Localhost) SSL 憑證。
    openssl req -x509 -new -nodes -sha256 -utf8 -days 3650 -newkey rsa:4096 -keyout server.pem -out server.crt


礙於篇幅的關係，整合 SAML2 SSO 的文章我會分成底下三篇來記錄，有需要的朋友再自行參考。



參考網站



留言

張貼留言

您好，我是 Lawrence，這裡是我的開發筆記的網誌，如果你對我的文章有任何疑問或者有錯誤的話，歡迎留言讓我知道。