针对 HTTP 数字签名协议和 API 的提议

  • Jean-Jacques Dubray
  • 王丽娟

2011 年 2 月 21 日

话题:REST安全架构语言 & 开发

数字签名在遭遇十年多的冷遇后重新回到了我们的视野。这次回归归因于复合应用的出现,复合应用在移动领域中又称为聚合应用。复合应用是一场架构的盛宴,组成复合应用的部分和服务分属不同拥有者的不同域,由不同的团队开发,有着不同的发布周期,使用不同的技术,具有不同的伸缩性、可用性或安全模型。

信任是复合应用的核心问题之一。从身份识别和访问权限的角度来说,所有协同工作的部分和服务都需要彼此信任,以便交付共同的解决方案,这些部分和服务也经常会组成涉及范围颇广的解决方案。鉴于此,HTTP 的核心问题之一就是,HTTP 的认证机制会假定一个由请求处理器验证的单一身份(一个用户或一台服务器)。这样,建立请求涉及各方的身份识别就是 HTTP 最大的困难,比如使用应用胖 / 瘦客户端的用户、构建应用的某开发人员。随着大型“独立供应商”将他们受信任的服务逐渐暴露给几乎所有的开发人员,这种情况变得越来越普遍。问题继而成为,HTTP 该如何附带用户、客户端、应用(类型)或应用开发人员的身份识别信息?

Bill Burke提议对 HTTP 协议进行扩展,以支持数字签名和 RESTEasy 里对应的 API。他解释道:

签名确实是OAuth协议的一部分,但我曾经希望与认证互相垂直的某些内容能作为客户端、而服务器可以不用 OAuth 进行认证。
我们希望协议能具备以下目标和功能:
  • 简单的头信息。所有的签名信息都存储在 HTTP 请求或响应头中。这通常能简化框架、客户端、服务器代码对签名的验证。
  • 过期。我们希望能让签名过期。
  • 签名者的信息。我们想知道是谁对消息进行了签名。这可以让接收者在内部注册表里查找验证键值。
  • 你要是不关心签名信息,可以忽略它。
  • 可以将消息和请求转发到多个端点或接收者。
  • 允许多个不同的 URL 发布相同的签名消息。
  • 这并不意味着要去取代能保证消息完整性的 OAuth 或 Digest 协议。

基于 DSig 的协议有个很主要的优势——断定身份的同时还能创建消息内容的防篡改信封,这两个功能通常都要求同时出现。

Bill 建议创建一个特定的 HTTP 头 Content-Signature,示例如下:

Content-Signature: type=redhat;
                   values=signer:expiration;
                   headers=Content-Type:Date;
                   signer=bill;
                   expiration="Sunday, 06-Nov-11 08:49:37 GMT";
                   signature=0f341265ffa32211333f6ab2d1

真正的问题与其说是如何采用包含数字签名的 HTTP 协议(这仅仅是个“消息信封”的问题),还不如说是“业界该如何解决阻碍 DSig 推广的问题”,特别是互操作性问题。你有没有发现对 HTTP 里的认证和防篡改机制有了越来越多的需求?你找到什么解决方案了么?

查看英文原文:A Proposal for an HTTP Digital Signature Protocol and API

REST安全架构语言 & 开发