在 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？
这是 SAML 实现的常见问题。虽然在某些情况下，签名在协议级别是合法可选的，但在其他情况下，它不是可选的......然而不幸的是，实现允许这样做。
Ruby-SAML 实现了服务提供商 (SP( 方面。关于 SAML 规范
-
服务提供商可以签署身份验证请求 (
AuthNRequest(。该协议允许对身份验证请求进行未签名。 此设置还会通知库生成的 SAML 元数据中可选AuthnRequestsSigned属性的值;此属性将服务提供程序是否要对请求进行签名，从而与身份提供程序进行通信。最佳做法 - 对请求进行签名。 -
服务提供商必须在前通道 SLO 中签署注销请求 (
LogoutRequest(。如果库允许此请求未签名，则违反了规范。从规格：
4.4.4.1 用法
请求者必须向响应者验证自身并确保 消息完整性，通过对消息进行签名或使用 特定于绑定的机制。
虽然一些实现坚持认为 https 可以被认为是特定于绑定的机制，但服务器端 https 确实在传输中提供了消息完整性，但它肯定不会对请求者进行身份验证。签名可以更有力地保证请求者不是向身份提供程序发送类似 DoS 的注销请求的随机第三方。
- 服务提供商必须使用开机自检/重定向绑定在前通道SLO中对注销响应(
LogoutResponse(进行签名。如果库允许此响应未签名，则违反了规范。从规格：
第 4.4.3.4节 会话参与者/授权
<LogoutResponse>问题 到身份提供程序
<LogoutResponse>如果 HTTP POST 或 使用重定向绑定。
- 服务提供商期望从身份提供程序收到的响应具有签名。响应消息的结构使得有一个包含断言元素的整体响应元素。规范要求对响应或断言或响应和断言进行签名。
此设置还会通知库生成的 SAML 元数据中可选WantAssertionsSigned属性的值;此属性与身份提供程序通信，除了规范所需的任何签名之外，服务提供商是否还希望对断言进行签名。许多商业标识提供者会同时签署断言和响应，但有些只会签署其中任何一个。
- SAML 元数据规范建议对元数据进行签名。
第 3 部分 - 签名处理
元数据实例中的各种元素都可以进行数字签名(如 由元素包含
<ds:Signature>元素表示(， 具有以下好处：
- 元数据完整性
- 由可信签名者对元数据进行身份验证
数字签名并不总是必需的，例如，如果依赖 一方直接从发布实体获取信息 直接(没有中介(通过安全通道，与 已通过其他方式向信赖方进行身份验证的实体 而不是数字签名。
许多不同的技术可用于"直接"身份验证 并在双方之间建立安全渠道。目录 包括 TLS/SSL、HMAC、基于密码的机制等。另外 适用的安全要求取决于通信 应用。此外，元素可以继承签名 将本身已签名的父元素括起来。
在没有这种上下文的情况下，建议至少 对元数据实例的根元素进行签名。
因此，真正令人震惊的问题是允许 LogoutRequest 和 LogoutResponse 未签名。