Hi Kishanthan, When we have the master-keys.yaml and secrets.properties yaml file path in secure-vault.yaml configuration the end user do not need to override a method to explain how the paths are taken but rather handled within the secure vauilt implementation itself. So if the paths are specified as a relative path, we can locate the files using the relevant configuration file location (OSGi / non-OSGi) and if we specify the absolute path, we can locate the file straight away from the specified location.
On Fri, Mar 17, 2017 at 10:28 AM, Vidura Nanayakkara <[email protected]> wrote: > Hi Niranjan, > > Ideally, the OSGi / non-OSGi check should happen at the secure vault > initialization phase. The rest of the execution should happen accordingly > without checking for OSGi / non-OSGi. However, if we delegate providing > other file paths (secret.properties, master-key.yaml) to relevant > implementation classes we need to get the file location accordingly (OSGi / > non-OSGi). This will require an OSGi / non-OSGi check (even if we set the > OSGi / non-OSGi config path during initialization how would the end > developer know when overriding a specific method?) > > Example: > > @Override > public Path getMasterKeyYAMLPath() throws SecureVaultException { > Path masterKeysFilePath; > if (SecureVaultUtils.isOSGIEnv()) { > Path carbonHomePath = Utils.getCarbonHome(); > masterKeysFilePath = Paths.get(carbonHomePath.toString(), > MASTER_KEYS_FILE_NAME); > } else { > Optional<Path> resourcePath = SecureVaultUtils > .getResourcePath("securevault", "conf", > MASTER_KEYS_FILE_NAME); > if (!resourcePath.isPresent()) { > throw new SecureVaultException(MASTER_KEYS_FILE_NAME + > "not found"); > } > masterKeysFilePath = resourcePath.get(); > } > return masterKeysFilePath; > } > > > We do not need to do an OSGi / non-OSGi check if we include the > secrets.properties and master-keys.yaml in the secure-vault.yaml as stated > above since we can keep the relevant paths in memory accordingly during the > secure vault initialization phase. Furthermore, is it really required to > delegate providing other file paths to the relevant implementation when we > can handle this from the secure-vault.yaml itself? > > My suggestion is to specify the locations in the secure-vault.yaml. This > way if we specify a relative path, we can get the path according to the > OSGi / non-OSGi mode (predefined configuration locations). If we specify an > absolute path we can take the path as it is to locate the files. > > WDYT? > > On Fri, Mar 17, 2017 at 10:18 AM, Niranjan Karunanandham < > [email protected]> wrote: > >> Hi Jayanga, >> >> >> On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake <[email protected]> >> wrote: >> >>> Hi Niranjan, >>> >>> You are correct we should follow the same way as msf4j to detect >>> whether it is OSGi mode or not. >>> The properties suggested are to avoid the OSGi mode check in several >>> places. With the suggested properties, secure-vault.yaml will have all the >>> information it needs for the initialization. Hence it could check the mode >>> at one place and initialize the secure vault accordingly. >>> >> Is it possible to move the parts where we need to check if it is an OSGi >> mode or not to a generic place that is at the start and these values are >> based to the implementation later? So that the implementation layer does >> not need to know whether it is a OSGi or non-OSGi. >> >> >>> >>> 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 17, 2017 at 9:43 AM, Niranjan Karunanandham < >>> [email protected]> wrote: >>> >>>> Hi Vidura, >>>> >>>> We can identify whether it is in OSGi mode or non-OSGi mode by checking >>>> if the bundleContext is set. If it is not set, then it is in non-OSGi mode. >>>> This is the way we have done for msf4j. Any reason for this new approach? >>>> >>>> Regards, >>>> Nira >>>> >>>> On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayakantha < >>>> [email protected]> wrote: >>>> >>>>> Hi Vidura, >>>>> >>>>> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> An example for a secure vault YAML configuration file is as shown >>>>>> below according to the current implementation. >>>>>> >>>>>> secretRepository: >>>>>> type: org.wso2.carbon.kernel.securevault.repository.DefaultSecretR >>>>>> epository >>>>>> parameters: >>>>>> privateKeyAlias: wso2carbon >>>>>> keystoreLocation: resources/security/wso2carbon.jks >>>>>> masterKeyReader: >>>>>> type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyRe >>>>>> ader >>>>>> >>>>>> However, according to the discussion made in [1] >>>>>> <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> >>>>>> , we decided to move Carbon Secure Vault out of Carbon Kernel for >>>>>> the specified reasons in [1] >>>>>> <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>. >>>>>> According to this change, in OSGi mode the Secret repository and the >>>>>> master key reader will be an implementation of the specified classes ( >>>>>> org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository >>>>>> and org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader >>>>>> ) and will be registered via the Secure Vault Component while in >>>>>> standalone mode the secret repository and master key reader will be >>>>>> instances of the specified classes and will be created using the >>>>>> class.forName() method. >>>>>> >>>>>> According to this implementation, it was decided to delegate >>>>>> providing other file paths (secret.properties, master-key.yaml) to >>>>>> relevant implementation classes because other file paths >>>>>> (secret.properties, master-key.yaml) are bound to the relevant >>>>>> implementation. However, with this approach, we are forced to check >>>>>> whether the code is being executed in OSGi mode or non-OSGi mode in order >>>>>> to provide the correct location of the file paths (secret.properties, >>>>>> master-key.yaml). >>>>>> >>>>> Since this happens in implementation class as in this case in Default >>>>> implementation, IMO it is not a problem to check whether OSGI or not to >>>>> give the correct file location. Even when you create another >>>>> implementation >>>>> that should work in both OSGI and non OSGI enviorenments you have to check >>>>> for OSGI or not to give the correct file location. >>>>> >>>>>> >>>>>> >>>>> >>>>>> *Suggestion:* >>>>>> >>>>>> secretRepository: >>>>>> type: org.wso2.carbon.secvault.securevault.repository.DefaultSecre >>>>>> tRepository >>>>>> parameters: >>>>>> privateKeyAlias: wso2carbon >>>>>> keystoreLocation: securevault/resources/security/wso2carbon.jks >>>>>> secretProperties: securevault/resources/security >>>>>> /secrets.properties >>>>>> masterKeyReader: >>>>>> type: org.wso2.carbon.secvault.securevault.utils.DefaultHardCodedM >>>>>> asterKeyReader >>>>>> parameters: >>>>>> masterKeyFile: securevault/resources/security/master-keys.yaml >>>>>> >>>>>> >>>>>> If we could add the highlighted properties to the secure vault YAML >>>>>> configuration file specifying the location of the master-keys.yaml and >>>>>> secrets.properties, we only need to check whether the code is being >>>>>> executed in OSGi mode or non-OSGi mode once at the time of secure vault >>>>>> initialisation. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> [1] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 >>>>>> Separate Repositories (Removing from Kernel) >>>>>> <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> >>>>>> >>>>>> >>>>>> 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/> >>>>>> Twitter : http://twitter.com/viduranana >>>>>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara >>>>>> <http://wso2.com/> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lakshman Udayakantha >>>>> WSO2 Inc. www.wso2.com >>>>> lean.enterprise.middleware >>>>> Mobile: *0717429601* >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> *Niranjan Karunanandham* >>>> Associate Technical Lead - WSO2 Inc. >>>> WSO2 Inc.: http://www.wso2.com >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> 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 >> [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/> > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : [email protected] Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
