---------- Forwarded message ----------
From: Jayanga Dissanayake <[email protected]>
Date: Fri, Jul 15, 2016 at 1:22 PM
Subject: [Architecture] Defining KeyStores in C5
To: Architecture List <[email protected]>
Hi All,
Currently I am redesigning the SecureVault implementation for C5. Our main
approach is to change the current implementation in more OSGi friendly and
extensible manner. While designing the new approach I came across the
following manner.
How are we going to define KeyStores in the C5?
Is it the carbon.yml, we are going to define all the keystores or are we
going to define keystore for secure vault separately and SSL related
keystores in respective transports yamls.
The concerns I have here are,
1. If we define all the keystores in carbon.yml, this will be a blocker for
SecureVault initialization. Because, in the secure vault initialization, it
has to parse the carbon.yml via “ConfigUtil” (This name is not yet
finalized) : Dynamic Configuration Update Module , to get the carbon.yml
updated for the Environment, System and Security related parameters. Hence,
by the time the dynamic configuration update happens, SecureVault has to be
initialized.
So, the option would be to have a separate configuration file for
SecureVault, which doesn't have ${sec:xyz} directives. (Hence no issue for
SecureVault). It may have ${env:xyz} and ${sys:xyz} directives and get
those parameters updated properly.
2. If we go with the Option:1, then we can define the SSL related keystores
in carbon.yml, or respective transport configurations. Configurations of
those can have all three types of dynamic configuration directives without
any restrictions. Because by the time those components read the
configuration, SecureVault is initialized.
3. One other option would be to expose the access to the keystores as an
OSGi service. We can use a separate component or same SecureVaule (might
need to change the name) component to expose that as an OSGi service. So,
if an other component needs a Key, it could provide the alias and private
key password to this service and get the Key and continue.
This approach will work fine for carbon components. But if there are any
third party components that uses keystores directly (as we had in C4,
axis2.xml, catalina-server.xml, etc) this approach doesn't add much value.
Considering above mentioned approaches, I would suggest to have,
1. A separate configuration file for SecureVault (name would be
secure_vault.yml). Which will have KeyStore information related to
encrypting and decrypting passwords.
2. And SSL related keystore information in respective transport
configurations.
+1 for separating keystores for SSL and other encryptions(secure vault),
Currently we have KeyStore and RegistryKeyStore configs where
RegistryKeyStore is used to encrypt the data written to registry and
KeyStore for all other (SSL and Secure-Vault). I think we can use a
separate keystore for SSL and another one for Secure-Vault and registry
encryption.
Also I think we have to consider secure vault for json, yml and any other
file types.
Suggestions and thoughts are welcome.
Thanks,
*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [email protected]
mobile: +94772207259
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
*Susinda Perera*
Software Engineer
B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL)
Mobile:(+94)716049075
Blog: susinda.blogspot.com
WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
