包含外部身份的EF核心关系 [英] EF Core relationships containing external identity

问题描述

我正在尝试改善自己的一项业余项目，并且一直在研究数据库关系。
当前我有2个解决方案：

I am trying to improve on a hobby project i got and have been looking at database relationships. Currently i have 2 solutions:

• GameStoreSolution：注册所有用户的游戏，游戏设备和得分


• IdentityProvider：具有AspCoreIdentity的IdentityServer4项目，管理身份和身份验证

我的GameStore包含基本的Angular 5前端，以及由IdentityProvider服务器保护的WebApi服务器。

My GameStore contains basic Angular 5 frontend, as well as WebApi Server protected by IdentityProvider server.

我无法正确找出的是如何证明IdentityProvider提供的经过身份验证的用户与相关实体之间的关系在每个单独的商店解决方案中？

What I haven't been able to figure out properly is how do i demonstrate a relationship between authenticated user provided by IdentityProvider and the relevant entities within each individual Store solution?

当前我已经对其进行了黑客攻击，并将AspCoreIdentity复制到两个解决方案中，并通过实体对象创建了链接，例如

Currently i have hacked it and duplicated AspCoreIdentity into both solutions and created links via entity objects e.g. below:

public class GameDevice {
     public Guid Id {get; set;}
     public ApplicationUser User {get;set;}
}

这种方法有效，但是如果您考虑一下，那就不好了。

This approach works but is bad if you think about it.

1. 它强制IdentityProvider和Web App共享用户实体并可能共享数据库

1. It forces IdentityProvider and Web App to share user entity and potentially db

IdentityProvider中的更改，并且如果未复制更改，则导致Web App引发异常

Changes in IdentityProvider and cause Web App to throw exceptions if changes are not copyied over

其他Web应用程序使关系模型更加复杂，甚至进一步引起更多的麻烦

Additional Web Apps complicate the relationship model even further causing more headaches

将需要工作在相同的平台/服务器/数据库上，以最大程度地降低故障风险

Will require to work off same platform/server/db potentially to minimise risks of failure

所以我的问题是，是否有更好的方法来管理与身份提供商所服务的用户之间的关系？

So my question is, is there a better way to manage relationship with user served by the Identity Provider?

推荐答案

让我们退后一步，忘记身份验证。没有它，您将在模型中存储用户信息。业务模型，因为此信息是业务信息。这是显示包含用户信息的报告时所需的信息。它不包含有关身份验证或授权的任何信息。

Let's take one step back and forget about authentication. Without it you would store the user information in your model. The business model, since this information is business information. This is the kind of information you need when you would show a report that contains user information. It doesn't contain any information about authentication or authorization.

现在使用Ids4添加安全性。假设Ids4有自己的数据库，实际上它应该是这样。在Ids4中创建一个用户，并配置流程和用户以授予访问权限。结果是可以登录的用户。因此，您将拥有两个单独的用户：登录用户和业务用户。

Now add security using Ids4. Let's assume that Ids4 has its own database, which is in fact how it should be. Create a user in Ids4 and configure the flow and user to grant access. The result is a user that can login. So then you'll have two seperate users: a login user and a business user.

在继续之前，请记住，并非所有业务用户都需要登录。并非所有登录用户都可以访问此应用程序。

Before I continue, keep in mind, not all business users require to login. And not all login users have access to this application.

最后一步是将两者链接在一起。您应该使用 sub 声明。 ，但我宁愿添加一个声明，其中包含特定应用程序的UserId，例如 http：// myapp1 / userid = 123 。
因为可以确定该密钥在所有应用程序中都是唯一的，并作为OpenId Connect的一部分而存在：在IdentityServer4中， openid 范围是必需的（不需要同意且无法撤消）

Final step is to link the two together. You should use the sub claim for that. but I would rather add a claim that contains the UserId for the specific application, e.g. http://myapp1/userid = 123. Because you can be certain that this key is unique over all apps and exists as claim as it is part of OpenId Connect: in IdentityServer4 the openid scope is required (consent is not needed and can't be revoked by the user).

现在有关冗余。其实没有。信息存储在两个位置，但不在同一数据库中。考虑到这一点，如果您使用外部登录名（例如Google），则会遇到相同的问题，在这种情况下，您会将信息复制到本地身份表中。

Now about redundancy. Actually there isn't. The information is stored on two locations, but not inside the same database. Consider this, if you would use an external login (e.g. Google) then you would have the same problem, in which case you would copy the information to your local Identity tables.

使用Ids4并没有太大不同。但是您不必将信息复制到另一个身份表中，而只需更新您的业务用户。但仅包含业务信息。使用UserInfo端点从Ids4请求用户信息。

With Ids4 it isn't much different. But you don't have to copy the information to another Identity table, instead update your business user. But only with business information. Use the UserInfo endpoint to request user information from Ids4.

将两种环境分开是最简单的方法。因此，没有数据库关系。这适用于所有应用程序。而且，Ids4或应用程序中的更改不会相互影响。

Keeping both environments seperated is the easiest way. So, there isn't a database relation. This works for all your applications. And changes in either Ids4 or in your applications doesn't affect eachother. You could even replace Ids4 with another oidc server if you want to.

已经从代码中消除了复杂性，现在它涉及到配置Ids4，这实际上是一个重要原因使用Ids4：配置资源，范围和流的灵活性。

Having removed complexity from your code, it now it comes to configuring Ids4, which is actually an important reason to use Ids4: the flexibility to configure resources, scopes and flows.

一个缺点可能是您需要在Ids4上维护登录用户，而同时需要在您的应用程序中维护的业务用户。如果您也想从应用程序中管理登录用户，则可以使用API​​扩展Ids4，以实现此目的。

One drawback may be that you'll need to maintain the login user on Ids4, while you'll require a business user which is maintained in your application. If you want to manage the login user from your application too, then extend Ids4 with an API to make this possible.

这篇关于包含外部身份的EF核心关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！