General idea
General idea
The credential service allows storing the credentials for remote systems (such as the publish servers for remote replication or proxies) such that the usernames and passwords are encrypted and access to the credentials are restricted to users that have access to a certain JCR path stored in the credentials.
Usage
The Credential Service allows with the method com.composum.platform.commons.credentials.CredentialService#initHttpContextCredentials to use the credentials with an HttpClient.
Configuration
The passwords need to be encrypted with a master password which can be configured in the Composum Platform Credential Service. This can either be set in the configuration directly, or it is possible to configure a file which contains the password and which can be initialized with a random password.
The encryption of the passwords can be done with a UI (TBD), or via a servlet: e.g.:
echo -n thepasswordtoencode |
curl -X PUT -T - http://localhost:9090/bin/cpm/platform/security/credentials.encryptPassword.rawRepository structure
The credentials are stored in resources below /var/composum/platform/security/credentials . Each resource can be addressed by a credentialId that is the relative path to a resource below this node. It has the following properties:
encryptedUser,encryptedPasswd: the username and password encrypted with a master password stored in the OSGI configuration of the Composum Platform Credential Service.enabled: a boolean property that allows to enable or disable this particular set of credentialsreferencePath: an optional resource path. Access to these credentials is restricted to users that can read this path.
For testing purposes it is also possible to store usernames and passwords unencrypted form in properties user and password, but this is not recommended for production use.
NameComposum Platform Credential Servlet
Path/bin/cpm/platform/security/credentials
SelectorencodePassword Extensionraw MethodPUT OperationEncode password or username
Discussion
TODO
Planned changes:
- The credentials are grouped into vaults and are adressed into vaultId (usually the tenantid) and credentialId. There is only this level hierarchy.
- The credentials of a vault are encrypted by the vault password, the vault password is encrypted by the master password. The master password can be changed from the UI only by the admin user. The vault password can be changed by someone who has write permissions on the reference path.
- The code (incl. the proxyservice) is moved to platform/services/security. Access to the vault is only provided to the new service user composum-platform-security.
- list method for credentials of a vault, no list for vaults.
- Credentials are write only: input Map<String,String> (or ValueMap?), properties starting with "encrypted" are stored in encrypted form. Using them in different ways needs changing the CredentialServiceImpl.
Open points
- The aclpath mechanism protects against accidential use of credentials by normal code, but is easy to fool from malicious code with passing a resource resolver mock for the acl check. It's not quite clear how to identify the current user reliably from the service. Possibly we can use ResourceResolverFactory.getThreadResourceResolver() or PlatformAccessService.getAccessContext instead. Unfortunately, both of them do not work if the service is to be used by a service with a service user.
