Hi Susinda
On Mon, Jul 18, 2016 at 10:47 AM, Susinda Perera <susi...@wso2.com> wrote:
>
> ---------- Forwarded message ----------
> From: Jayanga Dissanayake <jaya...@wso2.com>
> Date: Fri, Jul 15, 2016 at 1:22 PM
> Subject: [Architecture] Defining KeyStores in C5
> To: Architecture List <architecture@wso2.org>
>
>
> 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.
>
RegistryKeystore is only there in Carbon 4.2.0 based products. From Carbon
4.4.x based products the Keystore define the carbon.xml is used for
Encrypting and Decrypting whereas the SSL keystore is defined in
catalina-server.xml.
+1 for secure vault for json and yml
>
>
> Suggestions and thoughts are welcome.
>
> Thanks,
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Regards,
Nira
--
*Niranjan Karunanandham*
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
