0

我们的应用程序（以下称为“XYZ_App”）是一个多租户 SaaS 应用程序。我们正在将其作为多租户“Web 应用程序/API”（以下称为“AppSourceXYZ_App”）提供给 Microsoft AppSource。

当需要/需要多租户时，我们开始我们的 OpenID Connect 实施，端点指向“common”，如文档中所述。

在 XYZ_App 中，我们在系统中添加了信息以了解每个 XYZ_App 租户与哪个 AAD 实例相关联（使用 Microsoft 分配给此 AAD 实例的 GUID，我们没有使用“rename-safe.onmicrosoft.com”表示）。

当使用“通用”端点时，我们必须从 JWT 手动验证颁发者，以确保它是预期的：用户可以访问 XYZ_App 请求访问与 contoso.onmicrosoft.com 关联的 XYZ_App 租户，然后定向到“登录” .microsoftonline.com/common”进行身份验证，然后决定使用来自另一个 AAD 实例（以下称为“anotherAADInstance.onmicrosoft.com”）的用户进行身份验证。在这种情况下，即使用户可以在 anotherAADInstance.onmicrosoft.com 上成功进行身份验证，XYZ_App 的重定向 URI 也必须确保 JWT 颁发者是来自 contoso.onmicrosoft.com 的颁发者。我将此设置称为 Scenario_1。

考虑到这种情况，我们考虑过不使用“common”并即时自定义访问 login.microsoftonline.com 的请求；试图“监禁”强制对特定 AAD 实例进行身份验证的请求。我们仍然需要在重定向 URI 中执行验证，以确保发布者是合适的，但我们认为这种方法可能会让我们的生活更轻松。我将此设置称为 Scenario_2。

您认为 Scenario_2 从长远来看是可行的还是过于短视？根据我目前对 OpenID Connect 的了解，我可以看到 Scenario_2 的一个限制是，在我们的应用程序中支持“代理帐户”会变得有问题。

“经纪人账户”的解释：在我们的行业中，允许一些外部用户访问系统。假设我有一家名为“BrokerCo”的公司（拥有自己的 brokerco.onmicrosoft.com AAD 实例），该公司有 2 名员工：Broker1 和 Broker2。另一个 AADInstance 和 contoso 都聘请了 Broker1 和 Broker2 来获取代理服务以在 XYZ_App 中执行任务；要求 XYZApp 授予他们访问权限。从 OpenID Connect 的角度来看，理想的身份验证方式是什么？如果 XYZ_App 使用“login.microsoftonline.com/common”进行身份验证（如 Scenario_1；与 Scenario_2 中的“监禁”访问相反），Broker1 和 Broker2 可以通过 brokerco.onmicrosoft.com 进行身份验证（没有 AAD“外部用户" 对于另一个 AADInstance 或 contoso)，

您有解决此问题的建议或指示吗？

背景上下文：在使用 OpenID Connect 发行者时，我收到以下错误消息：AADSTS50020：来自身份提供者的用户帐户 'testuser@anotherAADInstance.onmicrosoft.com' https://sts.windows.net/XXXXXXXX-fake-GUID- 9bZZ-XXXXxxxxXXXX/ '在租户 'XYZ Publisher' 中不存在，并且无法访问该租户中的应用程序 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY'。需要先将该帐户添加为租户中的外部用户。注销并使用不同的 Azure Active Directory 用户帐户重新登录。

提前致谢 ！

4

1 回答 1

0

您的问题有多个层次，试图解决其中的大部分问题：

AppSource是关于新用户的试用体验：这意味着全球任何公司帐户都可能成为您的 SaaS 应用程序的用户 - 或者至少是您应用程序的试用体验，因此在与AppSource 是潜在用户第一次体验您的应用程序的难易程度。

考虑到这一点，AppSource 建议应用程序的试用建立在允许来自任何组织的任何用户登录的方式上，因此对于您的应用程序的多租户方法是任何应用程序的推荐设置。

单租户方法需要您有更多的控制权，并且对于试用体验 - 这意味着用户无法立即试用您的应用程序，因为您必须对单租户应用程序执行的操作是将用户添加到 Azure Active Directory 租户作为来宾用户。然后，此访客帐户将需要等待收到一封电子邮件，以接受加入此租户的邀请，您正在添加用户，然后登录到您的应用程序。

因此，您的方案 1是总体上考虑试用体验的最佳方案，并且通常需要较少的管理（因为您不需要创建/管理需要以 Azure AD 的来宾用户身份访问您的应用程序的每个单独帐户实例）。

但是，您列出的一些问题 - 这种情况带来的问题是有效的：因为您正在接受common endpoint，所以您基本上是说任何用户都可以登录到您的应用程序的任何租户，这可能是不可取的。此外，您列出的用户可以为任何应用程序生成令牌的场景也是有效的，但是，您可以添加额外的检查以使其更安全，并且阻止其他身份验证生成的任何令牌：

  1. 您可以验证“受众”声明以保证令牌已颁发给您的应用程序

  2. 您最终可以检查数据库中租户 ID 列表的“tid”/“iss”声明，以查看用户的组织是否是应用程序中的有效组织——这对非试用用户/组织有效.

本文中的更多信息。

关于方案 '2' 和经纪人账户：

这种情况可以用两种不同的方式来解释：

  1. 代理帐户是客户的 Azure AD 租户的来宾帐户
  2. 代理帐户是第三方帐户，但实际上并未添加为另一个 AADInstance 或 contoso AD 的用户

如果您的案例是“1”，那么您是对的：如果您的应用程序需要对属于另一个 Azure AD 租户的来宾用户进行身份验证，则无法直接使用公共端点。

如果您的案例是“2”，那么您需要做的是继续使用公共端点，并在用户通过身份验证后要求他们选择公司。我在没有完全理解这种情况的情况下笼统地描述了这一点。也许这并不简单，因为您希望远程公司而不是用户来控制它 - 所以这里可能需要处理一些额外的复杂性。

请注意，如果您的场景是场景 1。 - 理论上 - 您仍然可以使用混合方法，您会要求用户在应用程序中输入用户名和他们想要登录的公司，然后检查是否您需要根据common或tenant-id端点验证用户，准备请求，然后在身份验证时发送login_hint参数。更多信息在这里

于 2017-12-11T23:29:26.743 回答