ruby - 为什么有人会将 ruby​​-saml gem 请求/响应的证书签名设置为 false？

Question

在 ruby​​-saml gem 中，我们有以下选项配置来决定是否签署某些请求/响应:

  settings.security[:authn_requests_signed]   = true     # Enable or not signature on AuthNRequest
  settings.security[:logout_requests_signed]  = true     # Enable or not signature on Logout Request
  settings.security[:logout_responses_signed] = true     # Enable or not signature on Logout Response
  settings.security[:want_assertions_signed]  = true     # Enable or not the requirement of signed assertion
  settings.security[:metadata_signed]         = true     # Enable or not signature on Metadata

使用证书将确保我们正在与我们认为正在交谈的人交谈。为什么有人想将这些配置设置为 false？

Answer 1

这是 SAML 实现的常见问题。虽然在某些情况下签名在协议(protocol)级别是合法可选的，但在其他情况下它不是可选的......但遗憾的是实现允许这样做。

ruby-saml 实现了服务提供商 (SP) 方面。关于 SAML spec

1. 服务提供商可以签署身份验证请求 ( AuthNRequest )。该协议(protocol)允许对身份验证请求进行未签名。此设置还通知可选 AuthnRequestsSigned 的值库生成的 SAML 元数据中的属性；该属性向身份提供商传达服务提供商是否要签署请求的信息。最佳实践 - 签署请求。

2. 服务提供商必须在前端 channel SLO 中签署注销请求 ( LogoutRequest )。如果该库允许未签署此请求，则它违反了规范。从规范来看:

4.4.4.1 Usage

The requester MUST authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism.

虽然某些实现坚持认为 https 可以被视为特定于绑定(bind)的机制，但服务器端 https 确实提供了传输中的消息完整性，但它肯定不会对请求者进行身份验证。签名是一个更有力的保证，确保请求者不是某个随机的第三方向身份提供者发送类似 DoS 的注销请求。

服务提供商必须使用 POST/Redirect 绑定(bind)在前端 channel SLO 中签署注销响应 ( LogoutResponse )。如果该库允许未签名此响应，则它违反了规范。从规范来看:

Section 4.4.3.4 Session Participant/Authority Issues <LogoutResponse> to Identity Provider

The <LogoutResponse> message MUST be signed if the HTTP POST or Redirect binding is used.

服务提供商希望在从身份提供商处收到的响应上签名。响应消息的结构是这样的:有一个整体的 Response 元素，其中包括一个 Assertion 元素。该规范要求响应或断言或响应和断言都经过签名。

此设置还通知可选 WantAssertionsSigned 的值库生成的 SAML 元数据中的属性；此属性向身份提供者传达服务提供者是否希望除了规范要求的任何签名之外还对断言进行签名。许多商业身份提供商会同时签署断言和响应，但有些只会签署其中之一。

SAML metadata spec建议对元数据进行签名。

Section 3 - Signature Processing

Various elements in a metadata instance can be digitally signed (as indicated by the element's inclusion of a <ds:Signature> element), with the following benefits:

• Metadata integrity
• Authentication of the metadata by a trusted signer

A digital signature is not always required, for example if the relying party obtains the information directly from the publishing entity directly (with no intermediaries) through a secure channel, with the entity having authenticated to the relying party by some means other than a digital signature.

Many different techniques are available for "direct" authentication and secure channel establishment between two parties. The list includes TLS/SSL, HMAC, password-based mechanisms, etc. In addition, the applicable security requirements depend on the communicating applications. Additionally, elements can inherit signatures on enclosing parent elements that are themselves signed.

In the absence of such context, it is RECOMMENDED that at least the root element of a metadata instance be signed.

因此，真正令人震惊的问题是允许 LogoutRequest 和 LogoutResponse 未签名。