我们只有一个.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。
答案 0 :(得分:1)
这周我不得不解决类似的问题。显然,.NET Core不支持此功能,因为在处理基于GUI的网站时,它可能会引起一些有关身份验证挑战的棘手问题: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
中的请求中提取一个标识符,并使用该标识符在基于Audience
的{{1}}和Authority
上重新配置有关请求传入时存储在数据库中的内容的信息。它不会为请求增加很多开销,并且看起来工作得很好。
我链接的整个存储库是我为使Cognito身份验证与多个用户池一起使用而进行的概念验证,因此值得花一些时间阅读很多内容。这非常混乱,并且包含我不需要替换的类。核心更改在JwtBearerOptions
,CognitoUserPoolResolver
和DSJwtBearerHandler
中。
答案 1 :(得分:0)
如果我正确理解,关键的挑战是识别与已认证用户关联的Cognito用户池。为了解决由Cognito发出的ID令牌包含标识用户池的iss声明的问题。
这里的更多细节,