Hi All, Let me do certain clarifications regarding this email. Apologies since the actual message is not conveyed.
We need to do the OSGi / non-OSGi check only once. However, if we follow the previous secure-vault.yaml structure (without the secrets.properties path and the master-keys.yaml path) we have to get these files through the implementation which means that for OSGi mode we will look for these files in the carbon config home and in the non-OSGi mode we will look for these files in the resources. If we are to provide the locations of these files without limiting to the carbon config home or resource path we have to provide the ability state the relevant paths. There are 3 ways we can do this. 1. Let the user override a method to get the master keys YAML path and the secrets properties path - This is not a convenient approach for the user 2. Provide these locations through environment variables. 3. Set these path values in secure-vault.yaml The suggested approach was 3, since according to the discussions we had 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 decide to get the secure-vault.yaml location from carbon config home in OSGi mode (we are not talking about different runtimes yet) and from system property, environment variable or class path in non-OSGi mode. If we specify the paths of master-keys.yaml and secrets.properties in secure-vault.yaml we only need to specify the path of the secure-vault.yaml as per the discussions we had 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> . Myself, Jayanga and Niranjan had a discussion regarding this matter yesterday. Here are the points we discussed during the discussion. - Obtaining the secure-vault.yaml path in OSGi mode will be carbon config home by default (as discussed 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>) You can change this path via a system property or an environment variable. In non-OSGi mode the secure-vault.yaml would be provided via the implementation (SecureVaultInitializer.getInstance.initialise(Path secureVaultYaml)). - Obtaining the paths of the master-keys.yaml and the secret.properties will be by default taken from the secure-vault.yaml configuration file. If this is not specified in the secure-vault.yaml then it will refer to the relevant configuration location (OSGi / non-OSGi). The reason for specifying these path values in secure-vault.yaml is since master-keys.yaml file and the secret.properties file will be taken from any outside location (rather than classpath) in non-OSGi mode. WDYT? On Fri, Mar 17, 2017 at 11:41 AM, Lakshman Udayakantha <[email protected]> wrote: > Adding these files to parameter section makes no difference because > parameter section includes implementation specific data. So I think it is > ok to keep them in parameter section as well. It is up to the > implementation. > > On Fri, Mar 17, 2017 at 10:42 AM, Vidura Nanayakkara <[email protected]> > wrote: > >> 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.securev >>>>>>>> ault.repository.DefaultSecretRepository >>>>>>>> parameters: >>>>>>>> privateKeyAlias: wso2carbon >>>>>>>> keystoreLocation: resources/security/wso2carbon.jks >>>>>>>> masterKeyReader: >>>>>>>> type: org.wso2.carbon.kernel.securev >>>>>>>> ault.reader.DefaultMasterKeyReader >>>>>>>> >>>>>>>> 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.DefaultSecret >>>>>>>> Repository and org.wso2.carbon.kernel.securevault.reader.Def >>>>>>>> aultMasterKeyReader) 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.secur >>>>>>>> evault.repository.DefaultSecretRepository >>>>>>>> parameters: >>>>>>>> privateKeyAlias: wso2carbon >>>>>>>> keystoreLocation: securevault/resources/security/wso2carbon.jks >>>>>>>> secretProperties: securevault/resources/security >>>>>>>> /secrets.properties >>>>>>>> masterKeyReader: >>>>>>>> type: org.wso2.carbon.secvault.secur >>>>>>>> evault.utils.DefaultHardCodedMasterKeyReader >>>>>>>> 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 <+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/> >> > > > > -- > Lakshman Udayakantha > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > Mobile: *0717429601* > > 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
