authentication - 同一 ASP.NET Web API 的不同身份验证方案

Question

情况

我有一个即将进行的项目，其中网页将进行 AJAX 调用。还将向外部客户端提供 REST API。我将使用 ASP.NET MVC 4 和 Web API 来实现这个项目。

我在网上看到了各种示例，人们使用 [Authorize] 属性来确保安全。我认为每当通过 AJAX 在网页上调用 Web API 时就会发生这种情况。

我还看到了各种示例，其中 API key 随每个请求一起传递(通过查询字符串或 header )。我认为每当从外部系统调用 Web API 时就会发生这种情况。

问题

以下是立即浮现在我脑海中的问题:

• 我应该为内部和外部客户端创建单独的 Controller 吗？
• 或者我应该强制网页使用相同的外部身份验证模型吗？
• 或者外部客户端是否可以使用 Authorize 属性？
• 或者我应该以某种方式同时支持表单或身份验证？

旁注

一位同事指出，我可能希望将 API 部署到与托管 Web 应用程序的位置完全不同的 URL。同样，他指出外部 API 可能需要更粗粒度或单独发展。

我不想在这里重新发明轮子。这让我想知道是否应该首先使用 Web API 作为 AJAX 调用的内部 API，或者是否应该坚持使用带有 [HttpPost] 属性的老式 MVC 操作。

Answer 1

[Authorize] 属性不仅仅适用于 Ajax。当您应用 [Authorize] 属性来表示操作方法时，它的作用是确保在操作方法运行之前对身份进行身份验证，无论客户端发出请求，也无论请求的类型如何提交给您的 API 的凭据。它寻找的只是Thread.CurrentPrincipal。以下是从 Authorize 过滤器复制粘贴的代码。

protected virtual bool IsAuthorized(HttpActionContext actionContext)
{
    ...
    IPrincipal user = Thread.CurrentPrincipal;
    if (user == null || !user.Identity.IsAuthenticated)
    {
        return false;
    }
    ...
}

如您所见，它所做的一切都是获取 Thread.CurrentPrincipal 并检查身份是否经过身份验证。当然，当您包含角色时，还会进行额外的检查。

因此，这意味着只要将 Thread.CurrentPrincipal 设置为身份验证结果，您就可以使用不同的身份验证方式。如果您有两个处理程序(或者在 Web 托管的情况下为 HttpModules)或在 Web API 2 的情况下有身份验证过滤器，您可以根据不同因素建立身份。例如，您可以将一个 BasicAuthnHandler 和一个 ApiKeyHandler 添加到 config.Handlers 中，从而在 Web API 管道中依次运行。他们可以做的是查找凭据并设置 Thread.CurrentPrincipal 。如果 Authorize header 出现在基本方案中，BasicAuthnHandler 将进行身份验证并设置 Thread.CurrentPrincipal，如果 API key 出现，则不会执行任何操作，并且ApiKeyHandler 设置Thread.CurrentPrincipal。两个处理程序都可以创建相同类型的主体，例如 GenericPrinicpal 甚至不同的主体。这并不重要，因为所有主体都必须实现 IPrincipal。因此，当 Authorize 过滤器运行时，Thread.CurrentPrincipal 将被设置，并且无论您如何进行身份验证，授权都将起作用。注意:如果您是网络托管服务商，除了 Thread.CurrentPrincipal 之外，您还需要设置 HttpContext.User。