2011-09-26 85 views
1

我正在處理多租戶雲應用程序,並考慮將電子郵件地址/密碼用於常規登錄憑據。但是,根據此應用程序的計劃銷售模式,我可能擁有與多個租戶相關的同一用戶(相同的電子郵件地址)。例如,同一家公司的多個部門可能是單獨的租戶,或者單獨的公司必須是單獨的租戶。無論哪種情況,同一用戶(具有相同的電子郵件地址)可能都是這些不同租戶的用戶。多租戶雲應用登錄可能的設計策略?

什麼是可能的設計策略來處理這種情況?

我正在考慮的一種方法是從租戶中分離創建和更新用戶電子郵件憑證。在這種方法中,租戶可以邀請用戶(通過發送電子郵件),用戶可以使用相同的登錄憑證訪問所有租戶,只需根據需要在租戶之間切換。

我在當前Web應用程序中通常看到的情況是,用戶必須爲每個租戶分配不同的電子郵件地址,這對用戶來說似乎是一種負擔。

謝謝。

回答

1

假設你的問題是關於技術設計(而不是用戶體驗),這是一個非常簡單的解決方案。獨立於租戶創建用戶,並允許表示「有權訪問」短語的多對多關係。

根據您選擇的後端,有設計模式的不同表現:

  1. RDBMS:創建一個用戶表,租戶表和user_has_access_to關係表
  2. 目錄服務器(LDAP):將用戶加入目錄中的單個OU,並將租戶創建爲組對象。然後用戶可以爲他們可以訪問的每個租戶設置memberOf屬性。

上面的LDAP選項具有重載組實體的限制。如果您足夠熟悉LDAP模式定義,則可以輕鬆創建租戶對象並向用戶對象添加hasAccessToTenant屬性。採用這種方法將允許您使用組來表示實際的用戶組(因爲要使用對象類型)。

更高級的設計選項將包括在租戶之間創建「有權訪問」關係。將此與用戶一起添加到租戶關係中,可以打開更高級的關係建模。例如:擁有部門或部門的租戶,允許用戶獲得頂層租戶的許可,自動「訪問」該部門。

0

在多租戶應用程序中跨命名空間使用相同的憑證在技術上是可行的。例如,當用戶登錄時,應用程序可以檢查命名空間並確定他所屬的所有命名空間。有可能,用戶可能對這些命名空間具有不同級別的授權。這也是可實施的。

真正的問題是應用程序可以爲這些用戶提供的體驗。他們將需要一個特殊的登陸頁面,這將允許他們在命名空間之間進行選擇。所選的命名空間應在會話期間變爲準永久,即直到用戶註銷。(我試圖在GAE/Python27上的新應用程序中實現此功能)

其他可能性會限制用戶使用單個名稱空間並要求用戶對每個名稱空間使用不同的憑據,這似乎是普遍的做法。