在任何一個大公司裡，X5零售集團也不例外，隨著它的發展，需要用戶授權的項目越來越多。 隨著時間的推移，需要用戶從一個應用程序無縫過渡到另一個應用程序，然後就需要使用單個單點登錄 (SSO) 服務器。 但是，當 AD 或其他不具有附加屬性的身份提供商已在各種項目中使用時該怎麼辦？ 一類稱為“身份經紀人”的系統將前來救援。 最實用的是它的代表，例如Keycloak、Gravitee訪問管理等。大多數情況下，用例可以是不同的：機器交互、用戶參與等。解決方案必須支持靈活且可擴展的功能，可以將所有需求結合在一起，而這樣的解決方案我們公司現在有一個指示經紀商——Keycloak。
Keycloak 是 RedHat 維護的開源身份和訪問控制產品。 它是該公司使用 SSO 的產品 - RH-SSO 的基礎。
基本概念
在開始處理解決方案和方法之前，您應該決定流程的術語和順序：
鑑別 是通過主體標識符識別主體的過程（換句話說，這是名稱、登錄名或號碼的定義）。
認證 - 這是一個身份驗證過程（使用密碼檢查用戶，使用電子簽名檢查信件等）
授權 - 這是提供對資源的訪問（例如，電子郵件）。
身份代理密鑰斗篷
鑰匙斗篷 是一種開源身份和訪問管理解決方案，設計用於可以使用微服務架構模式的 IS。
Keycloak 提供單點登錄 (SSO)、代理身份和社交登錄、用戶聯合、客戶端適配器、管理控制台和帳戶管理控制台等功能。
Keycloak支持的基本功能：
- 瀏覽器應用程序的單點登錄和單點退出。
- 支持 OpenID/OAuth 2.0/SAML。
- 身份代理 - 使用外部 OpenID Connect 或 SAML 身份提供商進行身份驗證。
- 社交登錄 - Google、GitHub、Facebook、Twitter 支持用戶識別。
- 用戶聯合 - 來自 LDAP 和 Active Directory 服務器以及其他身份提供商的用戶同步。
- Kerberos 橋 - 使用 Kerberos 服務器進行自動用戶身份驗證。
- 管理控制台 - 通過 Web 統一管理設置和解決方案選項。
- 帳戶管理控制台 - 用於自我管理用戶配置文件。
- 根據公司的企業形象定制解決方案。
- 2FA 身份驗證 - 使用 Google Authenticator 或 FreeOTP 支持 TOTP/HOTP。
- 登錄流程 - 用戶自行註冊、密碼恢復和重置以及其他都是可能的。
- 會話管理 - 管理員可以從單點管理用戶會話。
- 令牌映射器 - 將用戶屬性、角色和其他所需屬性綁定到令牌。
- 跨領域、應用程序和用戶的靈活策略管理。
- CORS 支持 - 客戶端適配器具有內置的 CORS 支持。
- 服務提供商接口 (SPI) - 大量 SPI 允許您自定義服務器的各個方面：身份驗證流程、身份提供商、協議映射等。
- JavaScript 應用程序、WildFly、JBoss EAP、Fuse、Tomcat、Jetty、Spring 的客戶端適配器。
- 支持使用支持 OpenID Connect 依賴方庫或 SAML 2.0 服務提供商庫的各種應用程序。
- 可使用插件進行擴展。
對於 CI / CD 流程以及 Keycloak 中管理流程的自動化，可以使用 REST API / JAVA API。 文檔可通過電子方式獲取：
REST API
Java API
企業身份提供商（本地）
能夠通過用戶聯合服務對用戶進行身份驗證。
還可以使用傳遞身份驗證 - 如果用戶使用 Kerberos（LDAP 或 AD）對工作站進行身份驗證，那麼他們可以自動通過 Keycloak 進行身份驗證，而無需再次輸入用戶名和密碼。
對於用戶的身份驗證和進一步授權，可以使用關係型DBMS，它最適用於開發環境，因為它不涉及項目早期階段的冗長設置和集成。 默認情況下，Keycloak 使用內置 DBMS 來存儲設置和用戶數據。
支持的 DBMS 列表非常廣泛，包括：MS SQL、Oracle、PostgreSQL、MariaDB、Oracle 等。 迄今為止測試最多的是 Oracle 12C Release1 RAC 和 MariaDB 3.12 的 Galera 10.1.19 集群。
身份提供商 - 社交登錄
可以使用社交網絡登錄。 要激活對用戶進行身份驗證的功能，請使用 Keycloack 管理控制台。 不需要更改應用程序代碼，並且該功能是開箱即用的，並且可以在項目的任何階段激活。
可以使用 OpenID/SAML 身份提供商進行用戶身份驗證。
Keycloak 中使用 OAuth2 的典型授權場景
授權碼流程 - 與服務器端應用程序一起使用。 最常見的授權權限類型之一，因為它非常適合外部人員無法獲取應用程序源代碼和客戶端數據的服務器應用程序。 本例中的過程是基於重定向的。 應用程序必須能夠與用戶代理（用戶代理）（例如 Web 瀏覽器）交互，以接收通過用戶代理重定向的 API 授權代碼。
隱式流動 - 由移動或網絡應用程序（在用戶設備上運行的應用程序）使用。
隱式授權權限類型用於無法保證客戶端機密性的移動和 Web 應用程序。 隱式權限類型還使用用戶代理重定向，從而將訪問令牌傳遞給用戶代理以在應用程序中進一步使用。 這使得該令牌可供用戶和用戶設備上的其他應用程序使用。 這種類型的授權權限不會驗證應用程序的身份，並且流程本身依賴於重定向 URL（之前在服務中註冊）。
隱式流不支持訪問令牌刷新令牌。
客戶憑證授予流程 — 當應用程序訪問 API 時使用。 這種類型的授權權限通常用於必須在後台執行而無需立即用戶交互的服務器到服務器交互。 客戶端憑據授予流程允許 Web 服務（機密客戶端）在調用另一個 Web 服務時使用自己的憑據，而不是模擬用戶進行身份驗證。 為了獲得更高級別的安全性，調用服務可以使用證書（而不是共享密鑰）作為憑證。
OAuth2 規範描述於
JWT 代幣及其好處
JWT（JSON Web Token）是一個開放標準（）定義了一種緊湊且獨立的方式，以 JSON 對象的形式在各方之間安全地傳輸信息。
根據標準，令牌由三部分組成，採用 Base-64 格式，並用點分隔。 第一部分稱為標頭，其中包含令牌的類型和用於獲取數字簽名的哈希算法的名稱。 第二部分存儲基本信息（用戶、屬性等）。 第三部分是數字簽名。
。 。
切勿將令牌存儲在數據庫中。 由於有效令牌相當於密碼，因此存儲令牌就像以明文形式存儲密碼一樣。
訪問令牌 是授予其所有者訪問安全服務器資源的令牌。 它的生命週期通常很短，並且可能攜帶附加信息，例如請求令牌的一方的 IP 地址。
刷新令牌 是一個令牌，允許客戶端在其生命週期到期後請求新的訪問令牌。 這些代幣通常會發行很長一段時間。
在微服務架構中使用的主要優點：
- 能夠通過一次性身份驗證訪問各種應用程序和服務。
- 如果用戶配置文件中缺少許多必需的屬性，則可以使用可添加到有效負載的數據來豐富，包括自動的和動態的。
- 不需要存儲有關活動會話的信息，服務器應用程序只需要驗證簽名。
- 通過有效負載中的附加屬性進行更靈活的訪問控制。
- 對標頭和有效負載使用令牌簽名提高了整個解決方案的安全性。
JWT 令牌 - 組成
標題 - 默認情況下，標頭僅包含令牌類型和用於加密的算法。
令牌的類型存儲在“typ”鍵中。 JWT 中會忽略“type”鍵。 如果存在“typ”鍵，則其值必須是 JWT 以指示該對像是 JSON Web 令牌。
第二個密鑰“alg”定義用於加密令牌的算法。 默認情況下應設置為 HS256。 標頭採用 base64 編碼。
{“alg”：“HS256”，“類型”：“JWT”}
有效負載（內容） - 有效負載存儲任何需要檢查的信息。 有效負載中的每個密鑰稱為“聲明”。 例如，您只能通過邀請（封閉促銷）進入應用程序。 當我們想邀請某人參加時，我們會向他們發送邀請函。 檢查電子郵件地址是否屬於接受邀請的人非常重要，因此我們將在有效負載中包含該地址，為此我們將其存儲在“email”鍵中
{ “電子郵件”： ”[電子郵件保護]”}
有效負載中的密鑰可以是任意的。 不過，還是有一些保留的：
- iss（頒發者）- 標識發送令牌的應用程序。
- sub（主題）- 定義令牌的主題。
- aud（受眾）是區分大小寫的字符串或 URI 的數組，它是此令牌的接收者的列表。 當接收方收到帶有給定密鑰的 JWT 時，它必須檢查接收方中是否存在自身 - 否則忽略該令牌。
- exp（過期時間）- 指示令牌何時過期。 JWT 標準要求其所有實現拒絕過期令牌。 exp 鍵必須是 unix 格式的時間戳。
- nbf（Not Before）是unix格式的時間，用於確定令牌生效的時刻。
- iat (Issued At) - 該密鑰表示令牌的發行時間，可用於確定 JWT 的年齡。 iat 鍵必須是 unix 格式的時間戳。
- Jti (JWT ID) — 定義此令牌的唯一標識符的字符串，區分大小寫。
重要的是要了解有效負載不是以加密形式傳輸（儘管令牌可以嵌套，然後可以傳輸加密數據）。 因此，它不能存儲任何秘密信息。 與標頭一樣，有效負載也是採用 Base64 編碼的。
簽名 - 當我們有標題和有效負載時，我們可以計算簽名。
Base64編碼：獲取header和payload，通過點組合成字符串。 然後該字符串和密鑰被輸入到標頭中指定的加密算法（“alg”密鑰）。 鍵可以是任何字符串。 較長的繩子是最受歡迎的，因為它需要更長的時間來拾取。
{“alg”：“RSA1_5”，“有效負載”：“A128CBC-HS256”}
構建Keycloak故障轉移集群架構
當所有項目使用單個集群時，對 SSO 解決方案的要求會增加。 當項目數量較少時，這些要求對於所有項目來說並不是那麼明顯，但是，隨著用戶數量和集成數量的增加，對可用性和性能的要求也會增加。
單一 SSO 失敗風險的增加增加了對解決方案架構和用於冗餘組件的方法的要求，並導致非常嚴格的 SLA。 在這方面，更常見的是，在開發或實施解決方案的早期階段，項目都有自己的非容錯基礎設施。 隨著發展的進展，需要提供發展和擴展的機會。 使用容器虛擬化或混合方法構建故障轉移集群是最靈活的。
為了工作在Active/Active和Active/Passive集群模式下，需要保證關係數據庫中的數據一致性——兩個數據庫節點必須在不同地理分佈的數據中心之間同步複製。
容錯安裝的最簡單示例。
使用單個集群有哪些好處：
- 高可用性和性能。
- 支持工作模式：主動/主動、主動/被動。
- 能夠動態擴展 - 使用容器虛擬化時。
- 集中管理和監控的可能性。
- 項目中用戶識別/身份驗證/授權的統一方法。
- 不同項目之間的交互更加透明，無需用戶參與。
- 能夠在各種項目中重用 JWT 令牌。
- 單點信任。
- 使用微服務/容器虛擬化更快地啟動項目（無需提升和配置其他組件）。
- 可以從供應商處購買商業支持。
規劃集群時要注意什麼
數據庫管理系統
Keycloak 使用數據庫管理系統來存儲：領域、客戶端、用戶等。
支持多種 DBMS：MS SQL、Oracle、MySQL、PostgreSQL。 Keycloak 帶有自己的內置關係數據庫。 建議用於非加載環境 - 例如開發環境。
要工作在Active/Active和Active/Passive集群模式下，需要關係數據庫中的數據一致性，並且兩個數據庫集群節點在數據中心之間同步複製。
分佈式緩存（Infinspan）
為了使集群正常工作，需要使用 JBoss 數據網格對以下類型的緩存進行額外同步：
身份驗證會話 - 用於在對特定用戶進行身份驗證時保存數據。 來自此緩存的請求通常僅包括瀏覽器和 Keycloak 服務器，而不包括應用程序。
操作令牌用於用戶需要異步確認操作（通過電子郵件）的場景。 例如，在忘記密碼流程期間，actionTokens Infinispan 緩存用於跟踪有關已使用的關聯操作令牌的元數據，因此無法重複使用。
持久數據的緩存和失效——用於緩存持久數據，以避免對數據庫進行不必要的查詢。 當任何一個Keycloak服務器更新數據時，所有數據中心的所有其他Keycloak服務器都需要知道它。
Work - 僅用於在集群節點和數據中心之間發送無效消息。
用戶會話 - 用於存儲有關用戶會話的數據，這些數據在用戶瀏覽器會話期間有效。 緩存必須處理來自最終用戶和應用程序的 HTTP 請求。
暴力保護 - 用於跟踪有關失敗登錄的數據。
負載均衡
負載均衡器是 keycloak 的單一入口點，並且必須支持粘性會話。
應用服務器
它們用於控制組件之間的交互，並且可以使用現有的自動化工具和基礎設施自動化工具的動態擴展進行虛擬化或容器化。 OpenShift、Kubernates、Rancher 中最常見的部署場景。
第一部分——理論部分到此結束。 在接下來的系列文章中，將分析與各種身份提供商集成的示例和設置示例。
來源： www.habr.com