我们有一个单独的.net Core MVC Web应用程序,将由多个客户使用.每个客户都有许多用户.
我们打算使用AWS Cognito进行用户身份验证并阅读此内容我发现每个客户的用户池是推荐的路由之一.这适用于我们的用例,因为客户A可能希望用户具有用户名“Bob”而客户B可能想要另一个用户具有用户名“Bob”.
我读过的所有内容都表明这应该是可能的,但问题在于:
在.net核心中,我必须在启动时指定特定于特定应用程序池的一些细节:
.AddOpenIdConnect(async options =>
{
options.ResponseType = OpenIdConnectResponseType.Code;
options.ConfigurationManager = new ConfigurationManager<OpenIdConnectConfiguration>(
services.BuildServiceProvider().GetService<IOpenIdDiscovery>().OpenIdConfigurationUrl(),
new OpenIdConnectConfigurationRetriever(),
services.BuildServiceProvider().GetService<System.Net.Http.HttpClient>());
options.Authority = Configuration["OpenIdAuthority"];
options.ClientId = Configuration["AuthCodeClientId"];
options.ClientSecret = Configuration["AuthCodeClientSecret"];
如何让应用程序使用多个用户池?
要详细说明上述内容,我认为理想的解决方案是:
1)我们将用户引导至其用户池的特定登录URL.
2)登录后用户被重定向到中心站点.
3)我们以某种方式检测他们通过哪个用户池,并相应地为会话设置ClientId和ClientSecret.
最佳答案 我本周必须解决类似的问题.显然.NET Core不支持这种开箱即用,因为它可以在处理基于GUI的网站时提出一些关于auth挑战的棘手问题:
https://github.com/aspnet/Security/issues/1847
我在API服务器的上下文中解决了这个问题,但很容易做出一些基本的假设.
我最终通过实现我自己的JwtBearerHandler类来解决它,该类与.NET Core一样,但是根据HTTP请求中的信息动态重新配置JwtBearerOptions.最相关的变化可以在这里找到:https://github.com/tgittos/AmazonCognitoPrototype/blob/master/AmazonCognitoSpike/Auth/CognitoUserPoolResolver.cs
基本上,解决方案的要点是从JwtBearerHandler中的请求中提取标识符,并根据请求进入时根据数据库中存储的内容重新配置JwtBearerOptions上的Audience和Authority.它不会添加请求的大量开销,似乎工作得很好.
我链接的整个回购是我为了让Cognito auth使用多个用户池而进行的概念验证,因此可能需要花一些时间来阅读该批次.它非常混乱,包括我不需要替换的类.核心更改位于CognitoUserPoolResolver,DSJwtBearerHandler和DSJwtBearerOptions中.