0

在 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？

4

1 回答 1

4

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

ruby-saml 实现了服务提供者 (SP) 方面。关于 SAML规范

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

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

4.4.4.1 使用

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

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

  1. 服务提供者必须LogoutResponse在前通道 SLO 中使用 POST/Redirect 绑定对注销响应 ( ) 进行签名。如果允许此响应未签名，则该库违反规范。从规范：

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

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

  1. 服务提供者希望在其从身份提供者处收到的响应上得到签名。响应消息的结构是这样的，即有一个包含 Assertion 元素的整体 Response 元素。规范要求响应或断言或响应和断言都已签名。

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

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

第 3 节 - 签名处理

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

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

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

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

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

所以真正令人震惊的问题是允许 LogoutRequest 和 LogoutResponse 去签名。

于 2019-08-23T03:42:45.850 回答