参考

Question

我们正在构建一个多租户应用程序，该应用程序将托管在全球多个数据中心（Azure）中。此应用程序还将公开API（不仅仅是MVC Web应用程序）。

为了处理身份验证/授权，我们计划实施Owin OAuth，但后来我们遇到了Thinktecture IdentityServer3＆＃39;适合我们的账单。

此外，如果租户在任何区域实例中拥有帐户（例如＆＃39; NA1.ourwebsite.com＆＃39;），他不仅应该能够登录＆＃39; NA1.ourwebsite.com＆＃39; ;，但他也应该能够通过集中的实例/身份服务器登录我们的网站＆＃39;。

NA1.ourwebsite.com - 北美实例

EA1.ourwebsite.com - 东亚实例

目前，我们为每个租户提供了不同的数据库，其用户信息也存在于各自的数据库中。

我不确定一个应用程序如何拥有多个身份服务器（我不知道是否必须选择联合服务器）。

SalesForce.com完全一样，但我不知道如何做。任何人都可以帮助我吗？

提前致谢。

Answer 1

为了处理身份验证/授权，我们计划实施Owin OAuth，但后来我们遇到了Thinktecture IdentityServer3＆＃39;适合我们的账单。

确实如此。 Thinktecture IdentityServer3 是OpenID Connect的一个实现，OpenID Connect是OAuth，添加了一个＆＃34;身份层。＆＃ 34;您仍然可以使用OAuth进行授权（访问受保护资源），因为OpenID提供程序通常会返回access_token。它还返回id_token进行身份验证（身份验证）。

此外，如果租户在任何区域实例中拥有帐户（例如＆＃39; NA1.ourwebsite.com＆＃39;），他不仅应该能够登录＆＃39; NA1.ourwebsite.com＆＃39; ;，但他也应该能够通过集中的实例/身份服务器登录我们的网站＆＃39;。

这是OpenID Connect启用的用例。您可以让最终用户选择是使用我们的网站登录NA1.ourwebsite.com，还是使用任何其他OpenID Connect提供商。例如，我可以使用多个提供程序登录相同的StackExchange帐户。

当然，最终用户需要将每个OpenID Connect身份与您应用中的帐户相关联。有时，您的应用可以根据OpenID Connect声明（例如电子邮件）自动解决此问题，而有时最终用户必须手动关联登录。例如。

目前，我们为每个租户提供了不同的数据库，其用户信息也存在于各自的数据库中。

您可以采取多种方法继续前进。 您需要将仅与您的应用相关的用户信息与与身份验证相关的用户信息区分开来。您无法合理地期望所有OpenID Connect提供商都存储您的应用所需的所有用户信息。关于用户信息，它只能验证您的用户身份并提供您的用户已在提供商处存储的个人资料信息（例如，他们的Twitter帐户中的内容。）

我不确定一个应用程序如何拥有多个身份服务器（我不知道是否必须选择联合服务器）。

这有点像一个机场如何接受多种形式的身份证明：出生证明，电费单，护照，驾驶执照。很难理解但是一旦你知道{{1}就像你可以开始欣赏它的一块可信任的识别。现实世界的例子是出生证明。在这种情况下，政府是身份提供者，出生证明是id_token。应用程序可以选择它接受的身份提供程序。

SalesForce.com完全一样，但我不知道如何做。任何人都可以帮助我吗？

除了salesforce.com之外，如上所述，stackexchange.com也是这样做的。 OpenID Connect规范中的图表将有所帮助。

id_token

RP（客户端）向OpenID提供商（OP）发送请求。
OP验证最终用户并获得授权。
OP以ID令牌响应，通常是访问令牌。
RP可以使用访问令牌向UserInfo端点发送请求。
UserInfo Endpoint返回有关最终用户的声明。

+--------+ +--------+ | | | | | |---------(1) AuthN Request-------->| | | | | | | | +--------+ | | | | | | | | | | | End- |<--(2) AuthN & AuthZ-->| | | | | User | | | | RP | | | | OP | | | +--------+ | | | | | | | |<--------(3) AuthN Response--------| | | | | | | |---------(4) UserInfo Request----->| | | | | | | |<--------(5) UserInfo Response-----| | | | | | +--------+ +--------+是OpenID Connect提供商。我认为这就是＆＃34;身份服务器的意思。＆＃34;您可以接受应用决定信任的任何提供商的令牌。最终用户可以选择在登录时使用哪个提供商（您经常会将此视为选择使用Twitter，Facebook，Google，Microsoft登录...）。其中一个选择可能是ourwebsite.com。

OP是依赖方，在这种情况下是您的应用程序。它被称为依赖方，因为它依赖于各种OP进行身份验证，授权和一些用户配置文件存储。

上述步骤（1）至（3）与OAuth授权流程几乎完全相同，其中最终用户登录到所选择的提供者，并且提供者使用令牌进行响应。与OpenID Connect的不同之处在于，在步骤（3）中，除了RP之外，响应通常还包含id_token。

access_token代表最终用户授权。这是一个OAuth烧杯令牌。您的应用包含在受保护资源的请求中。这些受保护的资源可以包括存储在OpenID Connect提供程序中的用户信息。参见步骤（4）和（5）。

access_token代表最终用户身份验证，并包含有关最终用户和Open ID Connect Provider的声明。 id_token声明标识了OpenID提供商，iss声明唯一标识了最终用户，sub声明标识了依赖方（您的应用）。其他标准声明包括aud，name，given_name，family_name，middle_name，picture，website，{{1经过身份验证的最终用户。

授权最重要的是email和phone_number，因为这两者的组合唯一标识了登录信息。

OpenID Connect很复杂，需要一些时间才能完全欣赏。您的持久性将得到回报，因为它完全符合您的用例。 Thinktecture IdentityServer3 看起来像一个可靠的选项。另一个要评估的类似的是AspNet.Security.OpenIdConnect.Server。

参考

OpenID Connect in a nutshell。这篇文章由OpenID Connect的一位作者撰写，包含两个特别有用的部分：＆＃34;制作OpenID Connect请求＆＃34;和＆＃34;接收OpenID Connect响应。＆＃34;

OpenID Connect Core 1.0 incorporating errata set 1其中一个规范文档包含此答案中发布的有用图表。

The OAuth 2.0 Authorization Framework: Bearer Token Usage OAuth RFC，解释了如何在受保护资源的请求中使用sub。

如何实现多个IdentityServer

1 个答案:

参考