在设计REST API或服务时,是否有处理安全性(身份验证、授权、身份管理)的最佳实践?
在构建SOAPAPI时,您可以将WS-Security作为指南,并且有许多关于该主题的文献。我发现关于保护REST端点的信息较少。
虽然我理解REST故意没有类似于WS-*的规范,但我希望已经出现了最佳实践或推荐的模式。
如有任何讨论或相关文件的链接,我们将不胜感激。如果重要的话,我们将使用WCF和POX/JSON序列化消息,用于使用.NET Framework v3.5构建的REST API/服务。
这些答案中的每个人都忽略了真正的访问控制/授权。
例如,如果您的RESTAPI/web服务是关于发布/获取病历的,那么您可能需要定义访问控制策略,以确定谁可以访问数据以及在什么情况下访问数据。例如:
医生可以获取与他们有护理关系的患者的病历任何人都不能在练习时间之外(例如9到5)发布医疗数据最终用户可以获得他们拥有的病历或他们作为监护人的患者的病历护士可以更新与护士属于同一单位的患者的病历。
为了定义和实现这些细粒度授权,您需要使用一种基于属性的访问控制语言XACML,即可扩展访问控制标记语言。
其他标准如下:
OAuth:id。联合和授权委托,例如让一个服务代表我的另一个服务(Facebook可以发布到我的Twitter)SAML:身份联合/web SSO。SAML非常关注用户是谁。WS-Security/WS-*标准:这些标准关注SOAP服务之间的通信。它们特定于应用程序级消息传递格式(SOAP),它们处理消息传递的各个方面,例如可靠性、安全性、机密性、完整性、原子性、事件。。。没有一个涉及访问控制,所有都是特定于SOAP的。
XACML是技术不可知的。它可以应用于java应用程序、.NET、Python、Ruby。。。web服务、REST API等。
以下是有趣的资源:
OASIS XACML网站NIST ABAC标准
因为@Nathan最后得到了一个简单的HTTP Header,有些人说OAuth2和客户端SSL证书。其要点是。。。您的RESTAPI不应该处理安全性,因为这确实超出了API的范围。
相反,无论是web代理后面的HTTP头(一种常见的方法,如SiteMinder、Zermatt甚至Apache HTTPd),还是像OAuth 2一样复杂,都应该在其上面设置一个安全层。
关键是请求应该在没有任何最终用户交互的情况下工作。所需要的就是确保与RESTAPI的连接经过身份验证。在JavaEE中,我们有一个userPrincipal的概念,它可以在HttpServletRequest上获得。它也在部署描述符中管理,URL模式可以是安全的,因此RESTAPI代码不再需要检查。
在WCF世界中,我将使用ServiceSecurityContext.Current获取当前安全上下文。您需要将应用程序配置为需要身份验证。
我上面的声明有一个例外,那就是使用随机数来防止重放(可能是攻击,也可能是某人提交了两次相同的数据)。该部分只能在应用程序层中处理。