跨域身份管理系統 (SCIM) 簡介

Cloudera 的身份團隊一直在努力将跨域身份管理系統 (SCIM) 支援添加到 Cloudera 資料平台 (CDP)，我們很高興地宣布 SCIM 在 Azure Active Directory 上的全面可用性！在第一部分中，我們讨論了：CDP SCIM 對 Active Directory 的支援，其中讨論了 CDP 對 Azure AD 的 SCIM 支援的核心元素。

SCIM（跨域身份管理系統）：簡介

SCIM（跨域身份管理系統）是用于管理 Web 上的身份（使用者群組）的協定規範。SCIM 協定規範定義了 Web 産品可以實作的一系列端點、有效負載和響應，以便交換身份資訊。“管理身份”僅包含管理該身份的整個生命周期的能力，身份再次是一個人或一個群體。身份的生命周期包括以下階段：

• 建立：當身份是系統的新身份并需要輸入身份資料庫時（例如新員工入職時），
• 閱讀：當授權應用程式想要了解更多關于身份的資訊時（例如運作查詢時），
• 更新/修改：當身份的某個屬性（例如電子郵件位址）發生更改并需要更新時，以及
• 删除：當一個身份需要被删除時（例如當員工被解雇時）。

SCIM 标準允許身份提供者通過使用 REST API 調用在 Web 應用程式中建立、檢索/發現、更新和删除使用者群組狀态。是以，SCIM 取代了圍繞身份管理的大量手動工作。

SCIM 的威力最好用一個例子來說明：

Acme Inc. 是一家公司，Alice 管理他們的身份提供者。過去，當 Acme 是一家隻有幾個員工并且隻使用少數 Web 産品的初創公司時，Alice 會在身份提供者及其所有 Web 産品中手動進行所有使用者管理。當有人加入 Acme 時，Alice 将在身份提供者中手動建立他們的帳戶。然後，她會向他們發送邀請連結，以便在 Acme 使用的所有各種 Web 應用程式中建立一個帳戶/密碼。這是一個手動過程，Acme 幾乎無法控制這些應用程式中的使用者權限。

随着 Acme 的發展，該組織需要更精細地控制員工在他們使用的 Web 應用程式中所擁有的權限——他們已經超越了公司發展的“讓每個人都紮根”階段。是以，Alice 做了大多數公司所做的事情，并将帳戶管理轉移到了單點登入 (SSO) 提供商。這意味着對于所有支援 SSO 的應用程式，Acme 員工不再需要記住他們特定于應用程式的使用者名和密碼。相反，他們可以登入到他們的 SSO 提供商并單擊“使用 SSO 登入”按鈕。這也簡化了 Alice 的生活：每次有人單擊“使用 SSO 登入”按鈕時，都會将更新的使用者狀态（使用者群組資訊）發送到該應用程式。這意味着，如果 Acme 員工調動組織并需要一組新組，他們隻需使用 SSO 再次登入，所有内容都會更新。

SSO 為 Alice 修複了很多手動工作，但并未涵蓋所有情況。僅舉幾例：

• 當新員工加入 Acme 時，他們必須通過 SSO 手動登入才能在每個 Web 應用程式中建立帳戶。
• 每個 Web 應用程式都有不同的會話逾時，是以 Acme 員工需要了解他們必須重新登入才能将更新更新到應用程式中。這也意味着，如果某人在應用程式中獲得了臨時管理者通路權限，他們将繼續擁有該管理者通路權限，直到 Alice 手動撤銷它，或者他們再次登入并更新他們的權限。
• 同樣，當員工被解雇時，他們仍然可以通路他們在 Web 應用程式中的帳戶，直到 Alice 手動删除他們，或者他們的會話過期。

為了解決這些缺點，Alice 編寫了自定義代碼來更新每個産品的使用者群組，并将其連接配接到 Acme 的身份提供程式 webhook。但是代碼很脆弱；随着 API 的變化和新的 Web 産品的添加，它總是過時并不斷維護。用于管理使用者/組狀态的内部 SLA （尤其是對于已離職員工）會不斷打斷她的工作。換句話說，Alice 花費了大量時間來保持自定義代碼正常工作。

通過使用 SCIM（以及支援 SCIM 的身份提供者），所有這些令人頭疼的問題都消失了，或者至少對 Alice 來說大大減輕了。她需要做的就是為每個支援它的 Acme 網絡産品設定 SCIM，她不再需要擔心這些應用程式中的使用者/組狀态。她仍然需要手動管理不支援 SCIM 的 Web 産品中的使用者/組狀态（這就是為什麼仍然有點頭疼的原因），但總的來說，這對她來說仍然是一個巨大的淨利好。

在幕後，Acme 的身份提供者将遵循 SCIM 規範，隻要有使用者/組更改，就會向每個 Web 應用程式發送有效負載。有人被添加到身份提供者的新組中？身份提供者啟動了一系列“将使用者 X 添加到組 Y”，SCIM 調用所有 Web 應用程式，使用者無需重新登入即可更新。有人被解雇了嗎？身份提供者啟動“删除使用者 X”，SCIM 調用這些應用程式。隻需幾分鐘的配置，Alice 就将所有支援 SCIM 的應用程式的工作量減少到接近于零。

然而，SCIM 并不是靈丹妙藥。最大的限制是許多 Web 應用程式不支援它。對于支援它的 Web 應用程式，SCIM 非常有用。

SCIM 如何在幕後工作

本節有點技術性，并引導讀者完成：

• 從身份提供者的角度來看的 SCIM。
• 從網絡産品的角度來看的 SCIM。
• 限制。

身份提供者

公司的身份提供者是使用者和群體的真實來源。對于這種情況，同樣重要的是要注意并非所有身份提供者都支援 SCIM，是以如果您想将 SCIM 與 Cloudera 資料平台一起使用（支援 SCIM 的兩個常見身份提供者是 Azure AD 和 Okta），請記住這一點。

SCIM 協定規範的核心分為兩部分：使用者建立、讀取、更新和删除（CRUD）操作群組 CRUD 操作。在大多數情況下，這是您對 RESTful 規範的期望：身份提供者可以發送到 Web 産品的一系列端點和有效負載，以及對這些請求的一系列響應，讓身份提供者知道它們是否是成功與否。當 Web 産品對 SCIM 調用做出錯誤響應時，身份提供者有兩個選擇：重試（使用一些退避政策）和提醒（電子郵件）可以嘗試修複它的人。正因為如此，Web 産品使用人類可操作的消息來響應錯誤非常重要。

SCIM 使用者 CRUD 操作：

• 建立使用者 (POST)
• 檢索使用者 (GET)
• 檢索特定使用者 (GET)
• 更新使用者（PUT/PATCH）
• 删除使用者 (DELETE)

SCIM 組 CRUD 操作：

• 建立組 (POST)
• 檢索組 (GET)
• 檢索特定組 (GET)
• 更新特定組名（PUT/PATCH）
• 更新特定組成員身份（PUT/PATCH）
• 删除組 (DELETE)

SCIM 還定義了一些超出基本 CRUD 操作的批處理式操作（例如“從組中删除所有使用者”和“替換組中的所有使用者”），以及可以發送以縮小結果範圍的不同查詢參數. 還有一些大多數身份提供者（和大多數 Web 産品）選擇不實作的額外端點（/Me、/Schemas、/ServiceProviderConfig、/ResourceTypes）。

使用者資料以及如何對其進行切片有很多細微差别。例如，一個是應該将哪些字段發送到 Web 産品（例如，CDP 需要電子郵件，但不需要街道位址）。發送的字段還确定身份提供者可以使用哪些查詢參數來嘗試縮小搜尋結果的範圍。查詢參數本身也有細微差别，因為并非所有網絡産品都支援這些垂直領域的縮小結果。例如，一個網絡産品可能會存儲最後修改時間，但它可能不支援通過它過濾使用者。

支援 SCIM 的身份提供者必須維護每個 SCIM 連接配接的 Web 産品的單獨狀态，此外還要維護組織的所有使用者群組的真實來源。每個 SCIM 的單獨狀态–連接配接的網絡産品既重要又複雜：假設 Acme 使用三個産品，A、B 和 C。如果産品 C 出現故障，身份提供者需要能夠跟蹤它認為 C 中的真相來源是什麼，并在 C 重新聯機時同步它，無論中斷多長時間以及發生了多少使用者/組更改。或者，如果 B 不支援完整的 SCIM 規範，則身份提供者需要對出錯的操作進行回退重試（以防 B 決定在将來添加對規範的該部分的支援）同時仍然同步同時所有其他使用者/組更改。身份提供者還需要處理網絡産品中并非源自身份提供者的使用者/組更改（即，當有人僅在網絡産品中更新使用者/組資訊時）。這些隻是幾個例子。

網絡産品

網絡産品（如 CDP）必須具有

• 一種對 SCIM 調用進行身份驗證/授權的機制。
• SCIM 端點。
• 與 SCIM 相容的内部使用者/組 CRUD 操作。

身份驗證機制通常是某種類型的通路令牌或通路令牌秘密，由 Web 産品生成并在設定階段提供給身份提供者。這些通常是長期存在的、可撤銷的，并且包含足夠的資訊來執行授權。一些網絡産品使用使用者通路令牌進行雙重 SCIM 身份驗證/授權，但是如果使用者被删除（即使用者離開公司），令牌将停止工作的缺點，以及有時該使用者被管理的雙重缺點通過 SCIM，是以 SCIM 更新可能會删除使用者，這會删除他們的令牌，這會中斷 SCIM 同步，直到建立新的信任。對于 CDP，我們将身份驗證/授權實作為通路令牌：

• 有一個自定義的生命周期。
• 是可撤銷的。
• 不屬于建立它們的使用者（是以它們存在于系統中任何單個使用者的生命周期之外）。
• 範圍為 SCIM 端點。

Web 提供者的 SCIM 端點需要能夠解析身份提供者發送的有效負載，然後将它們映射到内部操作。但是，SCIM 端點和内部端點之間可能沒有 1:1 的映射，是以需要将它們從 SCIM 規範轉換為内部 API。例如，SCIM 定義了“替換組中的所有使用者”的操作。這可能需要由網絡産品轉換為一系列内部 API 調用，例如：

• 列出組中的所有使用者。
• 從組中删除所有這些使用者。
• 将所有新使用者添加到組中。
• 擷取組資訊并在響應中傳回。

有時 SCIM 規範定義了 Web 産品中不可能的事情。一個常見的例子是大多數網絡産品認為組名是不可變的，但 SCIM 規範定義了一個應該更新組名的有效負載。在這種情況下，網絡産品唯一能做的就是傳回一個人類可操作的錯誤，并希望身份提供者會通知人類事情現在不同步了。

限制

SCIM 規範的一個顯着使用者體驗是缺乏使用者/組資料的雙向同步。也就是說，真相的來源永遠在身份提供者那裡，所有的網絡産品都是“下遊”。是以，對于您開始使用 SCIM 的任何 Web 産品，您都應該停止管理這些産品中的使用者資訊，因為您将與身份提供者中的真實來源不同步。

身份提供者通常不會實時将更改同步到 Web 應用程式，它們以“同步周期”運作。這意味着使用者/組更改可能需要一點時間來傳播（通常這可能需要一個小時）。是以，如果您的内部 SLA 小于同步周期之間的時間，則 SCIM 可能不适合您。或者，如果您的 SLA 是針對特定場景（例如，被解雇的員工），您可以将 SCIM 用于其他所有事情，并且隻需少量代碼即可涵蓋這些特定場景。

最後的一些想法

我希望這是對 SCIM 的有用概述。如果您想閱讀更多内容，跳轉點是：http://www.simplecloud.info/。

如果您的組織使用 Azure AD，并且您希望将 SCIM 與 Cloudera 資料平台一起使用，請參閱我們的文檔以開始使用。

如果您的組織使用 Okta，并且您想開始将 SCIM 與 CDP 一起使用，請聯系您的 Cloudera 代表以将其添加到候補名單中— Okta 支援即将推出。

原文作者：Jason Wang

原文連結：https://blog.cloudera.com/scim-system-for-cross-domain-identity-management/