在设计REST API或服务时,是否有处理安全性(身份验证、授权、身份管理)的最佳实践?

在构建SOAPAPI时,您可以将WS-Security作为指南,并且有许多关于该主题的文献。我发现关于保护REST端点的信息较少。

虽然我理解REST故意没有类似于WS-*的规范,但我希望已经出现了最佳实践或推荐的模式。

如有任何讨论或相关文件的链接,我们将不胜感激。如果重要的话,我们将使用WCF和POX/JSON序列化消息,用于使用.NET Framework v3.5构建的REST API/服务。


当前回答

因为@Nathan最后得到了一个简单的HTTP Header,有些人说OAuth2和客户端SSL证书。其要点是。。。您的RESTAPI不应该处理安全性,因为这确实超出了API的范围。

相反,无论是web代理后面的HTTP头(一种常见的方法,如SiteMinder、Zermatt甚至Apache HTTPd),还是像OAuth 2一样复杂,都应该在其上面设置一个安全层。

关键是请求应该在没有任何最终用户交互的情况下工作。所需要的就是确保与RESTAPI的连接经过身份验证。在JavaEE中,我们有一个userPrincipal的概念,它可以在HttpServletRequest上获得。它也在部署描述符中管理,URL模式可以是安全的,因此RESTAPI代码不再需要检查。

在WCF世界中,我将使用ServiceSecurityContext.Current获取当前安全上下文。您需要将应用程序配置为需要身份验证。

我上面的声明有一个例外,那就是使用随机数来防止重放(可能是攻击,也可能是某人提交了两次相同的数据)。该部分只能在应用程序层中处理。

其他回答

因为@Nathan最后得到了一个简单的HTTP Header,有些人说OAuth2和客户端SSL证书。其要点是。。。您的RESTAPI不应该处理安全性,因为这确实超出了API的范围。

相反,无论是web代理后面的HTTP头(一种常见的方法,如SiteMinder、Zermatt甚至Apache HTTPd),还是像OAuth 2一样复杂,都应该在其上面设置一个安全层。

关键是请求应该在没有任何最终用户交互的情况下工作。所需要的就是确保与RESTAPI的连接经过身份验证。在JavaEE中,我们有一个userPrincipal的概念,它可以在HttpServletRequest上获得。它也在部署描述符中管理,URL模式可以是安全的,因此RESTAPI代码不再需要检查。

在WCF世界中,我将使用ServiceSecurityContext.Current获取当前安全上下文。您需要将应用程序配置为需要身份验证。

我上面的声明有一个例外,那就是使用随机数来防止重放(可能是攻击,也可能是某人提交了两次相同的数据)。该部分只能在应用程序层中处理。

我搜索了很多关于restful ws安全性的信息,最后我们通过cookie在客户端到服务器之间使用令牌来验证请求。我使用spring安全性来授权服务中的请求,因为我必须根据DB中已经存在的指定安全策略来验证和授权每个请求。

除了HTTP之外,没有其他REST标准。已经建立了REST服务。我建议你看一眼它们,感受一下它们是如何工作的。

例如,在开发自己的服务时,我们借鉴了亚马逊S3 REST服务的许多想法。但我们选择不使用基于请求签名的更高级的安全模型。更简单的方法是通过SSL进行HTTP基本身份验证。你必须决定什么最适合你的情况。

此外,我强烈推荐O'reilly的《RESTful Web Services》一书。它解释了核心概念,并提供了一些最佳实践。您通常可以使用他们提供的模型并将其映射到您自己的应用程序。

SOAP世界被安全标准覆盖得很好,这并不意味着默认情况下它是安全的。首先,标准非常复杂。复杂性不是安全性的好朋友,实现漏洞(如XML签名包装攻击)在这里很常见。

至于.NET环境,我不会有太大帮助,但“用Java构建web服务”(一个有约10位作者的砖)确实帮助我理解了WS-*安全体系结构,尤其是它的怪癖。

我想添加(与臭马特一致),最简单的解决方案是将SSL证书添加到您的站点。换句话说,确保您的url是HTTPS://。这将保障你的交通安全(一掷千金)。使用RESTfulurl,想法是保持它的简单性(不像WS*security/SAML),您可以使用oAuth2/openID连接,甚至可以使用Basic Auth(在简单的情况下)。但您仍然需要SSL/HTTPS。请在此处检查ASP.NET Web API 2安全性:http://www.asp.net/web-api/overview/security(文章和视频)