REST API和消息级安全性

Question

我需要在REST API中实现消息级安全性并且有一些问题和疑问.我在这里找到了答案: Rest Web服务中的消息级安全性

只是部分有用.

我们目前支持标准SSL传输安全性和多种身份验证方法,包括

• 基本的http auth(与我们的API对话的一些网络设备服务所需)
• HMAC具有SHA1和SHA256风格的预共享密钥.
• 客户身份证书发送@TLS级别.
• SAML 2.0

我们为什么需要消息级安全性,因为

• 客户行业包括医疗保健,金融和政府等,他们经常对SSL不满.
• 需要保证端到端的安全性.通过反向代理,SSL加速器等......
• 通过服务传递的一些数据将包括非常敏感的数据.
• 需要为坚持SOAP的WS-*安全标准是"企业实力"Web服务和REST API的客户提供良好的答案.

如果客户端应用程序了解如何处理包络响应,我最初的想法是使用PKCS#7信封作为选项.

我希望客户端应用程序告诉API他们想要一个安全的响应,或者告诉API他们正在POST消息或PUTing的消息是安全的.

我真正的问题是,这应该通过媒体类型传达吗？例如:

• Content-Type:application/vnd.resourcetype1 + json + pkcs7
• 内容类型:txt/csv + pkcs7

我不想丢失有关媒体类型的信息.

它变得复杂,因为在某些情况下签名就足够了.其他人也需要加密.关于如何构造信封,术语"pkcs7"含糊不清.

我希望客户端和服务器通过标准HTTP头告诉对方他们发送的内容类型以及他们理解的内容类型.

Answer 1

当然，如何定义 API 取决于您，没有正确或错误的方法，但是S/MIME是一种很好理解的消息格式，非常适合互联网。如果您更喜欢分散的信任层次结构，则PGP/MIME也是如此。由于这些是易于理解的格式，因此客户端将允许采用现有的库来处理这些消息体。

如果您坚决不想使用多部分响应，则除了 Content-Type 之外，您可能还需要查看Content-Encoding标头。然后，您可以将签名/加密格式指定为自定义编码类型。

使用 HTTP 作为应用程序协议而不仅仅是传输协议有显着的好处，但您似乎已经了解了这一点。确保正确设置和解析 Accept* 标头，包括 q 值。请注意诸如默认值 q=1（表示相等（非降序）偏好）和 q=0 之类的情况。