多实例应用和Azure身份验证最佳实践

Question

我们有一个多实例Saas应用程序：

• 我们的每个客户都有自己的实例和他们自己的网站子域。
• 我们的应用程序（Web应用程序和API）受Azure保护，目前使用ADAL javascript库
• 我们还有第二个用于系统级集成的API，需要加以保护，目前正在使用第二个本地＆＃39; azure app，但这可能不正确，我们想巩固
• 我们的应用程序通过AzureAD Graph API和Microsoft Graph API（包括密码重置调用）读取和写入Azure AD

我们正在研究Azure AD应用程序配置选项，并希望确保我们构建最合理，最安全的Azure AD应用程序。以下是我们一直在关注的一些文档：

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds

https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare

我们希望应用程序成为多租户，以简化配置，并允许在Gallery中提供可用性;但在考虑这样做时，我们会留下一些安全问题。

：一种。使用哪个应用程序版本

• 1）v1。允许访问两个Graph API。正如Microsoft建议的那样，当我们不关心Microsoft帐户时，我们应该使用它。
• 2）v2。查看MS Graph API文档时，建议使用v2。据说对AzureAD Graph API不起作用？允许同一个应用程序有多种类型（Web App / API和本机），我们可能需要或不需要保护我们的web api和我们的系统api（我们仍在尝试建模）。

B中。如果我们的客户有不同的子域，如何管理回复URL？

我注意到以下选项：

• 1）在app注册表中，我们为所有客户添加回复网址。这似乎没关系，因为我们只需要做一次，但感觉很奇怪。回复网址的数量是否有限制？
• 2）有一个回复网址，但管理一个外部工具，将响应路由到正确的实例，利用状态url参数。 Microsoft似乎建议在此链接中使用https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/authenticate我不确定ADAL是否允许我们为返回子域url设置状态。这种方法常见吗？
• 3）我们客户端目录中的每个ServiceProvider实例是否可以将回复URL配置到他们自己的子域？我觉得这将是最干净的方法，但我没有看到它的文档。如果我们也可以以编程方式设置replyURL，那就太好了。

℃。如何管理Graph API（AzureAD和Microsoft Graph）的授权

我注意到以下选项：

• 1）使用客户端凭据流，使用单个应用程序密钥（用于所有客户端）。在客户订阅时，他们将通过我们的应用程序获得管理员同意，以向其目录授予应用程序权限当然，我们会尽力保证密钥的安全。但如果由于某种原因它被泄露，这将使我们所有的客户面临风险，而不仅仅是受到损害的一个实例。
• 2）与1相同，但使用证书而不是密钥。我知道这可能会更安全一点，但我不知道它不会像1那样遭受同样的问题。
• 3）不使用应用程序权限，而是使用admin用户的委派权限。这样做会很好，因为它固有地阻止我们的应用程序的一个实例与错误的目录通话。但是，管理员的更改可能会中断服务;而且我认为审计最好的是我们的应用程序负责它所做的更改。 （另外，委派权限是否允许密码重置？我知道您需要运行PowerShell脚本以升级应用程序的目录角色的应用程序权限）
• 4）服务主体是否有某种方法可以在创建时为其创建一个唯一的密钥？可以通过编程方式将其传回我们的应用程序吗？也许在管理员同意期间？

Answer 1

真的好问题。我将尝试尽我所能回答每个问题，但如果有人有其他想法，请随时评论/添加自己的答案。

  

一个。使用哪个应用程序版本

v2应该允许您调用Azure AD Graph API。您链接的文档显示了指定Azure AD Graph范围的示例：

  

获取https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&scope=https%3A%2F%2Fgraph.windows.net%2Fdirectory.read%20https%3A%2F2Fgraph.windows.net%2Fdirectory.write

您应该使用v2的主要决策点是：您是否需要支持不在Azure AD中的Microsoft帐户？如果是，则需要使用v2。否则使用v1没有问题（好吧，缺乏动态权限）。

由于您使用Azure AD Graph修改内容，我猜测纯Microsoft帐户不适用于您。 我建议坚持使用v1。

v2也有一些限制：https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations

  

B中。当我们的客户有不同的子域时，如何管理回复URL？

我找不到有关网址限制的文档。可能你可以添加许多你想要的东西。但我不确定:)）

如果您的子域名如下所示：https://customer.product.com，您可以将回复网址配置为：

https://*.product.com

然后它将允许在redirect_uri。

中指定任何子域

虽然请注意，在撰写本文时，v2 不支持通配符回复网址。

  

℃。如何管理Graph API（AzureAD和Microsoft Graph）的授权

使用多个密钥是没有意义的，因为它们都是平等的:)任何一个都可以用来呼叫另一个租户。

您可以将密钥/证书存储在Azure密钥保管库中，然后使用Azure AD Managed Service Identity在应用启动时获取它。

我更喜欢使用委派权限，但如果应用的用户无权执行您的应用需要执行的操作，那么这不起作用。

我只是确保客户的实例无法使用其他租户ID调用API。并且还要确保令牌缓存以这样的方式分离，即不可能获得另一个租户的访问令牌（实例上的内存缓存会很好）。