多租户用户模型
在托管多个组织和应用程序的多租户系统中，一个组织可能使用系统上托管的多个应用程序，我的用户和角色模型是否应该使单个用户或角色可以跨多个应用程序和组织存在？或者我应该将用户实体限制为单个组织/应用程序对，然后定义一些总体模型将这些用户实体绑定在一起？
即：
John Doe 是一个人
他想要使用 ApplicationA 和 ApplicationB
他为两家不同的公司工作（请耐心等待），OrganizationA 和 OrganizationB
如果用户模型为：
johndoe@someuniquesuffix 是他的唯一用户名。这使他能够访问两个组织的两个应用程序。
johndoe@applicationa@organizationa 是他在 OrganizationA 的 ApplicationA 的用户名。 johndoe@applicationb@organizationa 是他在 OrganizationA 中的 ApplicationB 的用户名...对于 OrganizationB 来说也是如此。然后有一些“主”列表，表明应用程序/组织的所有 4 个用户帐户都对应于同一个实际“人”，John Doe？
上面描述的相同场景也适用于我将如何设计我的角色架构。
感谢您的帮助！
In a multitenant system that hosts multiple organizations and applications, where an organization may use several applications hosted on the system, should my user and role model be such that a single user or role can exist across multiple applications and organizations? Or should I limit a user entity to a single organization/application pair and then define some overarching model to tie those user entities together?
That is:
John Doe is a person
He wants to use ApplicationA and ApplicationB
He works for two different companies (just bear with me), OrganizationA and OrganizationB
Should the user model be:
johndoe@someuniquesuffix is his unique user name. This gives him access to both applications for both organizations.
johndoe@applicationa@organizationa is his username for ApplicationA at OrganizationA. johndoe@applicationb@organizationa is his username for ApplicationB at OrganizationA...and the same for OrganizationB. Then have some "master" list that says that all 4 user accounts for the apps/orgs correspond to the same actual "person", John Doe?
The same scenario(s) described above applies to how I will design my Role schema.
Thanks for any asistance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
IMO，您应该将每组凭据限制为一个组织。此外，您应该为每个应用程序启用限制该组织内的用户可以对每个应用程序执行哪些操作的功能。即，每个应用程序应该管理自己的授权角色。您需要一些方法来处理乔离开组织 A 但继续为组织 B 工作的情况。
IMO, you should limit each set of credentials to an organization. Further, you should enable the ability for each application to restrict what users within that organization can do with each application. I.e., each application should manage its own authorization roles. You need some means to handle the scenario where Joe leaves Organization A but continues to work for Organization B.
就我个人而言，我认为跟踪 John Doe 是同时在组织 A 和组织 B 工作的一个人会使事情变得非常复杂，并且在大多数情况下不会增加太多价值。除非您有明确的业务理由在模型中理解 A 的 John Doe 与 B 的 John Doe 相同，否则我会避开它。跨所有组织维护您的用户数据库，必须处理跨组织的唯一名称（“你是什么意思已经有一个 John Doe？那不是我！”）并拥有 UI 模型（例如在登录时询问用户“您今天要处理 A 的数据还是 B 的数据？”只会增加明显的复杂性。
我的建议的一个缺点是，如果您使用 OpenID 或 OAuth 等第三方身份验证器，那么拥有多个租户的人必须使用不同的 ID 登录。例如。我用我的 google openId 登录，最终得到 A 的数据，但要处理 B 的数据，我需要使用我的 Twitter 帐户，因为我的 Google id 已经与 A 绑定，并且仅与 A 绑定。
Personally I think that keeping track that John Doe is one person that works both at Organization A and at Organization B complicates things significantly, without adding much value to the most cases. Unless you have a clear business reason to understand in your model that A's John Doe is the same as B's John Doe, I'd steer away from it. Maintaining your user database across all orgs, having to deal with unique names across orgs ('What do you mean there is already a John Doe? that's not me!') and having the UI model this (eg. asking the user at login 'do you want to work on A's data today or on B's data?) just adds significant complications.
The one drawback of my recommendation is that if you use a 3rd party authenticator like OpenID or OAuth then a person that has multiple tenants has to log in with different IDs. Eg. I log in with my google openId I end up on A's data, but to work on B's I need to use my Twitter account, because my Google id is already tied to A and only A.