跨租户用户的多租户

Question

我们目前需要构建一个具有跨租户用户的多租户应用程序。也就是说，业务数据是由租户分隔的，但是用户可以属于多个租户，并且应该能够访问每个租户的所有数据。我的问题是这有意义吗？如果是的话，我们如何使用OpenID连接来处理这个场景的登录？当我在过去使用OpenID连接完成多租户时，tenantId已经成为登录的一部分。给定的需求显着地使事情复杂化。我应该推回去吗？这个需求的主要原因是防止属于多个租户的用户不得不进行多个登录。有什么想法？

Answer 1

我同意罗伯特·H.的观点，术语在这里有一个首要的问题。您的客户没有一致或正确地使用这些术语，因此使用该术语进行的任何需求讨论都是有问题的。避开它。

相反，谈论用例。这一要求可能会以简单的措辞重新表述如下：

作为一个用户，我需要能够访问所有的租户特定的网站，而不需要输入我的密码不止一次。

如果这是整个需求的范围，那么它应该不会很难实现，而且已经有一些标准支持它。毕竟，您可以使用Facebook或Google登录多个网站，而无需多次输入您的密码，并且这些孤立的网站至少与您的租户一样分开。如果你这样想的话，这个问题应该是微不足道的。

1. 修改网站以包括允许用户切换租户的小部件，例如在标题的右上角。
2. 小部件简单地重定向到指定租户的默认页面。
3. 特定于租户的网站检查用户是否已经拥有特定于租户的令牌。如果没有，则重定向到授权服务器。
4. 授权服务器将知道用户是否已经登录。如果不是，它将呈现输入用户名或密码所需的页面。如果是的话，它可能必须呈现一个页面，请求用户授予访问租户的权限(至少在第一次访问时是这样)。
5. 授权服务器重定向回特定于租户的网站，并带有访问它的令牌(例如，对租户的索赔)。
6. 特定于租户的服务器检查令牌以确定用户的身份，并检查是否有适当的声明。
7. 用户将继续拥有单独的记录，每个租户一份，包括不同的个人资料。这与维护单独配置文件的堆栈Exchange站点没有什么不同。
8. 此外，您还可以向用户提供同步配置文件的能力。例如，堆栈Exchange有一个“只为这个社区保存更改”按钮和一个“将更改保存并复制到所有公共社区”。但这是一个单独的要求，以确定与您的产品所有者(S)。

不要把它看作是“交叉租户用户”。这是一种解决办法，而不是一项要求。首先关注用例，然后根据这些案例确定解决方案。

Answer 2

In

是的，这是合理的，例如，结合SSO，但它削弱了租户的独立性。

更多信息

原则上，在多租户体系结构中，您希望每个租户独立于其他租户，就像--如果它是单独的系统。这意味着每个租户都应该有自己的用户管理。

然而，一些用户可能不得不对几个租户进行工作。例如，在我的公司，我们运行一个多租户系统，其中有几个系统管理员和审计员需要访问几个租户。但我也可以想象，共享服务中，相同的用户为不同的法律实体管理操作。

对于这种情况，自然的多租户方案是保持租户之间的严格隔离.用户需要在登录时选择租户，您必须复制相关帐户。这是很麻烦，但完全符合多租户的目标和工作非常好.直到你想要实现一些单一的登录。

使用SSO，您仍然可以要求用户首先选择租户，然后在正确的租户中使用SSO凭据。但是对于99%的用户来说，这将需要额外的选择他们注册的唯一租户，而SSO则被期望获得平滑的无缝访问，在连接到系统时避免任何不必要的步骤。换句话说，您可以将每个租户的用户管理分开，但这不符合您想要通过SSO提供的用户体验。

因此，对用户帐户进行全球管理是有意义的。通过这种方式，您可以使用SSO凭据连接到多个租户，系统将要求您使用该租户，前提是您在多个租户中拥有凭证。

在这种情况下，您的数据模型将分离：

• 用户帐户的管理，仅限于交叉租户的最低限度(例如用户id +名称)，
• 特定租户的用户数据(如所有权、联系人详细信息)和凭证(即授权)

这样，您仍然符合多租户(惟一帐户标识除外)，并允许在租户级别管理所需的元素，以确保由负责租户的实体进行操作控制。