iT邦幫忙

2024 iThome 鐵人賽

DAY 7
0
IT 管理

Backstage : 打造企業內部開發者整合平台系列 第 7

Day 7 : Backstage 內部員工身份認證:從 AD 同步到 SSO 的實施之路

  • 分享至 

  • xImage
  •  

前言

https://ithelp.ithome.com.tw/upload/images/20240916/20128232mXNOTQp8yo.png
以公司遇到的情境為例,隨著公司發展了一段歷史,並且旗下擁有的品牌與服務也越來越多,可惜的是在每個服務幾乎都是獨立擁有自己的系統,也就是說即便都掛在同個集團名下,但實際使用時卻需要重複註冊測一次。用戶可能會覺得說:「奇怪,記得這家也是你們公司的,為什麼我還要重新輸入一次這些基本資料呢。」這類的情況仍然存在尚未解決。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232KYJ5spdYT0.png
面對這種情況也另外衍生了一個問題,在不同服務中都提供了不同商品的優惠,比起現金折扣,公司可能更希望是回饋點數的方式,引導顧客使用點數在公司的其他服務上,創造雙重銷售的效果,另外在顧客持有點數的情況下,留住回頭客的機會也會大許多。這與 Uber 這類服務時常贈送折價券,來引誘用戶使用他們平台的服務,都能達到類似的效果。

為了達到利用點數創造顧客回流的效果,以現行不共通的資料,每個平台可能都各自擁有自己的點數或是折價券,導致顧客可以應用這些回饋的選擇變少,並局限於取得點數的該平台使用,十分可惜。

要解決這種跨平台登入並整合資料的問題,我們可以透過單點登入來解決,就如同我們可以在各種網站中登入 Google 來讀取我們的個人資料。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232tdoUVMNmlp.png

單點登入 SSO

https://ithelp.ithome.com.tw/upload/images/20240916/20128232rpFZBh1Axw.png
圖片來源 - https://www.netfriends.com/blog-posts/leveraging-single-sign-on-sso-to-protect-your-business
單點登入(SSO,全名 Single Sign-On)是一種身份驗證技術,讓使用者只需要進行一次登錄,就能夠在多個系統或應用程式之間無縫切換,而無需每次都重新登入。這不僅簡化了用戶的登入過程,也不必重複註冊多個帳號,單點登入常用的機制也能增強系統的安全性。

常見的 SSO 協議:

  • OAuth2: 開放授權框架,常用於 API 授權,讓第三方應用能安全地訪問用戶的資料。想像你去一間餐廳用餐,你給服務員一張通行證,他會讓你進入餐廳。同樣地,OAuth2 就像這張“通行證”,讓第三方應用程式可以安全地進入某些服務取得你的資料。例如,當我們用 Google 登錄其他網站時,網站不會直接拿到密碼,而是透過 OAuth2 取得授權來讀取你選擇分享的資料。
  • OpenID Connect: 基於 OAuth2 的進階版。用餐廳比喻,這不僅讓你進餐廳,還會告訴餐廳服務員你是誰。它不僅授權第三方應用取得你的資料,還確認你的身份。例如,我們用 Google 登入某個應用,應用程式會自動知道你是誰,並讓你直接使用。
  • SAML: 這就像公司大樓的保全系統,你只需在門口登記一次,進入後你可以自由在各部門之間走動。SAML 主要應用在企業內部系統,它在身份提供者(例如公司的保全系統)和服務提供者(如內部的財務或 HR 系統)之間傳遞身份信息,讓你無需每次進入新系統時再進行身份驗證。

實施 SSO 的解決方案

在現今技術已經相對成熟的時代,許多解決方案已經成為業界標準,我們不再需要從頭開始開發各種協議,尤其在這類資安議題更是企業不可忽視的一環,若在安全中有任何微小疏忽,都可能帶來嚴重的後果。選擇經過市場與時間驗證的成熟應用,不僅能夠加快部署進度,還能減少維護人力,從而降低整體運營成本,也相對安全。

然而,面對市面上眾多的解決方案,如何選出最符合企業需求的應用,並考量每種方案的優劣勢,成為一個關鍵的決策問題。

自行部署 vs. SaaS 服務的考量

對於企業來說,自行部署解決方案能夠讓企業完全掌握服務的運作,並在部署過程中進行高度自定義,更貼合維運架構上的環境與場景。然而,這種方案往往需要更多的技術資源和時間來進行微調與維護。雖然自行部署帶來了更大的控制權,但企業也需要擁有足夠的技術能力來管理與維護這些系統。

另一方面,選擇 SaaS(Software as a Service)服務,則能夠讓企業專注於核心業務,因為這些服務通常已經在雲端架設好,並且提供各種第三方應用的快速整合功能。SaaS 服務雖然方便且需要較少的維護人力,但相對的費用也較高,並且企業對於系統的完整控制權會比較有限,功能上依賴服務提供商。因此,選擇 SaaS 或自行部署,沒有絕對的對錯,全看企業的需求以及資源配置而定。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232UHSTiDK6gl.png

案例比較:IdentityServer 與 Keycloak

以當時我們在比較 IdentityServer 和 Keycloak 為例,這兩個方案在市場上都有一定的口碑,各自擁有不同的優勢與特色。

  1. IdentityServer
    IdentityServer 是一個半開源的身份驗證和授權框架,特別適合需要高自定義和微調的場景。它基於 .NET 平台,與 Microsoft 相關技術有良好的兼容性,我們還能在官方文件中看到以 IdentityServer 為範例來實現身份驗證服務,對於已經使用 .NET 平台的企業來說是個不錯的選擇。IdentityServer 的彈性很大,並以程式碼實現功能為主,這意味著企業需要擁有較強的技術能力來維護與管理該系統,並且在部署過程中可能需要花費較多的時間與精力,雖說是開源,但在企業需要使用的附加功能等等需要與官方購買許可證。

  2. Keycloak
    Keycloak 是另一個強大的開源身份和訪問管理解決方案,它提供了現成的企業級功能,並且對於企業的部署需求有很好的支持。Keycloak 支持多種協議,如 OAuth2、OpenID Connect 和 SAML,並且有內建的單點登錄(SSO)和社群平台登錄整合功能。與 IdentityServer 相比,Keycloak 的上手難度較低,並且提供了直觀的管理介面。它的彈性較高,但自定義選項可能相對少一些,對於需要快速上線且不需要大量客制化的企業來說,是個理想的選擇。

我們最後偏好將身份驗證服務架設於地端,而不必仰賴其它第三方服務的穩定性,經過許多的討論與嘗試,我們最終選擇可以讓我們高度自定義功能的 IdentityServer,其中一點也是因為公司中的 .NET 人力非常多。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232Hbapy8DdHs.png
當時在討論使用哪一款解決方案

架構概念

為了在公司內實現員工的身份認證,我們計畫在 Backstage 中引入 SSO 功能。公司架構的不斷發展,Backstage 將會包含不同平台的微服務,這些微服務同樣需要身份驗證功能。此外,公司本身已有許多系統,這使得實施 SSO 成為必要。與上面提到的面對顧客的角度不同,Backstage 要使用的 SSO 版本屬於面對內部員工的。

Backstage 與 Active Directory 同步

在 Backstage 中,使用者登入必須與一個實體對應。若要手動建立數百個使用者實體,這將是一項極為繁瑣的工作。透過 Backstage 與 Active Directory(AD)的同步,我們可以自動從 AD 的員工清單中建立使用者實體,再結合 OIDC(OpenID Connect)協議實現 SSO 架構,通過映射回傳的 mail 屬性自動完成登入。

社群中實作案例的靈感

我們從社群中的其他實作案例中獲得了許多經驗。例如一家外國房地產公司的 IT 團隊,開發了一個能個透過 Ldap 與 AD 直接驗證的插件,來實現 Backstage 的身份驗證。透過直接針對 Backstage 開發的插件,讓他們能夠直接從 AD 驗證使用者身份,省去了額外架設身份服務的功夫。

此外,另一個比較常見的實作方式是透過 Keycloak 部署身份驗證服務,再與 Backstage 進行整合,多數追求能以最小成本完成這件事情,需要快速部署與後續能穩定使用單純需求。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232CTHWRwuXuH.png

我們的選擇:IdentityServer 與 OTP 系統

針對公司的具體情況,儘管我們考慮了 Keycloak 能快速解決問題的優勢,但最終決定依賴 AD 進行身份驗證,因為現行系統已經大量依賴 AD 作為主要的員工資料來源。使用 AD 進行可以有效利用現有資源,也降低系統整合的複雜性。因此,雖然 Keycloak 提供了 Ldap 串接的選項,但我們決定選擇更符合公司現行架構的方案。

我們選擇使用 IdentityServer,並與公司現有的 OTP 系統進行整合,以加強身份驗證的安全性 (一部分是因為公司政策及現存的系統架構)。通過 IdentityServer,我們可以自行定義身份驗證流程,並進一步擴展 OIDC 驗證流程與 OTP 結合。
https://ithelp.ithome.com.tw/upload/images/20240916/20128232w68lsdH66x.png

文章架構

在接下來的三篇專題文章中,我們將圍繞如何在公司內部實現 SSO,並結合 Backstage 的過程,深入探討每一個重要環節。從公司面臨的實際問題出發,逐步介紹從基礎架構與實作細節的過程。我們將依次探討 AD 的串接、OIDC 的基礎範本,以及 Backstage 插件架構的新舊遷移過程。為了讓讀者更好地理解實作過程,每個文章會稍微補充 AD 和 OIDC 的背景知識。

第一篇:AD 的基礎設置與串接

在第一篇文章中,我們將討論如何將公司現有的 AD 與 Backstage 進行整合,實現員工資訊的自動化同步。這篇文章會稍微介紹 AD 的架設方法,並建議先在虛擬機環境中實際架設進行測試。

第二篇:OIDC 的應用與案例分享

第二篇文章將聚焦於 OIDC 的基礎架設。我們會分享一個成功的實作案例,展示如何通過 Backstage 的 OIDC 插件來實現身份驗證。在這篇文章由於使用到舊版的插件,我們將以概念展示為主,略過詳細的實作步驟,讀者能先理解整體流程。

第三篇:Backstage 插件的遷移與整合

最後一篇文章將深入探討如何將舊版的身份驗證插件遷移至新版 Backstage 的架構。演示插件開發的過程,並解決舊版與新版插件之間的問題,最後再使用 IdentityServer 的 OIDC 驗證範本,實現完整整合 SSO 的身份驗證功能。

結論

在開發 Backstage 的過程中,經常會面臨現有架構與新功能需求之間的抉擇,這些抉擇會時常重現。透過本系列文章的案例分享,我們希望能幫助讀者預見並解決類似的問題,為團隊提供更多參考與指引。

參考文獻

https://www.netfriends.com/blog-posts/leveraging-single-sign-on-sso-to-protect-your-business
https://www.linkedin.com/pulse/hosted-vs-self-hosted-identity-access-management-solution-


上一篇
Day 6 : 使用 Backstage Catalog 目錄連結 Azure DevOps Server 地端專案
下一篇
Day 8 : Backstage 內部員工身份認證:從 AD 同步到 SSO 的實施之路 - AD 篇
系列文
Backstage : 打造企業內部開發者整合平台30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言