登录多租户云应用程序的可能设计策略?

时间:2011-09-26 01:23:59

标签: login cloud multi-tenant

我正在开发一个多租户云应用程序,并考虑使用电子邮件地址/密码来获取常规登录凭据。但是,根据此应用程序的计划销售模型,我可能拥有与多个租户关联的相同用户(相同的电子邮件地址)。例如,同一公司中的多个部门可能是单独的租户,或者单独的公司必须是单独的租户。在任何一种情况下,同一用户(具有相同的电子邮件地址)可能是这些不同租户的用户。

处理此类情况的可能设计策略是什么?

我正在考虑的一种方法是将用户电子邮件凭证的创建和更新与租户分开。在这种方法中,租户可以邀请用户(通过发送电子邮件),用户可以使用相同的登录凭证访问所有租户,只需根据需要在租户之间切换。

我在当前的网络应用程序中经常看到的是,用户必须为每个租户分别设置电子邮件地址,这对用户来说似乎是一种负担。

感谢。

2 个答案:

答案 0 :(得分:1)

假设您的问题是关于技术设计(而不是用户体验),这是一个非常直接的解决方案。独立于租户创建用户,并允许表示“有权访问”短语的多对多关系。

根据您选择的后端,设计模式有不同的表现形式:

  1. RDBMS:创建用户表,租户表和user_has_access_to关系表
  2. 目录服务器(LDAP):将用户放入目录中的单个OU中,并将租户创建为组对象。然后,用户可以为他们能够访问的每个租户设置memberOf属性。
  3. 上面的LDAP选项具有重载组实体的限制。如果您对LDAP模式定义足够熟悉,则可以轻松创建租户对象并将hasAccessToTenant属性添加到用户对象。采用这种方法可以使用组来表示实际的用户组(因为要使用的是对象类型)。

    更高级的设计选项包括在租户之间建立“有权访问”关系。将此以及用户与租户关系一起添加将开启更高级的关系建模。例如:拥有部门或部门的租户,允许拥有顶级租户权限的用户自动“访问”部门。

答案 1 :(得分:0)

在多租户应用程序中跨命名空间使用相同的凭据在技术上是可行的。例如,当用户登录时,应用程序可以检查命名空间并确定他所属的所有命名空间。有可能,用户可能对这些名称空间具有不同级别的授权。这也是可以实现的。

真正的问题是应用程序可以为这些用户提供的体验。他们需要一个特殊的登陆页面,允许他们在命名空间之间进行选择。在会话期间,即在用户注销之前,所选命名空间应该是准永久性的。 (我试图在GAE / Python27的新应用程序中实现它)

其他可能性是将用户限制在单个命名空间并要求用户针对每个命名空间使用不同的凭据,这似乎是主流做法。