有关IndetityServer4的实现问题 [英] Implementation concerns regarding IndetityServer4

问题描述

在以下情况下，我对IdentityServer4有一些疑问:

I have some questions regarding Identityserver4 in the following context:

我有多个域(domainA，domainB，domainC等)，我希望所有域都使用Identityserver4进行身份验证，但我只希望IdentityServer4的一种实现(具有asp.net身份和EF) )，并让所有域都将此实现用作客户端.所有域都在以MS SQL作为数据库的托管环境中(如果有关联的话).

I have a number of domains (domainA, domainB, domainC ect.) and I’d like all of them to use Identityserver4 for authentication, but I’d like only one implementation of Identityserver4 (with asp.net identity and EF) and have the all domains use this implementation as clients. All domains is in a hosted environment with MS SQL as database, if that has any relevance.

问题1:

IdentityServer4可以在domainA的子文件夹/区域中运行吗?知名端点中显示的端点?

Can IdentityServer4 run in a subfolder/area of domainA, and if so what are the necessary steps for getting this to work, e.g. the endpoints shown in the .well-known endpoint?

问题2:

将Identityserver4托管在domainA下的子文件夹/区域中，并且让domainA使用Identityserver来验证站点其余部分的用户身份时，有哪些陷阱?如果有的话，如何避免陷阱? /p>

What are the pitfalls, if any, in hosting Identityserver4 in a subfolder/area under domainA, and also having domainA use Identityserver for authenticating users for the rest of the site, and how to avoid the pitfalls if there are any?

授权部分允许一个用户执行此操作，而不是执行该操作，而另一用户的权限与Identityserver4无关，但是据我了解我可以在网上找到的内容，相应的域/站点负有责任.为了在每个域/站点中的asp.net身份核心2中使用角色和角色声明，该域/站点中必须有一个用户，该用户必须对Identityserver4中的用户进行引用，以便该域使用Identityserver4进行身份验证.

The authorization part that permits one user to do this and not that, and the opposite for another user is not the concern of Identityserver4, but the respective domains/sites own responsibility as I understand what I can find online. In order to make use of roles and roleclaims in asp.net identity core 2 in each domain/site there has to be a user in that domain/site, that has a reference to a user in Identityserver4 in order for the domain to use Identityserver4 for authentication.

问题3:

如何避免用户必须在域和Identityserver4中都进行注册，所以最好进行一种注册，而另一种则与参考一起在幕后进行.

How do I avoid that the user must register both on the domain and in Identityserver4, one registration would be preferable and have the other made behind the scenes along with the reference?

我希望有人可以回答我的一个或所有问题.欢迎访问相关博客等的链接，但是我搜寻了网络以寻找有用的答案，但没有任何运气–希望你们中的某些人比我具有更好的搜索引擎技能.

I hope someone can provide the answers to one or all of my questions. Links to relevant blogs etc. are welcome, but I have scoured the web to find useful answers without any luck – hopefully some of you have better search engine skills than me.

推荐答案

第一季度

是的，可以. IdentityServer是OWIN托管环境，因此，如果您将它设置为domainA，则它将作为middleware使用.拥有公共端点完全取决于您的domainA.

Yes you can. IdentityServer is OWIN hosted environment, thus it will be working as a middleware for your domainA, if you set it up so. Having a public endpoint entirely depends on your domainA.

第二季度

您可能遇到的问题可能是 性能问题 .您的domainA将接收来自domainB和domainC的请求，当然包括domainA本身.与简单的HTTP请求相比，IdentityServer的检查(例如身份验证，验证，颁发令牌)显然很耗时.

The possible problem you will possibly encounter would be performance issues. your domainA is going to receive requests from domainB and domainC including, of course, domainA itself. And IdentityServer's checks-up such as authentications, validations, issuing tokens could be obviously time consuming jobs compared to the plain HTTP requests.

middleware在执行其工作时，性能将比domanB和domainC略低.但这是必然的，不可避免的事与愿违，因为您在HTTP窗口中添加了另一层来处理服务端点上的身份验证/授权/验证问题.

While the middleware is doing its job, the performance will hit slightly lower rate then domanB and domainC. But this is a necessary, unavoidable backfire because you added one another layer in your HTTP windows to deal with the authentication / authorization / validation issues on your service endpoints.

如果流量变得比您预期的大得多，您可能想扩展您的 IdentityServer，并且您认为授权服务器正在拖延整个服务.我建议您事先执行一些压力测试，并比较使用身份服务的服务与不使用身份服务的服务之间的性能差异.

You may want to scale out your IdentityServer if the traffic gets much more huger then you expected and you feel your authorization server is dragging the whole services down. I recommend you to perform some stress tests beforehand and compare the performance differences between the services using the identity service and the services using none of that.

第三季度

这可能是自以为是的答案.但是正如您提到的ASP.NET Identity和EF，我想您已经知道答案了.看来您将要在自己托管的DBMS中管理令牌和身份信息.然后考虑使用可能的重复注册完成此操作.只要您做对了，您的DBMS以及用于存储和获取此类数据的实现都将为您完成.

This could be highly opinionated answer. But as you mentioned ASP.NET Identity and EF I think you already know the answer. It seems that you're going to manage the token and identity information in your own hosted DBMS. Then consider it done with the possible duplicated registrations. Your DBMS and your implementation for storing and fetching such data will do it for you as long as you've done it right.

如果您不打算将DBMS用于身份和令牌数据，而是使用高速缓存或文件系统，那么您将不得不在实现中付出一些努力，以确保concurrency在此类数据的交易.

If you're not going to use DBMS for the identity and token data, and use a cache or a file system instead, then you will have to pour some efforts into the implementation in order to guarantee concurrency on the transactions for such data.

这篇关于有关IndetityServer4的实现问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！