REST API和消息级安全性

Question

我需要在REST API中实现消息级安全性，并且有一些问题和疑问。我在这里找到了答案： Message Level Security in Rest Web services

只是部分有用。

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

• 基本的http auth（某些网络设备服务需要 与我们的API联系）
• HMAC，具有SHA1和SHA256风格的预共享密钥。
• 发送@TLS级别的客户端身份证书。
• SAML 2.0

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

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

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

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

我真正的问题是，这应该通过媒体类型传达吗？ E.g：

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

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

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

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

Answer 1

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

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

使用HTTP作为应用程序协议而不仅仅是传输协议有很多好处，但您似乎已经理解了这一点。确保正确设置和解析Accept *标头，包括q值。谨防诸如q = 1的默认值意味着相等（不是降序）偏好，并且q = 0。