Background

Registry needs numerous credentials to talk to integrated systems, including Organizational Identity Source and Provisioning Targets. In general, the use of credentials is conceptually related to Servers, although in v4 not all uses follow this model.

The original intention was for deployers to leverage database encryption to protect secrets such as passwords. In practice, it's not clear this model was meaningfully adopted. Furthermore, the adoption of container based infrastructure and other changes over the years suggest a new approach is due.

Registry PE will introduce the concept of Credentials and Credential Management Plugins. In short, when credentials are required to talk to an integrated system, a Credential object will be used. Credential objects will be implemented by Credential Management Plugins, which will allow for multiple backend technologies to be used, potentially concurrently.

Credential Management Plugins

Credential Management Plugins will be responsible for registering Credentials for configuration purposes, and obtaining Credentials for runtime authentication. Any given Plugin can support multiple technologies, such as Passwords, SSH Keys, and OAuth Tokens.

Example operations to be implemented by these Plugins include

  • retrieve(int $credentialId): Credential
    • Obtain a Credential from the Credential store.
  • store(Credential $c): bool
    • Store a Credential. Not all Plugins may support write operations, and those that do might not support all Credential types. This is intended to support use cases such as OAuth, where a token is obtained at runtime.
  • inventory(): ResultSet
    • Obtain a list of available Credentials. Generally to be used for configuring Credential consumers.

An example administrator sequence to set up an LdapProvisioner might look like

  1. Create a new PasswordCredential with the bind DN and password.
  2. Create a new LdapServer, configured with the PasswordCredential (via foreign key reference) defined above.
  3. Create a new ProvisioningTarget, configured with the LdapServer configuration (via foreign key reference) defined above.

Credential Management Plugins will be instantiated on a per-CO basis. At least two plugins are expected to be shipped out of the box.

DatabaseVault Plugin

DatabaseVault will use a database to store and retrieve credentials. By default (to simplify out of the box deployment) this may be the same as the standard database, but if an appropriate configuration is added to database.php a separate database could be used. By default, the standard Security salt could be used to encrypt data stored in the vault, though plausibly an alternate key could be specified.

DatabaseVault will most likely be a Core Plugin.

EnvVault Plugin

EnvVault is designed for container environments, and will retrieve credentials from environment variables. EnvVault will not support storing credentials. A convention might restrict variables to specified COs, possibly with prefix notation similar to ApiUsers. (eg: $CO2_LDAPPWD would only be available within CO ID 2.)

For the LdapProvisioner example above, with EnvVault the sequence might look like

  1. Create the password in the appropriate storage environment.
  2. Configure the environment variable that will hold the password value.
  3. Create a new PasswordCredential with the bind DN and the appropriate environment variable name.
  4. Create the LdapServer and ProvisioningTarget.

EnvVault will most likely be an Available Plugin.

Authenticator Plugins

There is conceptual overlap between Credential Management Plugins and Authenticator Plugins, but for now there are no plans to merge the two. This may change as PE designs evolve.

See Also

  • No labels