10

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

只是部分有用。

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

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

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

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

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

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

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

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

我不想泄露有关被封装的媒体类型的信息。

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

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

4

1 回答 1

1

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

如果您不希望使用多部分响应，则可能需要查看Content-Encoding标头，而不仅仅是 Content-Type。然后，您可以将签名/加密格式指定为自定义编码类型。

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

于 2012-12-05T13:51:19.873 回答