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

Question

现状

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

我在网上看到过各种例子，人们使用 [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 设置为身份验证的结果，您就可以使用不同的身份验证方式。如果您有两个处理程序(或 HttpModules 在 Web 托管的情况下)或身份验证过滤器在 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。