数字签名在遭遇十年多的冷遇后重新回到了我们的视野。这次回归归因于复合应用的出现,复合应用在移动领域中又称为聚合应用。复合应用是一场架构的盛宴,组成复合应用的部分和服务分属不同拥有者的不同域,由不同的团队开发,有着不同的发布周期,使用不同的技术,具有不同的伸缩性、可用性或安全模型。
信任是复合应用的核心问题之一。从身份识别和访问权限的角度来说,所有协同工作的部分和服务都需要彼此信任,以便交付共同的解决方案,这些部分和服务也经常会组成涉及范围颇广的解决方案。鉴于此,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
评论