Hi all,
We will provide both two options to initialize config provider. So user can
either initialize securevault separately with separate configuration
file(secure-vault.yaml) and pass the securevault instance when creating
config provider instance. or user can use the same the configuration
file(deployment.yaml) to initiate both config provider and securevault.
Secure vault configuration looks like,
...
wso2.securevault:
secretRepository:
type: org.wso2.carbon.secvault.repository.DefaultSecretRepository
parameters:
privateKeyAlias: wso2carbon
keystoreLocation: resources/security/wso2carbon.jks
secretPropertiesFile: conf/secrets.properties
masterKeyReader:
type: org.wso2.carbon.secvault.reader.DefaultMasterKeyReader
parameters:
masterKeyReaderFile: conf/master-keys.yaml
...
we have to maintain same format both case, either using separate
file(secure-vault.yaml) and adding it to depoyment.yaml. securevault impl
will read the configuration file and look for wso2.securevault namespace
to intialize the securevault instance.
Thanks
Danesh
On Fri, Mar 31, 2017 at 5:24 PM, Jayanga Dissanayake <[email protected]>
wrote:
> Hi Danesh,
>
> IMO, A hybrid of Option 1 and Option2 would be the best.
>
> i.e:
> 1. If the instantiation of SecureVault and ConfigProvider is separated
> out, as you mentioned in the Option1, then we have the flexibility of
> providing the SecureVault implementation to the ConfigProvider. Which
> improves the clarity of the API and in the meantime improves the
> testability of the code.
>
> 2. If we can merge the secure-vault configurations into the
> deployment.yaml that would be the ideal case. As we are now trying to put
> all configurations related things in one file. But if we make a
> dependency in SecureVault for ConfigProvider, then it creates cyclic
> dependency.
> SecureVault <-> ConfigProvider.
> One way to avoid this conflict is to read the deployment.yaml separately
> in the SecureVault and read only the relevant section for the SecureVault.
>
> WDYT?
>
> Thanks,
> Jayanga.
>
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: [email protected]
> mobile: +94772207259 <+94%2077%20220%207259>
> <http://wso2.com/signature>
>
> On Fri, Mar 31, 2017 at 3:40 PM, Vidura Nanayakkara <[email protected]>
> wrote:
>
>> Hi Danesh,
>>
>> IMO, option 2 can be used in OSGi mode. However, in non-OSGi mode, we may
>> use the secure vault only rather than using the config provider and the
>> secure vault. Therefore having a deployment.yaml file including the secure
>> vault yaml configuration sounds a bit odd. Furthermore in this case how are
>> we extracting the secure vault configuration out of the deployment yaml.
>>
>> *Suggestion: *IMO we should proceed with option 2 in OSGi mode and
>> option 1 in non-OSGi mode. So in non-OSGi mode how the user initializes
>> secure vault would be like:
>>
>> Example 1:
>>
>> Path secureVaultconfigPath = <secure-vault.yaml file path>;
>> SecureVaultFactory secureVaultFactory = new SecureVaultFactory();
>> SecureVault secureVault = secureVaultFactory.getSecureVa
>> ult(secureVaultconfigPath);
>> or
>>
>> Example 2:
>>
>> Path secureVaultconfigPath = <secure-vault.yaml file path>;
>> SecureVaultConfiguration securevaultconfiguration =
>> SecureVaultConfigProvider.createSecureVaultConfiguration(
>> secureVaultconfigPath);
>> SecureVaultFactory secureVaultFactory = new SecureVaultFactory();
>> SecureVault secureVault = secureVaultFactory.getSecureVa
>> ult(securevaultconfiguration);
>>
>> In the OSGi mode we can use Example 2 when initializing securevault
>> inside the config provider.
>>
>> WDYT?
>>
>>
>> On Fri, Mar 31, 2017 at 11:02 AM, Danesh Kuruppu <[email protected]> wrote:
>>
>>> Hi all,
>>>
>>> In the current non-OSGi securevault implementation, we need to pass
>>> securevault configuration file path when initializing the securevault
>>> service instance. like below,
>>>
>>>> Path *configPath* = <secure-vault.yaml file path>;SecureVaultFactory
>>>> secureVaultFactory = new SecureVaultFactory();SecureVault secureVault =
>>>> secureVaultFactory.getSecureVault(*configPath*);
>>>>
>>>>
>>> Since Configuration Provider directly depends on securevault, we need to
>>> initialize securevault instance because initializing the Configuration
>>> Provider. Below are few options we can follow when initializing Config
>>> Provider non-OSGi mode
>>>
>>> Option 01: Force user to create securevault instance before creating
>>> Configuration Provider instance. We will provide method in provider factory
>>> to get ConfigProvider by passing deployment config file path and
>>> securevault instance. like below,
>>>
>>> Path *secureVaultconfigPath* = <secure-vault.yaml file
>>> path>;SecureVaultFactory secureVaultFactory = new
>>> SecureVaultFactory();SecureVault *secureVault* =
>>> secureVaultFactory.getSecureVault(*secureVaultconfigPath*);
>>>>
>>>> Path *deploymentConfigPath* = <deployment.yaml file path>;
>>>> ConfigProviderFactory configProviderFactory = new ConfigProviderFactory();
>>>> ConfigProvider configProvider =
>>>> configProviderFactory.getConfigProvider(*deploymentConfigPath*,
>>>> *secureVault*);
>>>>
>>>>
>>> Option 02: Allow user to pass deployment.yaml(can be any file name) file
>>> path only and we create the securevault instance. in order to do that, we
>>> should know the securevault config file path. Shall we add securevault
>>> configuration also to the deployment.yaml file(can be any file name. we
>>> keep same file to hold both server configs and securevault configs) and
>>> pass the same file to initialize securevault when initializing
>>> configuration provider. So configuration file will looks like,
>>> ...
>>>
>>> wso2.securevault:
>>> secretRepository:
>>> type: org.wso2.carbon.secvault.repository.DefaultSecretRepository
>>> parameters:
>>> privateKeyAlias: wso2carbon
>>> keystoreLocation: resources/security/wso2carbon.jks
>>> secretPropertiesFile: conf/secrets.properties
>>> masterKeyReader:
>>> type: org.wso2.carbon.secvault.reader.DefaultMasterKeyReader
>>> parameters:
>>> masterKeyReaderFile: conf/master-keys.yaml
>>>
>>> ...
>>>
>>> So when initializing the securevault, provider will read the same config
>>> file and get configurations under wso2.securevault.
>>>
>>> Please share your thoughts / suggestions.
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: [email protected]
>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : [email protected]
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran <http://wso2.com/>
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> <http://wso2.com/>
>>
>
>
--
*Danesh Kuruppu*
Senior Software Engineer | WSO2
Email: [email protected]
Mobile: +94 (77) 1690552
Web: WSO2 Inc <https://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
