将用户数据存储在身份验证服务器或资源服务器中?或两者? [英] Store user data in auth server or resource server? Or both?
问题描述
这是我第一次使用IdentityServer 4和AspNetIdentity设置OpenID Connect，我希望有人能够揭开有关存储用户数据的神秘面纱.
This is my first time setting up OpenID Connect with IdentityServer 4 and AspNetIdentity and I was hoping someone could demystify the part about storing user data.
到目前为止，我已经读到用户数据应该存储在连接到auth服务器的Auth数据库中，但是我真的很想将用户数据也存储在连接到资源的数据库中服务器.
What I've read so far is that user data should be stored in the Auth db that is connected to the auth server, but I'd really like to store user data in the resource db too that is connected to the resource server.
我目前有一个数据模型，如下所示:
I currently have a data model that looks like this:
我已经省略了User和Event的许多字段，但是希望您能看到图片.我们有一个用户表，一个事件表和一个主机表.用户可以主持事件.用户和事件之间的多对多关系是通过主机表实现的.
I have omitted many of the fields for both User and Event, but you hopefully get the picture. We have a User table, an Event table, and a Host table. A User can Host an Event. The many-to-many relation between a User and an Event is via the Host table.
这是一个关于建筑的基本问题，但是，很难找到一个合理的好答案，这并不是一个完全的hack.到目前为止，我已经从不同的人那里了解了以下解决方案:
This is such a rudimentary question on architecture, yet it's really hard to find a good answer that makes sense and that isn't a total hack. So far I've read about the following solutions from different people:
-
仅将所有用户数据存储在Auth数据库中，然后在Auth服务器上设置API，以便资源服务器可以从Auth服务器获取数据.
Store all user data in the Auth db, only, and then set an API up on the Auth server so the Resource server can get data from the Auth server.
有人说不应该将与身份验证无关的数据(例如用户所在的城市或国家/地区)存储在Auth数据库中.取而代之的是，仅将与身份验证相关的数据保留在Auth服务器中，并将与用户相关的所有数据保留在资源数据库中.听起来这两个用户记录需要同步吗?听起来是个坏主意.
Someone else says that non-auth related data such as a user's city or country should not be stored in the Auth db. Instead keep auth related data in the Auth server only and any user-related data in the Resource DB. This sounds like the two User records need to be in sync? Sounds like a bad idea.
将资源服务器和身份验证服务器作为一个应用程序，以便我们可以在用户，主机和事件之间建立必要的关系.但这似乎违反了使用OpenID Connect的全部目的.
Have the Resource server and Auth server be one application so that we can build the necessary relations between User, Host, and Event. But this seems to defeat the whole purpose of using OpenID Connect.
那么这里的标准架构是什么?或者，如果没有一种千篇一律的方法，您将如何存储此用户数据?
So what is the standard architecture here? Or if there is no one-size-fits all, how would you store this user data?
推荐答案
牢记关注点和单一责任:
With seperation of concerns and single responsibility in mind:
不仅有一个用户表.表中的字段在上下文中仅具有含义.
There is not just one user table. Fields in a table have only meaning within the context.
用户可以使用Google帐户登录，但对于不是可以与员工联系的帐户的企业.在不属于上下文的报告中显示信息又如何呢?假设您在标识上下文中存储城市.然后，您将如何在报告中显示该信息?您需要在业务环境中提供信息.
A user can have a google account to login, but for the business that is not the account where you can reach the employee. And how about showing information on a report that is not part of the context? Suppose you store city in the identity context. Then how are you going to show that information on a report? You'll need the information in the business context.
还要考虑身份上下文是否是存储信息的好地方.因为用户处于控制之中.如果用户不同意使用信息或只是删除帐户，该怎么办?想要同步数据时使用什么策略?
Also consider whether the identity context is a good place to store information. Because the user is in control. What happens when the user doesn't give consent for using the information, or simply removes the account? And what strategy to use when you would like to synchronize data?
共享上下文是行不通的.身份是IdentityServer的责任，身份上下文应仅包含有关身份的信息，并且只能由IdentityServer访问.请注意，IdentityServer未绑定到一个应用程序.
Sharing contexts is a no go. Identity is the responsibility of IdentityServer, the identity context should only contain information about the identity and is only accessible by the IdentityServer. Please note that IdentityServer is not bound to one app.
在每个上下文中都需要一个用户表.那里的信息看似多余，但实际上不是多余的，因为它是单独上下文的一部分.就像您使用Google之类的提供商登录时一样.然后，在身份上下文中创建用户的本地副本.
You'll need a user table in each context. Where information may seem redundant but actually is not, because it is part of the seperate context. Like when you login using a provider like google. Then a local copy of the user is created in the identity context.
但是，也许您不应该在业务环境中将其称为用户".因为在业务环境中没有用户.他们很可能是员工，客户等.谁可以登录，但不一定.并且可能会有(身份)用户不了解该业务(例如，在有多个应用程序的情况下).
But perhaps you should not refer to it as User in the business context. Because within the business context there are no users. Most likely they are employees, customers, etc. Who can have a login, but not necessarily. And it's possible to have (identity) users that are unkown to the business (e.g. in case of multiple apps).
IdentityServer是对用户进行身份验证的权限.授权可以在多个级别上实现.您可以创建单独的授权服务器(例如 policyserver ).或较低级别(基于资源)在人员"表中表示用户有权访问该资源.
IdentityServer is the authority to authenticate the user. Authorization can be implemented on multiple levels. You can create a seperate authorization server (like policyserver). Or lower level (resource-based), where the existence of a user inside the 'person' table means that the user has access to the resource.
单独上下文的最好之处在于，可以在上下文中创建表之间的关系，而不会干扰其他上下文.如果需要，您可以轻松切换到其他oidc提供程序.但是一旦开始混合上下文，就没有回头路了.
The best part of seperate contexts is that within the context you can create relations between tables, without interfering with other contexts. You can easily switch to a different oidc provider, if you'd like. But once you start to mix contexts, there is no way back.
在oidc中非常有用的一件事是 sub 声明.只需通过 sub 声明查找用户，并将本地ID用于业务环境.
The one thing that is very useful in oidc is the sub claim. Simply look up the user by the sub claim and use the local id for the business context.
关于身份上下文中的 city 和 country 字段:身份验证有多个级别，因此您实际上可能需要此上下文中的信息.但是，如果您需要在其他上下文中使用该信息(例如在报告中显示)，则也应该在其中添加该信息.
About the fields city and country in the identity context: there are multiple levels of authentication, so you may actually need the information in this context. But if you need the information in another context (e.g. to show on reports) then it should be added there (as well).
这篇关于将用户数据存储在身份验证服务器或资源服务器中?或两者?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
