ITADN
CZERTAINLY/CZERTAINLY-Common-Credential-Provider
CZERTAINLY/CZERTAINLY-Common-Credential-Provider · 文件 下载 ZIP
文件最后提交记录最后更新时间
README.md

Common Credential Provider

This repository is part of the commercial open-source project ILM. You can find more information about the project at the ILM repository, including the contribution guide.

Common Credential Provider is the implementation of basic Credential Kinds and validation interfaces. This Connector provides options to add the Credential to the Core which can be used within other objects in the platform for authentication and authorization purposes.

Credentials provided by the Common Credential Provider are not involved in the platform authentication and authorization process.

Common Credential Provider implement the following credential Kinds:

  • Basic (Username and Password)
  • API Key
  • Software KeyStore (i.e., certificate related authentication)

Beyond credentials, the connector also acts as a Secret Provider — a namespaced store for secrets managed by the platform (see Secret Provider below).

Short Process Description

The Credential can be created and added to the Core based on their Kind. Selecting the specific Kind of Credential and providing the necessary information is the first step in the process. When the Connector or other platform object requests the specific Kind of the Credential implemented in this Credential Provider, it will provide its values.

To know more about the Core, refer to Core.

Interfaces

Common Credential Provider implements the Credential Provider Interface from the ILM Interfaces. To learn more about the interfaces and end points, refer to the Interfaces.

For more information regarding the Credentials, please refer to the documentation.

Secret Provider

In addition to the Credential Provider, this connector implements a Secret Provider: it stores versioned secrets in its own database and serves them back to the platform. Secrets are scoped by an optional namespace.

The namespace is a vault-instance attribute set when the vault is created. It is part of a secret's identity and provides hard isolation between scopes:

  • Secrets in one namespace are not visible to, and cannot be modified from, another namespace.
  • The same secret name can exist independently in different namespaces.
  • Leaving the namespace empty places secrets in a distinct root scope; a vault configured with no namespace only ever sees root-scope secrets.

This mirrors how namespaces work in HashiCorp Vault.

Docker container

Common Credential Provider is provided as a Docker container. Use the hub.omnitrustregistry.com/ilm/common-credential-provider:tagname to pull the required image from the repository. It can be configured using the following environment variables:

VariableDescriptionRequiredDefault value
JDBC_URLJDBC URL for database accessN/A
JDBC_USERNAMEUsername to access the databaseN/A
JDBC_PASSWORDPassword to access the databaseN/A
DB_SCHEMADatabase schema to usecommon_secret
ENCRYPTION_KEYKey used to encrypt stored secrets at rest. A built-in default exists so the service can start, but it must be overridden with a strong, unique secret in production.built-in (insecure)
PORTPort where the service is exposed8080
INCLUDE_ERRORWhether error responses include the exception message (always / never).always
JAVA_OPTSCustomize Java system properties for running applicationN/A