Using a Credentials Provider
与数据存储器交互通常意味着首先使用凭据进行连接。这些凭据将允许对客户端进行识别、验证和最终授权。基于用户名/密码的验证非常常见，但这绝不是唯一的一种。此类凭据信息可能出现在应用程序配置中，但将此类敏感信息存储在安全存储中（如 HashiCorp Vault、Azure Key Vault 或 AWS Secrets Manager，仅举几例）正变得越来越普遍。
为了桥接消耗不同形式的凭据的数据存储和提供这些凭据的安全存储，Quarkus 引入了名为 Credentials Provider 的中间抽象，一些扩展可能支持以消耗凭据（例如，agroal），而其他一些可能实现以生成凭据（例如，vault）。
该服务编程接口 (SPI) 也可被希望支持 Quarkus 中尚未实现的自定义提供程序（例如，Azure Key Vault）的实现者使用。
目前，Credentials Provider 接口由 vault 扩展实现，并由以下凭据使用者扩展支持：
-
agroal -
reactive-db2-client -
reactive-mysql-client -
reactive-mssql-client -
reactive-oracle-client -
reactive-pg-client -
oidc -
oidc-client -
messaging-rabbitmq
所有依赖于用户名/密码身份验证的扩展也允许将配置属性设置为 application.properties 的替代。但是，如果生成凭据（例如，Vault Dynamic DB Credentials）或需要自定义凭据提供程序，则 Credentials Provider 是唯一选项。
本指南将展示如何使用 vault 扩展中提供的 Credentials Provider，然后我们将研究如何实现自定义 Credentials Provider，最后我们将讨论有关在新扩展中实现 Credentials Provider 的其他注意事项。
:iokays-category: quarkus
:iokays-path: modules/ROOT/pages/_includes/extension-status.adoc
:keywords: Quarkus, 中文文档, 编程技术
|
该技术被认为是 {extension-status}。 有关可能状态的完整列表，请查看我们的 FAQ entry. |
Vault Credentials Provider
要配置 Vault Credentials Provider，你需要提供以下属性：
quarkus.vault.credentials-provider.<name>.<property>=<value><name> 将在使用者中用于引用此提供程序。<property> 和 <value> 字段特定于 Vault Credentials Provider。有关完整详细信息，请参阅 https://quarkiverse.github.io/quarkiverse-docs/quarkus-vault/dev/vault-datasource.html。
例如：
quarkus.vault.credentials-provider.mydatabase.kv-path=myapps/vault-quickstart/db一旦定义，mydatabase 提供程序即可在任何支持 Credentials Provider 接口的扩展中使用。例如，在 agroal 中：
# configure your datasource
quarkus.datasource.db-kind = postgresql
quarkus.datasource.username = sarah
quarkus.datasource.credentials-provider = mydatabase
quarkus.datasource.jdbc.url = jdbc:postgresql://localhost:5432/mydatabase请注意，quarkus.datasource.username 是原始 agroal 属性，而 password 属性未包含，因为值将来自我们刚刚定义的 mydatabase 凭据提供程序。另一种方法是在 Vault 中定义用户名和密码，并从配置中删除 quarkus.datasource.username 属性。所有正在使用的扩展都支持从提供程序获取用户名和密码，或仅获取密码。
Time Limited Credentials
凭据提供程序可能会提供有限时凭据。例如，vault 扩展。在使用有限时凭据时，重要的是要了解凭据提供程序不会自动刷新正在使用的扩展的凭据。必须对每个扩展进行配置，以便在凭据到期之前回收其连接。
Custom Credentials Provider
在 Quarkus 中尚未支持保险箱产品或者需要从自定义存储中检索凭据时，实现自定义凭据提供程序是唯一选择。
需要实现的唯一界面是：
public interface CredentialsProvider {
String USER_PROPERTY_NAME = "user";
String PASSWORD_PROPERTY_NAME = "password";
Map<String, String> getCredentials(String credentialsProviderName);
}`USER_PROPERTY_NAME`和`PASSWORD_PROPERTY_NAME`是标准属性，任何支持基于用户名/密码进行认证的扩展都可以识别这两个属性。
需要实现为有效的`@ApplicationScoped`CDI bean。
这是一个简单的示例：
@ApplicationScoped
@Unremovable
public class MyCredentialsProvider implements CredentialsProvider {
@Override
public Map<String, String> getCredentials(String credentialsProviderName) {
Map<String, String> properties = new HashMap<>();
properties.put(USER_PROPERTY_NAME, "hibernate_orm_test");
properties.put(PASSWORD_PROPERTY_NAME, "hibernate_orm_test");
return properties;
}
}请注意，我们决定同时返回用户名和密码。
此提供程序可以在数据源定义中像这样使用：
quarkus.datasource.db-kind=postgresql
quarkus.datasource.credentials-provider=custom
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5431/hibernate_orm_test也可以使用标准 MicroProfile 配置注入的方式向提供程序传递配置属性：
custom.foo=bar并且在提供程序实现中：
@Inject
Config config;
@Override
public Map<String, String> getCredentials(String credentialsProviderName) {
System.out.println("MyCredentialsProvider called with foo=" + config.getValue(credentialsProviderName + ".foo", String.class));
...
}New Credentials Provider extension
在新的扩展中创建自定义凭据提供程序时，还有几项其他注意事项。
首先，您需要为其命名以避免在项目中存在多个凭据提供程序时发生冲突：
@ApplicationScoped
@Unremovable
@Named("my-credentials-provider")
public class MyCredentialsProvider implements CredentialsProvider {用户的责任是允许有`credentials-provider-name`属性：
quarkus.datasource.credentials-provider = custom
quarkus.datasource.credentials-provider-name = my-credentials-provider扩展应该允许运行时配置，例如允许来自`vault`扩展的`CredentialsProviderConfig`配置提供程序中的任何自定义属性。对于 AWS Secrets Manager 扩展，可以如下配置：
-
region -
credentials-type -
secrets-id
还要注意，一些用户（例如 agroal）会将其连接配置添加到凭据提供程序返回的任何属性中，而不仅仅是用户名和密码。因此，在设计新的凭据提供程序时，将属性限制为用户可以理解的属性，或者提供适当的配置选项以支持不同的模式。