为什么有人会将 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 实施的常见问题。虽然在某些情况下签名在协议级别是合法可选的，但在其他情况下它不是可选的......但遗憾的是实现允许这样做。

ruby-saml 实现了服务提供商（SP）方面。关于 SAML规范

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

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

4.4.4.1 使用

请求者必须向响应者验证自己的身份，并通过对消息进行签名或使用特定于绑定的机制来确保消息完整性。

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

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

第 4.4.3.4 节 会话参与者/<LogoutResponse> 身份提供商的权限问题

<LogoutResponse>如果使用 HTTP POST 或重定向绑定，则必须对消息进行签名。

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

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

5. SAML元数据规范建议对元数据进行签名。

第 3 节 - 签名处理

元数据实例中的各种元素都可以进行数字签名（如元素包含的元素所示<ds:Signature>），具有以下优点：

• 元数据完整性
• 由受信任的签名者对元数据进行身份验证

并不总是需要数字签名，例如，如果依赖方通过安全通道直接（没有中介）从发布实体直接获取信息，并且该实体已通过数字签名以外的某种方式向依赖方进行了身份验证。

许多不同的技术可用于两方之间的“直接”身份验证和安全通道建立。该列表包括 TLS/SSL、HMAC、基于密码的机制等。此外，适用的安全要求取决于通信应用程序。此外，元素可以继承自身签名的封闭父元素上的签名。

如果没有这样的上下文，建议至少对元数据实例的根元素进行签名。

因此，真正严重的问题是允许 LogoutRequest 和 LogoutResponse 未签名。