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
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
