| description |
|---|
本博客采用知识共享署名 4.0 国际许可协议进行许可 |
SAML断言、SAML协议请求和响应消息都可能被签名，这样做有以下好处。被断言机构签名的断言支持断言完整性验证、支持SAML依赖方对断言方的身份认证，并且如果签名是基于SAML机构（断言方）的公私钥对，那么还具有不可抵赖性。由消息发起者签名的SAML协议请求和响应消息支持消息完整性、消息源到目的地的身份认证、并且如果签名是基于发起者的公私钥对的话，还支持消息源的不可抵赖性。
译者（义臻）注：网络安全中关注的几个关键特性：认证性、完整性、机密性、不可抵赖性
在SAML中，数字签名并不总是必须的。例如，在一些场景下，签名可以被“继承“，比如一个未签名的断言使用其包含的协议响应消息的签名来获取保护。当被包含的对象（如断言）具有非短暂的生命周期时，应谨慎使用“继承的”签名。原因是必须保留整个上下文以允许验证，这样会暴露XML的内容并增加不必要的开销。再举一个例子，SAML依赖方或者SAML请求方可能已经从SAML断言方或SAML响应方那里直接地（没有中间人）通过安全通道获得了断言或协议消息，并且，SAML断言方或响应方已经向依赖方或者请求方认证了自己的身份，只不过是使用了数字签名之外的认证方式。
许多不同的技术都可用于双方之间的“直接”身份验证和安全通道建立。这里包括了TLS/SSL（参考[RFC 2246]/[SSL3]）、HMAC（消息认证码）、password-based mechanisms（基于密码的认证机制）等等。除此之外，应用的安全需求取决于需要通信的应用以及传输的断言或消息的性质。建议在所有其他情况下，要将数字签名用于断言以及请求和响应消息。
具体来说：
-
SAML依赖方从SAML断言方以外的实体获得的SAML断言应由SAML断言方签名。
-
从消息发送源以外的实体到达目的地的SAML协议消息应该由发送源签名。
-
配置文件可以指定替代的签名机制，例如S/MIME或包含SAML文档的签名Java对象。使用关于保留上下文和互操作性的警告。XML签名旨在成为主要的SAML签名机制，但本规范试图确保与可能需要其他机制的配置文件保持兼容。
-
除非配置文件指定了可替代的签名机制，否则的话，任何XML数字签名都必须封装。