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.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.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.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 <+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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
