Hi All,
We introduced this new design to solve the issues in the previous secure
vault implementation. We've simplified the configuration of secure vault
module with this new design.
Now we don't maintain passwords or any sensitive data in the configuration
files. All such data should be maintained in the *secret.properties* file.
We will see whether we can use YAML as the file format here.
When you develop Carbon components and if you happen to introduce configs
which contain passwords, you shouldn't put the actual password there. Just
put a secret alias in your config file and add an entry the
secret.properties file. This should happen at the development time. End
users do not need to worry such configurations. But if they want to change
passwords, they can change them only in the secret.properties file.
e.g. Consider the carbon.yml file. You should put a secret alias such as,
password: ${secvault:carbon.security.keystore.password}
Now you need put an entry in the secret.properties file as follows.
carbon.security.keystore.password=[wso2carbon]
Thanks,
Sameera.
On Wed, May 4, 2016 at 6:52 PM, Nipuni Perera <[email protected]> wrote:
> Hi all,
>
> We are trying to add Carbon secure-vault support to C5.
>
> We have done some changes to the way how we configure ciphertool and
> securevault in C5 compared to C4. Please find the new design details below:
>
> There are two configuration files that we maintain for Ciphertool and
> Securevault:
>
> [1]. *secrets.properties* - This file will contains the secret-allias
> and secrets (encrypted/or plain-text). Act as the file-based secret
> repository. We define all the passwords/secrets which need to be secured in
> this file.
> eg: SecureVault.Keystore.Password=[wso2carbon]
> Carbon.Security.KeyStore.Password=[somepassword]
>
> [2]. *secure-vault.yaml* - This file will have the main
> configurations (eg: default secret repository implementation, default
> Callbackhandler implementation etc)
> eg: carbon.secretProvider:
> org.wso2.securevault.secret.handler.SecretManagerSecretCallbackHandler
> keystore.identity.type: JKS
> keystore.identity.store.password: identity.store.password
>
> The CipherTool will be used for creating encrypted values for given plain
> text secrets in the *secrets**.properties* [1].
>
> If a user need to make a value secure,
>
> 1. they have to add a unique name (alias) to their carbon
> configuration element (eg: a value of an element in carbon.yml)
> 2. add the same unique-name along with the plain-text password to the
> *secrets.properties* file.
>
> *Example:*
>
> Assume that we need to secure a value "password" under element
> "Security/Keystore" in Carbon.yml configuration. First we add a unique a
> alias as the value to the Password as below [3]. Second we add that unique
> alias with its plain text password to *secrets*.properties file[4].
>
> CipherTool will encrypt the plain-text password and replace the plain-text
> password with the encrypted value. (In c4 we have added plain-text
> passwords within square brackets. If not they are identified as encrypted
> values).
>
> When loading the carbon.yml (or any other custom configuration file), we
> read the secured values using secure-vault service. This secure vault
> service will either return the password from the *secrets*.properties
> file if the secret is not encrypted, OR return the encrypted value.
>
> [3]
> ################################################################################
>
> id: carbon-kernel #Value to uniquely identify a server
> name: WSO2 Carbon Kernel #Server Name
> version: 5.1.0-SNAPSHOT #Server Version
> tenant: default #Tenant Name
>
> # Keystore used by this server
> Security:
> Keystore
> Password: Carbon.Security.Keystore.Password
>
>
> ###############################################################################
>
> [4] Carbon.Security.Keystore.Password=[wso2carbon]
>
>
> *New design decisions taken compared to C4 SecureVault implementation:*
>
> 1. We have removed the usage of cipher-tool.properties file. (This
> file was used to keep the alias, the location to the configuration file,
> and the xpath to the secret element in the configuration file).
> 2. We can support any format of configuration file with this model as
> we only care about the secret-key that we define in the
> *secrets*.properties
> file and do not depend on the xpath to find the location of the secret
> element.
>
> Thanks,
> Nipuni
>
> --
> Nipuni Perera
> Software Engineer; WSO2 Inc.; http://wso2.com
> Email: [email protected]
> Git hub profile: https://github.com/nipuni
> Blog : http://nipunipererablog.blogspot.com/
> Mobile: +94 (71) 5626680
> <http://wso2.com>
>
>
--
Sameera Jayasoma,
Software Architect,
WSO2, Inc. (http://wso2.com)
email: [email protected]
blog: http://blog.sameera.org
twitter: https://twitter.com/sameerajayasoma
flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
Mobile: 0094776364456
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
