SAML Security Cheat Sheet / SAML安全速查表

Introduction / 介绍

The Security Assertion Markup Language (SAML) is an open standard for exchanging authorization and authentication information. The Web Browser SAML/SSO Profile with Redirect/POST bindings is one of the most common SSO implementation. This cheatsheet will focus primarily on that profile.

安全断言标记语言（SAML）是一个用于交换授权和认证信息的开放标准。SAML 的 Web浏览器SAML/SSO配置文件，带有重定向/POST绑定 是最常见的SSO实现之一。本速查表将主要关注该配置文件。

Validate Message Confidentiality and Integrity / 验证消息机密性和完整性

TLS 1.2 is the most common solution to guarantee message confidentiality and integrity at the transport layer. Refer to SAML Security (section 4.2.1) for additional information. This step will help counter the following attacks:

• Eavesdropping 7.1.1.1
  中文：窃听 7.1.1.1
• Theft of User Authentication Information 7.1.1.2
  中文：用户认证信息盗窃 7.1.1.2
• Theft of the Bearer Token 7.1.1.3
  中文：载体令牌盗窃 7.1.1.3
• Message Deletion 7.1.1.6
  中文：消息删除 7.1.1.6
• Message Modification 7.1.1.7
  中文：消息篡改 7.1.1.7
• Man-in-the-middle 7.1.1.8
  中文：中间人攻击 7.1.1.8

A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to SAML Security (section 4.3) for additional information. This step will help counter the following attacks:

使用经过认证的密钥进行数字签名的消息是保证消息完整性和身份验证的最常见解决方案。有关更多信息，请参阅SAML安全（第4.3节）。此步骤有助于抵御以下攻击：

• Man-in-the-middle 6.4.2
  中文：中间人攻击 6.4.2
• Forged Assertion 6.4.3
  中文：伪造断言 6.4.3
• Message Modification 7.1.1.7
  中文：消息篡改 7.1.1.7

Assertions may be encrypted via XMLEnc to prevent disclosure of sensitive attributes post transportation. Refer to SAML Security (section 4.2.2) for additional information. This step will help counter the following attacks:

断言可以通过XMLEnc进行加密，以防止在传输后泄露敏感属性。有关更多信息，请参阅SAML安全（第4.2.2节）。此步骤有助于抵御以下攻击：

• Theft of User Authentication Information 7.1.1.2
  中文：用户认证信息盗窃 7.1.1.2

Validate Protocol Usage / 验证协议使用

This is a common area for security gaps - see Google SSO vulnerability for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider).

这是安全漏洞的常见领域 - 请参阅Google SSO漏洞的真实案例。他们的SSO配置文件容易受到恶意SP（服务提供商）发起的中间人攻击。

The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the SAML Profile usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack.

SSO Web浏览器配置文件最易受到受信任合作伙伴的攻击。这个特定的安全漏洞暴露出来，是因为SAML响应没有包含进行安全消息交换所需的所有数据元素。遵循SAML配置文件中AuthnRequest（4.1.4.1）和Response（4.1.4.2）的使用要求将有助于抵御这种攻击。

The AVANTSSAR team suggested the following data elements should be required:

AVANTSSAR团队建议以下数据元素应该是必需的：

• AuthnRequest(ID, SP): An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.
  中文：AuthnRequest(ID, SP): AuthnRequest必须包含ID和SP。其中ID是一个唯一标识请求的字符串，SP标识发起请求的服务提供者。此外，请求的ID属性必须在响应中返回（InResponseTo="<requestId>"）。InResponseTo有助于保证来自受信任的IdP的响应的真实性。这是Google的SSO易受攻击所缺失的一个属性。
• Response(ID, SP, IdP, {AA} K -1/IdP): A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.
  中文：响应(ID, SP, IdP, {AA} K -1/IdP): 响应必须包含所有这些元素。其中ID是一个唯一标识响应的字符串。SP标识响应的接收者。IdP标识授权响应的标识提供者。{AA} K -1/IdP是使用IdP的私钥数字签名的断言。
• AuthAssert(ID, C, IdP, SP): An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.
  中文：AuthAssert(ID, C, IdP, SP): 响应中必须存在一个认证断言。它必须包含ID、客户端(C)、身份提供者(IdP)和服务提供者(SP)`标识符。

Validate Signatures / 验证签名

Vulnerabilities in SAML implementations due to XML Signature Wrapping attacks were described in 2012, On Breaking SAML: Be Whoever You Want to Be.

由于XML签名包装攻击，SAML实现中的漏洞在2012年被描述在On Breaking SAML: Be Whoever You Want to Be中。

The following recommendations were proposed in response (Secure SAML validation to prevent XML signature wrapping attacks):

以下建议是对此做出的回应(Secure SAML validation to prevent XML signature wrapping attacks)：

• Without exception, always perform schema validation on the XML document prior to using it for any security-related purposes::
  中文：无例外，始终在将XML文档用于任何安全相关目的之前对其进行模式验证：
  • Always use local, trusted copies of schemas for validation.
    中文：始终使用本地、可信的架构副本进行验证。
  • Never allow automatic download of schemas from third party locations.
    中文：绝不允许从第三方位置自动下载架构。
  • If possible, inspect schemas and perform schema hardening, to disable possible wildcard type or relaxed processing statements.
    中文：如果可能，检查架构并执行架构加固，以禁用可能的通配符类型或宽松的处理语句。
• Securely validate the digital signature:
  中文：安全地验证数字签名：
  • If you expect only one signing key, use StaticKeySelector. Obtain the key directly from the identity provider, store it in a local file and ignore any KeyInfo elements in the document.
    中文：如果您预期只有一个签名密钥，请使用 StaticKeySelector。直接从身份提供者获取密钥，将其存储在本地文件中，并忽略文档中的任何 KeyInfo 元素。
  • If you expect more than one signing key, use X509KeySelector (the JKS variant). Obtain these keys directly from the identity providers, store them in local JKS and ignore any KeyInfo elements in the document.
    中文：如果您预期有多个签名密钥，请使用 X509KeySelector（JKS 变体）。直接从身份提供者获取这些密钥，将它们存储在本地 JKS 中，并忽略文档中的任何 KeyInfo 元素。
• Avoid signature-wrapping attacks.
  中文：避免签名封装攻击。
  • Never use getElementsByTagName to select security related elements in an XML document without prior validation.
    中文：绝不要在没有预先验证的情况下使用 getElementsByTagName 来选择 XML 文档中的安全相关元素。
  • Always use absolute XPath expressions to select elements, unless a hardened schema is used for validation.
    中文：始终使用绝对XPath表达式选择元素，除非使用强化模式进行验证。

Validate Protocol Processing Rules / 验证协议处理规则

This is another common area for security gaps simply because of the vast number of steps to assert.

这又是安全漏洞的常见区域，仅仅因为需要断言的步骤众多。

Processing a SAML response is an expensive operation but all steps must be validated:

处理SAML响应是一项昂贵的操作，但所有步骤都必须经过验证：

• Validate AuthnRequest processing rules. Refer to SAML Core (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:
  中文：验证AuthnRequest处理规则。有关所有AuthnRequest处理规则，请参阅SAML核心 (3.4.1.4)。此步骤将有助于抵御以下攻击：
  • Man-in-the-middle (6.4.2)
    中文：中间人攻击（6.4.2）
• Validate Response processing rules. Refer to SAML Profiles (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:
  中文：验证Response处理规则。有关所有Response处理规则，请参阅SAML配置文件 (4.1.4.3)。此步骤将有助于抵御以下攻击：
  • Stolen Assertion (6.4.1)
    中文：被盗断言（6.4.1）
  • Man-in-the-middle (6.4.2)
    中文：中间人攻击（6.4.2）
  • Forged Assertion (6.4.3)
    中文：伪造断言（6.4.3）
  • Browser State Exposure (6.4.4)
    中文：浏览器状态泄露（6.4.4）

Validate Binding Implementation / 验证绑定实现

• For an HTTP Redirect Binding refer to SAML Binding (3.4). To view an encoding example, you may want to reference RequestUtil.java found within Google's reference implementation.
  中文：对于HTTP重定向绑定，请参阅SAML绑定 (3.4)。要查看编码示例，您可以参考Google参考实现中找到的RequestUtil.java。
• For an HTTP POST Binding refer to SAML Binding (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.
  中文：对于HTTP POST绑定，请参阅SAML绑定 (3.5)。缓存考虑因素也非常重要。如果SAML协议消息被缓存，它随后可能被用作被盗断言(6.4.1)或重放攻击(6.4.5)。

Validate Security Countermeasures / 验证安全防护措施

Revisit each security threat that exists within the SAML Security document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation.

重新审视SAML安全文档中存在的每个安全威胁，并断言您已针对可能存在于特定实现中的威胁应用了适当的防护措施。

Additional countermeasures considered should include:

应考虑的其他防护措施包括：

• Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:
  中文：在适当的情况下优先使用IP过滤。例如，如果Google为每个受信任的合作伙伴提供单独的端点并为每个端点设置IP过滤器，则此防护措施可能阻止了Google最初的安全漏洞。这一步骤有助于抵御以下攻击：
  • Stolen Assertion (6.4.1)
    中文：被盗断言（6.4.1）
  • Man-in-the-middle (6.4.2)
    中文：中间人攻击（6.4.2）
• Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:
  中文：在SAML响应中优先使用较短的生存期。这一步骤有助于抵御以下攻击：
  • Stolen Assertion (6.4.1)
    中文：被盗断言（6.4.1）
  • Browser State Exposure (6.4.4)
    中文：浏览器状态泄露（6.4.4）
• Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:
  中文：在SAML响应中优先使用一次性使用。这一步骤有助于抵御以下攻击：
  • Browser State Exposure (6.4.4)
    中文：浏览器状态泄露（6.4.4）
  • Replay (6.4.5)
    中文：重放攻击（6.4.5）

Need an architectural diagram? The SAML technical overview contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.

Unsolicited Response (ie. IdP Initiated SSO) Considerations for Service Providers

Unsolicited Response is inherently less secure by design due to the lack of login CSRF protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user.

While this design does not make IdP-initiated SSO uniquely vulnerable to Man-in-the-Middle (MITM) attacks—those risks apply equally to SP-initiated flows if transport security is compromised—it does remove an important layer of login intent validation.

Despite these concerns, IdP-initiated SSO remains supported for backward compatibility (notably with SAML 1.1). If it must be enabled, the following steps (in addition to those mentioned above) should help secure this flow:

• Follow the validation process mentioned in SAML Profiles (section 4.1.5). This step will help counter the following attacks:
  中文：遵循SAML配置文件（第4.1.5节）中提到的验证流程。此步骤将有助于抵御以下攻击：
  • Replay (6.1.2)
  • Message Insertion (6.1.3)
• If the contract of the RelayState parameter is a URL, make sure the URL is validated and explicitly on an allowlist. This step will help counter the following attack:
  • Open Redirect) （开放重定向）
• Implement proper replay detection either at the response or assertion level. This will help counter the following attack:
  中文：在响应或断言级别实施适当的重放检测。这将有助于抵御以下攻击：
  • Replay (6.1.2)

Identity Provider and Service Provider Considerations / 身份提供者和服务提供者注意事项

The SAML protocol is rarely the attack vector of choice, though it's important to have cheatsheets to make sure that this is robust. The various endpoints are more targeted, so how the SAML token is generated and how it is consumed are both important in practice.

虽然SAML协议很少是首选的攻击向量，但拥有cheatsheets来确保其稳健性是很重要的。各种端点更具针对性，因此SAML令牌的生成方式和消费方式在实践中都同样重要。

X.509 Certificate Considerations / X.509证书注意事项

Typically the security association between the Identity Provider (IdP) and Service Provider (SP) is created when the SP explicitly chooses to trust the IdP's X.509 signing certificate. Exactly how this occurs can have a strong bearing on overall security posture. How the certificate is generated, what the contents of the certificate are, and how the certificate's corresponding private key is protected all have strong bearing on security posture. e.g., if an attacker has access to use the IdP’s signing key, they can mint SAML responses containing any assertion they wish.

通常，当服务提供者（SP）明确选择信任身份提供者（IdP）的X.509签名证书时，会在IdP和SP之间创建安全关联。这种关联的确切创建方式对整体安全态势有重大影响。证书的生成方式、证书内容以及证书对应的私钥保护方式都对安全态势有重大影响。例如，如果攻击者能够访问使用IdP的签名密钥，他们可以创建包含任何他们想要的断言的SAML响应。

In many cases, the method of manually setting the association is akin to Certificate Pinning, which is not ideal. Depending on the IdP and SP software, or various design considerations, this may be unavoidable.

在许多情况下，手动设置关联的方法类似于证书固定，这并不是理想的做法。根据IdP和SP软件或各种设计考虑，这可能不可避免。

Keep in mind that the certificate's signature type can be different from that of the XML document signing type. The certificate's corresponding private key is the only key that can be used to sign the XML document, but the signing algorithm is chosen at the IdP's discretion. The most commonly supported signing algorithm is rsa-sha256.

请注意，证书的签名类型可能与XML文档签名类型不同。证书对应的私钥是唯一可以用来签名XML文档的密钥，但签名算法是由IdP选择的。最常用的签名算法是rsa-sha256。

SAML Parties vs Organizations / SAML参与方与组织

The most common SAML use cases are those of business-to-business (B2B). This means that the two parties have different security polices, practices, and risk tolerances. This guidance focuses mainly on the B2B use case. However SAML based federation or SSO is commonly used inside of an organization. In this case the term third-party CA does not apply. It is likely that the CA has been built and run to company standards and it poses no more or less risk to the SAML systems. The term third-party CA is meant to indicate a private CA run by a third-party.

最常见SAML用例是业务对业务（B2B）。这意味着双方有不同的安全策略、实践和风险容忍度。本指南主要关注B2B用例。然而，基于SAML的联合或单点登录（SSO）通常在组织内部使用。在这种情况下，第三方CA的概念不适用。很可能CA是根据公司标准构建和运行的，它对SAML系统没有更多或更少的风险。第三方CA这一术语旨在表明由第三方运行的私有CA。

Certificate Use Cases / 证书用例

There are actually 5 separate use cases for certificates in a SAML system. While this document mainly talks about the IdP’s SAML signing certificate, the security considerations apply to all four SAML related certificates. The fifth certificate, the IdP’s TLS server certificate is no more or less special than any other server certificate.

实际上，SAML系统中证书有5个单独的用例。虽然本文档主要讨论身份提供者（IdP）的SAML签名证书，但安全考虑适用于所有四个与SAML相关的证书。第五个证书，即IdP的TLS服务器证书，与其他服务器证书没有更多或更少的特殊性。

IdP SAML Signing / IdP SAML签名

This is the certificate that an SP uses to validate an IdD’s SAML response. The IdP signs that response with the certificate’s corresponding private key. This is often the most important certificate and private key, as this protects the identity assertions being sent to the SP.

这是服务提供者（SP）用来验证身份提供者（IdD）的SAML响应的证书。IdP使用证书对应的私钥对该响应进行签名。这通常是最重要的证书和私钥，因为它保护了发送到SP的身份断言。

IdP SAML Encryption / IdP SAML加密

This is less commonly used, as this is used when the SP wants to protect the SAML request sent to the IdP, not just from tampering, but from information disclosure. There should be no sensitive information in the SAML request, so it is less commonly used. If used, the certificate and private key must be different from that of the SAML signing certificate.

这不太常用，因为它用于当SP想要保护发送到IdP的SAML请求，不仅是为了防止篡改，也是为了防止信息泄露。SAML请求中不应包含敏感信息，因此它不太常用。如果使用，证书和私钥必须与SAML签名证书不同。

SP Signing / SP签名

It is a best practice, though not required, that SPs and IdPs not allow IdP Initiated SSO. This means that the caller starts their SAML flow at the SP, which produces a signed SAML request intended for the IdP.

虽然不是强制要求，但最佳实践是SP和IdP不允许IdP发起的SSO。这意味着调用者从SP开始他们的SAML流程，SP生成一个针对IdP的已签名SAML请求。

SP Encryption / SP加密

It is a best practice to avoid placing sensitive data in the IdP’s SAML response, but sometimes it is unavoidable. This could be usernames or other PII. When information disclosure is a consideration, an SP will have a SAML encryption certificate. The IdP will use this and the embedded public key, in order to encrypt the SAML response. The SP must use a separate certificate and key pair for SAML signing and encryption.

最佳实践是避免在IdP的SAML响应中放置敏感数据，但有时这是不可避免的。这可能包括用户名或其他PII。当考虑信息泄露时，SP将有一个SAML加密证书。IdP将使用这个证书和嵌入的公钥来加密SAML响应。SP必须使用单独的证书和密钥对进行SAML签名和加密。

Certificate Contents / 证书内容

In the context of SAML signing and encryption, X.509 certificates are most often treated simply as a wrapper to hold a public key that is used to verify a signature, or to wrap a symmetric key for SAML encryption. Nonetheless, a certificate can contain attributes that can be used to further enhance security.

在SAML签名和加密的上下文中，X.509证书通常被简单地视为一个包装器，用于持有用于验证签名或包装用于SAML加密的对称密钥的公钥。尽管如此，证书可以包含可以用于进一步增强安全性的属性。

OWASP recommends that IdPs and SPs move to adopt the EKU, KU, and key lifetimes mentioned below. These legitimately enhance security and allow the verifying party to further protect themselves. They also help show compliance with PKI norms.

OWASP建议IdP和SP采用以下提到的EKU、KU和密钥有效期。这些措施合法地增强了安全性，并允许验证方进一步保护自己。它们还有助于展示符合PKI规范。

Keys and Signing Algorithms / 密钥和签名算法

The key pair size and type and signing algorithm choice has strong bearing on security and interoperability. Not all IdP and SP software packages or libraries support all combinations of options. As one IdP often has many SPs associated with it, the only option is to pick the least secure option that is still considered secure. The most supported and currently secure combination is using RSA 2048 bit keys and SHA-256 hashing/signing. This is referring to the certificate’s signing algorithm and not the SAML XML signing.

密钥对的大小、类型和签名算法的选择对安全性和互操作性有重要影响。并非所有身份提供者（IdP）和服务提供者（SP）的软件包或库都支持所有选项的组合。由于一个身份提供者通常与许多服务提供者相关联，唯一的选择是选择仍然被认为是安全的最低安全选项。目前最支持且安全的组合是使用2048位RSA密钥和SHA-256散列/签名。这指的是证书的签名算法，而不是SAML XML签名。

As post-quantum algorithms become more prevalent, and ultimately required, this becomes even more complex. Those writing SAML SP and IdP software should begin looking at options to support more key and signing algorithms.

随着量子算法变得越来越普遍，最终成为必需，这变得更加复杂。编写SAML SP和IdP软件的人应该开始寻找支持更多密钥和签名算法的选项。

Keys / 密钥

ECC Keys can be much smaller while providing more security than RSA keys and the math involved is faster to perform. These are preferred when all parties can use them. ECC keys can be as low as 256 bit and still be secure. RSA keys are more interoperable. The minimum RSA key size should be 2048 bit. At least one major vendor Microsoft Entra doesn’t support ECC keys.

椭圆曲线（ECC）密钥可以比RSA密钥小得多，同时提供更高的安全性，并且涉及的数学运算更快。当所有相关方都可以使用时，这些密钥更受欢迎。ECC密钥可以低至256位仍然安全。RSA密钥具有更好的互操作性。最小RSA密钥大小应为2048位。至少有一个主要供应商Microsoft Entra不支持ECC密钥。

Signing Algorithms / 签名算法

When public key cryptography is used for signing data, the data is first hashed with an chosen algorithm and then the hash is signed using the private key.

当使用公钥加密技术进行数据签名时，首先使用选择的算法对数据进行散列，然后使用私钥对散列进行签名。

No IdP should use SHA-1 as the certificate signing hash. SHA-256 is the minimum bar. That said, if possible moving to larger hash algorithms like SHA-384 or SHA-512 means you are better future-proofing your service. In this context we are talking about the certificate’s signing algorithm and not the one used to sign the SAML response XML.

没有任何身份提供者应该使用SHA-1作为证书签名散列。SHA-256是最低标准。尽管如此，如果可能的话，迁移到更大的散列算法如SHA-384或SHA-512意味着你更好地为服务未来的发展做好准备。在这个上下文中，我们谈论的是证书的签名算法，而不是用于签名SAML响应XML的算法。

Certificate Lifetime / 证书有效期

X.509 certificates contain notBefore and notAfter validity dates. Plan certificate replacement before expiry rather than ignoring the validity period. Choose the signing key's usage period based on its protection, use, and threat model; see Cryptoperiods and Rotation. NIST SP 800-57 Part 1 Rev. 5, Section 5.3.4 distinguishes certificate validity from key usage periods: renewing a certificate with the same public key does not rotate the private key or restart its usage period.

X.509证书包含notBefore和notAfter有效期](https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.5)。在证书过期前而不是忽略有效期的情况下计划证书更换。根据其保护、使用和威胁模型选择签名密钥的使用期限；参见密钥周期和轮换。NIST SP 800-57第1部分修订版5，第5.3.4节区分证书有效性和密钥使用周期：使用相同公钥更新证书不会轮换私钥或重新启动其使用周期。

Extended Key Usage (EKU) and Key Usage (KU) / 扩展密钥用途（EKU）和密钥用途（KU）

EKU describes a specific use case that the certificate is intended for. These are use cases like server authentication, client authentication, and code signing, which are not appropriate for SAML signing. There is no widely accepted EKU for SAML signing, but RFC 9336 defines one that is ideal, id-kp-documentSigning (1.3.6.1.5.5.7.3.36). IdPs and SPs may consider standardizing on this EKU.

KU describes the underlying cryptographic operations that the private key is meant for. There are things like digitalSignature, nonRepudiation, keyEncipherment, etc. IdPs and SPs may consider requiring digitalSignature and further, disallowing certificates that have other KUs, as certificates should only be used for one use case. e.g. the IdP's TLS server certificate must never be the SAML signing certificate.

CRL Distribution Point (CDP) / CRL分发点（CDP）

Certificate Revocation List (CRL) Distribution Point) （证书吊销列表（CRL）分发点） are a list of certificates that the CA says should no longer be trusted. They are most often delivered over HTTP and the CRL URLs are generally embedded in each CA issued certificate. The CRL is signed by the CA, so a man-in-the-middle attack against the HTTP cannot harm the integrity of the list, other than to tamper with, and thus invalidate, it. That is, it can't be altered by an attacker. Only CA signed certificates can have a CRL. If the SAML certificate has a CRL listed, it should be reachable by the validating party and the party should validate it.

Considering the level of risk, if a private key is compromised, and the smaller scale of IdP to SP relationships, parties in a SAML system should establish a plan with contact lists to notify and rotate certificates rapidly in case of an incident. Many SAML products and libraries don’t support revocation checking, and simply revoking the certificate, without coordinated replacement, means there is an outage.

考虑到风险水平，如果私钥泄露，以及身份提供者（IdP）到服务提供者（SP）关系的较小规模，SAML系统中的各方应制定一个包含联系名单的计划，以便在发生事件时快速通知和轮换证书。许多SAML产品和库不支持吊销检查，简单地吊销证书而不进行协调更换意味着会有服务中断。

Online Certificate Status Protocol (OCSP) / 在线证书状态协议（OCSP）

OCSP is another way of checking to see if a certificate is revoked. The OCSP URL is embedded in the certificate , like a CRL, and should be reachable over HTTP. The response is signed, so MITM attacks are not an integrity concern. OCSP is becoming less favored, as the exchange creates privacy concerns. The caller's IP address can be seen and the certificate that is being used is disclosed. This is less of a concern for SAML, as this does not disclose a destination website, use overall has declined. If an OCSP URL is present on any certificate in the chain, it should be used to check if the certificate is revoked.

Certificate Hierarchy / 证书层次结构

The SAML signing certificate can be signed by one of three things. The certificate can be self-signed, public CA signed, or private CA signed. Each has pros and cons, however, given the current state of WebPKI (public) and private PKI, using self-signed SAML certificates are the clear winner when proper precautions are taken for exchanging the certificates.

SAML签名证书可以由以下三者之一进行签名。证书可以是自签名的、公共CA签名的或私有CA签名的。然而，鉴于当前WebPKI（公共）和私有PKI的状态，在采取适当的预防措施交换证书的情况下，使用自签名的SAML证书是明显的赢家。

Certificate Issuer / 证书颁发者

All X.509 certificates are signed, using a private key, by an authority known as an Issuer. This may be a CA or in the case of a self-signed certificate the certificate's corresponding private key. In the case of a CA signed certificate, the signer may also have a certificate that has an Issuer, and so on. This is called chain, or path, and should terminate in a Root CA (which is self-signed by definition). The issuer should be inspected. If the issuer is a CA, its attributes, such as EKU, KU, and CRLs, may also be validated. This should happen for each certificate in the path all the way to the root.

所有X.509证书都是由一个称为颁发者的权威机构使用私钥签名的。这可能是一个CA，或者在自签名证书的情况下，是证书对应的私钥。在CA签名证书的情况下，签名者也可能有一个具有颁发者的证书，依此类推。这被称为链或路径，并且应该以根CA（按定义是自签名的）结束。应该检查颁发者。如果颁发者是CA，其属性，如EKU、KU和CRLs，也可以进行验证。这应该适用于路径中的每个证书，直到根。

Public Certificate Authority (CA) Signed / 公共证书机构（CA）签名

With this certificate type, a Public CA issues the certificate, in accordance with their rules and the rules of the CA Browser Forum (CABF). These public root CAs get bundled into trust stores maintained by major browser vendors. Most things on the web trust these, because someone makes sure the trust stores are where they need to be.

使用这种证书类型，公共CA根据其规则和CA浏览器论坛（CABF）的规则颁发证书。这些公共根CA被捆绑到由主要浏览器供应商维护的信任存储中。大多数网络上的东西都信任这些，因为有人确保信任存储位于正确的位置。

When an IdP rotates its SAML Signing certificate, each SP must simultaneously update its explicit trust of that certificate. This can be challenging with only a few SPs. With many, it is nearly impossible. This pain has led to the use of SAML signing certificates with the longest possible lifetimes. This used to be two years with public CAs, then 398 days. The focus of WebPKI standards and the CABF is on server certificates for TLS. Recent and ongoing changes in certificate lifetimes make Public CA issued certificates less appealing. This is because the CABF has a path to making public CA issued certificates last only 47 days. As the IdP must get the certificate, announce the change for a reasonable amount of time, and then execute the change, this would mean IdPs and SPs would be in a perpetual state of certificate updates.

当身份提供者（IdP）旋转其SAML签名证书时，每个服务提供者（SP）必须同时更新其对该证书的明确信任。当只有少数SP时，这可能具有挑战性。当有很多时，这几乎是不可行的。这种痛苦导致了使用具有最长可能生命周期的SAML签名证书。这曾经是两年，然后是398天。WebPKI标准和CABF的焦点是服务器证书的TLS。证书寿命的最近和持续变化使公共CA颁发的证书不那么有吸引力。这是因为CABF有一条途径使公共CA颁发的证书仅持续47天。由于身份提供者必须获取证书，宣布更改一段时间，然后执行更改，这意味着身份提供者和SP将处于持续的证书更新状态。

It is worth noting that the CABF does not have governance around the use or acquisition of SAML certificates, certificates from their member CAs are what are widely considered Public CAs. That is, they are widely trusted by browsers, operating systems, and various development frameworks.

值得注意的是，CABF 没有关于 SAML 证书的使用或获取的治理，其成员 CA 的证书被广泛认为是公共 CA。也就是说，它们被浏览器、操作系统和各种开发框架广泛信任。

Using Public CA signed certificates allows for revocation checking, which can increase security, but if the certificate exchange is not secured, this could lead to a false sense of security.

使用公共 CA 签名的证书可以进行吊销检查，这可以增加安全性，但如果证书交换没有得到保护，这可能导致虚假的安全感。

Private CA Signed / 私有 CA 签名

As most IdPs and SPs treat the X.509 certificates as an explicit trust, private CAs and PKI could be used. How private CAs are designed, built, and run varies wildly and ultimately running CAs well is very costly. In order to trust a third-party's CAs, one would need to clearly understand the lifecycle of the CA. There are two audit types that would cover this, both of which are very costly, on top of building and running the CAs. If you rely on third-party CAs, they should be WebTrust, ETSI, or SOC 2 Type II audited.

由于大多数身份提供者（IdP）和服务提供者（SP）将 X.509 证书视为明确的信任，因此可以使用私有 CA 和 PKI。私有 CA 的设计、构建和运行方式差异很大，最终运行 CA 的成本非常高。为了信任第三方 CA，需要清楚地了解 CA 的生命周期。有两种审计类型可以涵盖这一点，这两种审计都非常昂贵，而且是在构建和运行 CA 之上的。如果您依赖第三方 CA，它们应该是经过 WebTrust、ETSI 或 SOC 2 Type II 审计的。

Trusting third-party CAs, if done improperly, could result in unintended over-trust, for things such as TLS and code signing. If you choose to trust third-party CAs, make sure they are only trusted for the process of IdP signature validation.

如果不当信任第三方 CA，可能会导致意外的过度信任，例如 TLS 和代码签名。如果您选择信任第三方 CA，请确保它们只被信任用于 IdP 签名验证的过程。

Private CA-issued signing certificates must not extend beyond the signing key's approved usage period. Apply the same lifetime and rotation policy to CA-issued and self-signed signing certificates.

私有 CA 签发的签名证书不得超出签名密钥的批准使用期限。将 相同的生命周期和轮换策略 应用于 CA 签发和自签名签名证书。

Self-Signed / 自签名

Due to the explicit nature of most SAML security associations, self-signed certificates are ideal for the use case. The contents of the certificate and lifetime are not constrained by the policy or process of the issuing CA, be it public or private. As rotating SAML certificates can be painful and labor intensive, setting the certificate lifetime as long as safely possible is key. Few CAs allow long enough lifetimes, due to their focus on the TLS threat model.

由于大多数 SAML 安全关联的明确性，自签名证书非常适合此类用例。证书内容和生命周期不受发行 CA 的政策或流程的限制，无论是公共的还是私有的。由于轮换 SAML 证书可能很痛苦且劳动密集，因此将证书生命周期设置为尽可能安全的关键。由于它们专注于 TLS 威胁模型，很少有 CA 允许足够长的生命周期。

Creating a Self-Signed SAML Certificate / 创建自签名SAML证书

If you are using a Hardware Security Module (HSM), follow the vendor's instructions. This process uses openssl. The example uses an overly generic distinguished name. Your Common Name (CN) should be meaningful and specific.

如果您正在使用硬件安全模块（HSM），请遵循供应商的说明。此过程使用openssl。示例使用了一个过于通用的区分名称。您的通用名称（CN）应该是有意义且具体的。

1. Generate a Private Key:
   中文：生成私钥： openssl genrsa -out private.key 2048 or openssl ecparam -genkey -name prime256v1 -out private.pem

2. Create a Configuration File (e.g., cert.cnf):
   中文：创建配置文件（例如，cert.cnf）：

[req] distinguished_name = req_distinguished_name x509_extensions = v3_ca prompt = no

[req_distinguished_name] C = US ST = California L = San Francisco O = MyOrganization OU = MyUnit CN = SAML Signing

[v3_ca] basicConstraints = CA:FALSE keyUsage = digitalSignature extendedKeyUsage = 1.3.6.1.5.5.7.3.36

3. Generate the Self-Signed Certificate:
   中文：生成自签名证书： openssl req -x509 -new -nodes -key private.key -sha256 -days 365 -out certificate.crt -config cert.cnf -extensions v3_ca

Certificate Metadata URLs / 证书元数据URL

Many IdPs publish a metadata URL that contains basic configuration information including the SAML signing certificate. Many SPs can consume the data from the IdP, updating the Signing certificate information in near real-time. Using these options is ideal. This model matches exactly the intent of the Certificate and Public Key Pinning when pinning must be used.

许多身份提供者（IdP）发布包含基本配置信息（包括SAML签名证书）的元数据URL。许多服务提供者（SP）可以消费来自IdP的数据，几乎实时地更新签名证书信息。使用这些选项是理想的。这种模式与证书和公钥固定的意图完全一致，当必须使用固定时。

The metadata URL should be protected using TLS where the server certificate comes from a WebPKI CA that is widely trusted and matches the guidance in the Transport Layer Security Cheat Sheet.

应使用TLS保护元数据URL，服务器证书来自广泛信任的WebPKI CA，并符合传输层安全性备忘单中的指导。

The ideal state of the IdP to SP relationship is that of using the metadata URLs, regardless of what type of certificate is used. If metadata URLs are not used, great care must be taken to assure that an attacker does not convince an SP to trust the wrong certificate. Avoid emailing certificates. Instead, like the metadata URL, present them over properly configured TLS.

理想状态下，身份提供者（IdP）与服务提供者（SP）之间的关系是使用元数据URL，无论使用何种类型的证书。如果不使用元数据URL，必须非常小心，以确保攻击者不能说服SP信任错误的证书。避免通过电子邮件发送证书。相反，像元数据URL一样，通过正确配置的TLS进行展示。

Signing Key Protection / 签名密钥保护

SAML Signing keys are a top security asset and target of attackers. Great care should be taken when creating the keys and as needed, copying them to nodes of an IdP cluster. File based keys are trivial for an attacker with access to exfiltrate. IdP operators should strongly consider protecting the private keys using a Hardware Security Module (HSM). HSMs allow an application to use a key without it being exportable or copyable. They have mechanisms to safely replicate the keys into a failover HSM, without ever exposing the keys outside of the HSMs. Quality HSMs would be rated FIPS 140-2 or FIPS 140-3.

SAML签名密钥是顶级安全资产，也是攻击者的目标。在创建密钥时必须非常小心，并在需要时，将它们复制到IdP集群的节点上。基于文件的密钥对于有权限泄露的攻击者来说非常简单。IdP运营商应强烈考虑使用硬件安全模块（HSM）来保护私钥。HSM允许应用程序使用密钥，而不会使其可导出或可复制。它们具有将密钥安全复制到故障转移HSM的机制，而不会在任何时候将密钥暴露在HSM之外。高质量的HSM会被评为FIPS 140-2或FIPS 140-3。

Identity Provider (IdP) Considerations / 身份提供者（IdP）注意事项

• Validate X.509 Certificate for algorithm compatibility, strength of encryption, export restrictions, and content above
  中文：验证X.509证书的算法兼容性、加密强度、出口限制以及内容
• Validate Strong Authentication options for generating the SAML token
  中文：验证生成SAML令牌的强认证选项
• IDP validation (which IDP mints the token)
  中文：IDP验证（哪个IDP发行令牌）
• Synchronize to a common Internet timesource
  中文：同步到公共互联网时间源
• Define levels of assurance for identity verification
  中文：定义身份验证的保证级别
• Prefer asymmetric identifiers for identity assertions over personally identifiable information (e.g. SSNs, etc)
  中文：在身份断言中优先使用非对称标识符而非个人可识别信息（例如SSN等）
• Sign each individual Assertion or the entire Response element
  中文：为每个单独的断言或整个响应元素签名

Service Provider (SP) Considerations / 服务提供商（SP）注意事项

• Validating session state for user
  中文：验证用户会话状态
• Level of granularity in setting authorization context when consuming SAML token (do you use groups, roles, attributes)
  中文：在消费SAML令牌时设置授权上下文粒度（您是否使用组、角色、属性）
• Ensure each Assertion or the entire Response element is signed
  中文：确保每个断言或整个响应元素都已签名
• Validate Signatures) （验证签名）
• Validate if signed by an authorized IdP
  中文：验证是否由授权的IdP签名
• Validate IDP certificates for revocation against CRL/OCSP if they are present
  中文：如果存在，验证IDP证书是否针对CRL/OCSP进行了吊销验证
• Validate the Destination attribute on <samlp:Response> exactly matches the SP's expected Assertion Consumer Service (ACS) URL (SAML Core 2.0 §3.2.2.1). Reject responses that are missing Destination or where it does not match — this prevents cross-SP assertion replay.
  中文：确保samlp:Response中的Destination属性与SP期望的断言消费者服务（ACS）URL完全匹配《SAML核心2.0 §3.2.2.1》]。拒绝缺少Destination或与它不匹配的响应——这可以防止跨SP断言重放攻击。
• Validate <saml:Audience> matches the SP's EntityID
  中文：验证 <saml:Audience> 是否与SP的EntityID匹配
• Validate NotBefore and NotOnorAfter
  中文：验证NotBefore和NotOnorAfter
• Validate Recipient attribute, InResponseTo, and <saml:SubjectConfirmationData> (Recipient, NotOnOrAfter, InResponseTo)
  中文：验证接收者属性、InResponseTo 和 <saml:SubjectConfirmationData> (Recipient, NotOnOrAfter, InResponseTo)
• Explicitly verify the signature algorithm is at least RSA-SHA-256 (or stronger). Reject SHA-1-based algorithms (http://www.w3.org/2000/09/xmldsig#rsa-sha1, ...#hmac-sha1) and <ds:DigestMethod Algorithm="...sha1">. NIST SP 800-131A Rev. 2 disallows SHA-1 in digital signatures.
  中文：明确验证签名算法至少为RSA-SHA-256（或更强）。拒绝基于SHA-1的算法(http://www.w3.org/2000/09/xmldsig#rsa-sha1，...#hmac-sha1)和<ds:DigestMethod Algorithm="...sha1">。NIST SP 800-131A Rev. 2禁止在数字签名中使用SHA-1。
• Verify that the XML signature's <ds:Reference URI> resolves to the signed Assertion or Response, and that the exact assertion used for authentication is protected by that validated signature. SAML Core sections 5.3 and 5.4 define signature inheritance and references; approved errata E93 permits Response signatures in the browser SSO profile. Reject assertions outside the validated signed content and follow the signature-wrapping defenses.
  中文：验证XML签名的<ds:Reference URI>是否解析为已签名的断言或响应，以及用于认证的确切断言是否受到该验证签名的保护。SAML核心第5.3和5.4节定义了签名继承和引用；已批准的勘误E93允许在浏览器SSO配置文件中使用响应签名。拒绝验证内容之外的断言，并遵循签名封装防御。
• Define criteria for SAML logout
  中文：定义SAML注销的准则
• Exchange assertions only over secure transports like TLS
  中文：仅在安全的传输方式如TLS上交换断言
• Define criteria for session management
  中文：定义会话管理的准则
• Verify user identities obtained from SAML ticket assertions whenever possible.
  中文：尽可能验证从SAML票据断言中获取的用户身份

Input Validation / 输入验证

Just because SAML is a security protocol does not mean that input validation goes away.

尽管SAML是一种安全协议，但这并不意味着输入验证可以消失

• Ensure that all SAML providers/consumers do proper input validation.
  中文：确保所有SAML提供者/消费者进行适当的输入验证。

Cryptography / 密码学

Solutions relying cryptographic algorithms need to follow the latest developments in cryptoanalysis.

依赖于密码学算法的解决方案需要遵循密码分析的最新进展

• Ensure all SAML elements in the chain use strong encryption
  中文：确保链中所有SAML元素都使用强加密
• Consider deprecating support for insecure XMLEnc algorithms
  中文：考虑弃用对不安全的XMLEnc算法的支持

References / 参考

• OASIS: Security and Privacy Considerations for SAML 2.0) （OASIS：SAML 2.0 的安全与隐私考虑因素）
• OASIS: Assertions and Protocols for SAML 2.0) （OASIS：SAML 2.0 的断言和协议）
• OASIS: Profiles for SAML 2.0) （OASIS：SAML 2.0 的配置文件）