17.4. strict 模式
有 fips-mode 选项，当启用 fips 功能时，该选项会自动设置为 non-strict。这意味着在 "non-approved mode" 中运行 BCFIPS。更安全的替代方案是 use-- features=fips --fips-mode=strict，在这种情况下，BouncyCastle FIPS 将使用 "approved 模式"。使用该选项会对加密和安全算法造成更严格的安全要求。
在严格模式中，默认密钥存储类型（以及默认信任存储类型）是 BCFKS。如果要使用不同的密钥存储类型，则需要使用带有适当类型的 option -https-key-store-type。如果您希望使用 truststore，也可能需要一个类似的命令。
启动服务器时，您可以检查启动日志是否包含 KC 供应商，其中包含有关 Approved Mode 的备注，如下所示：
KC(BCFIPS version 2.0 Approved Mode, FIPS-JVM: enabled) version 1.0 - class org.keycloak.crypto.fips.KeycloakFipsSecurityProvider,
17.4.1. 严格模式中的加密限制
-
如上一节中所述，严格的模式可能无法用于
pkcs12密钥存储。如前文所述，需要使用另一个密钥存储（如bcfks）。在使用 strict 模式时，红帽构建的 Keycloak 不支持jks和pkcs12密钥存储。有些示例是在管理控制台中导入或生成 OIDC 或 SAML 客户端的密钥存储，或用于 realm 密钥中的java-keystore供应商。 -
用户密码必须为 14 个字符或更长时间。默认情况下，Red Hat build of Keycloak 使用基于 PBKDF2 的密码编码。BCFIPS 批准模式需要至少 112 位（有效的 14 个字符）使用 PBKDF2 算法。如果要允许较短的密码，请将供应商
pbkdf2-sha512of SPIpassword-hashing的属性max-padding-length设置为 14，以便在验证此算法创建的哈希时提供额外的 padding。此设置也与之前存储的密码向后兼容。例如，如果用户的数据库位于非FIPS 环境中，且您有较短的密码，并且您想要在批准模式中使用 BCFIPS 在红帽构建的 Keycloak 中验证它们，则密码应该可以正常工作。因此，您可以在启动服务器时使用如下选项：
--spi-password-hashing-pbkdf2-sha512-max-padding-length=14
使用以上选项不会中断 FIPS 合规性。但请注意，较长的密码都是很好的做法。例如，现代浏览器自动生成的密码符合此要求，因为它们超过 14 个字符。如果要省略 max-padding-length 的 选项，您可以将密码策略设置为您的域，使其至少有 14 个字符的密码。
当您从早于 24 的红帽构建的 Keycloak 迁移时，或者如果您明确设置了密码策略来覆盖默认的哈希算法，您的某些用户可能会使用像 pbkdf2-sha256 这样的旧算法。在这种情况下，请考虑添加 --spi-password-hashing-pbkdf2-sha256-max-padding-length=14 选项，以确保其密码使用旧的 pbkdf2-sha256 可以登录，因为其密码可能比 14 个字符要短。
-
RSA 密钥为 1024 位不能工作（最小是2048）。这适用于由红帽构建 Keycloak 域本身使用的键（来自管理控制台中的
Keys选项卡的Realm 密钥），以及客户端密钥和 IDP 密钥 -
HMAC SHA-XXX 密钥必须至少为 112 位（或 14 个字符）。例如，如果您使用带有客户端身份验证的 OIDC 客户端
Signed Jwt with Client Secret（或者在 OIDC 表示法中的client-secret-jwt），则您的客户端 secret 应该至少 14 个字符。请注意，为了获得良好的安全性，建议使用红帽构建的 Keycloak 服务器生成的客户端 secret，这始终可以满足这个要求。 -
bc-fips 版本 1.0.2.4 处理 PKCS 1.5 RSA 加密的过渡周期结束。因此，默认情况下，在严格模式下不允许带有算法
RSA1_5的 JSON Web 加密(JWE) (BC 提供系统属性-Dorg.bouncycastle.rsa.allow_pkcs15_enc=true作为现在的向后兼容性选项)。RSA-OAEP和RSA-OAEP-256仍如以前提供。
