Hi,
There are two functionalities can be identified in the secure vault
loading.
1. Reading the secure-vault.yaml and initializing instance variables from
values in file.
2. Initialising the master key reader secret repository and load secrets to
secret repository.
According to the desgin these functionalities reside in
SecureVaultComponent. After refactoring the code reading secure-vault.yaml
and initialising and common code moved to a new class called
SecureVaultInitializer. Code related to OSGI has been kept in
SecureVaultComponent class and common functions have moved to
SecureVaultInitializer class. After refactoring basic class and method
structures as follows.
Class SecureVaultInitializer {
public void initFromSecureVaultYAML() {
//reading secure vault yaml and initialising runtime variables happens here
}
public SecureVault initializeSecureVault(String masterKeyFilePath, String
secretPropertiesFilePath, String secureVaultYAMLPath) {
//initialise secure vault for SPI case
}
public SecureVault initializeSecureVault() {
//initialise the securevault in general.
}
}
Class SecureVaultComponent {
public SecureVaultComponent() {
//call SecureVaultInitilizer.initFromSecureVaultYAML method to read
secure vault yaml and initialise runtime variables
}
private void initializeSecureVault() {
// waiting for the references to resolve, call
SecureVaultInitializer.initializeSecureVault general case and register
securevault service in OSGI service registry
}
}
Class NonOSGIInvoker {
public static void main ( String[] args )
{
SecureVaultInitializer.getInstance().initializeSecureVault(masterKeysFilePath,
secretPropertiesFilePath, secureVaultYAMLPath).resolve(alias);
}
}
After discussion with team, It was decided to make entries in secure-vault
yaml optional and to provide one implementation of the providers of secret
repository and master key readers in class path. But this seems impossible
because there is already one implementation in securevault bundle which is
the default implementation. If non osgi secure vault coded to read only one
implementation, it always pick the default implementation because it first
look inside the bundle. Please raise any concern with the current
implementation to make it better.
Thanks,
Lakshman.
On Wed, Jan 4, 2017 at 10:23 PM, Lakshman Udayakantha <[email protected]>
wrote:
> Hi,
>
> The current implementation of secure vault functionality reside in carbon
> core component. So to make secure vault functionality available for non
> OSGI context, It can be separated out this piece of functionality as an
> OSGI bundle and remove tight coupling in code with OSGI context and users
> who wants to access non OSGI secure vault can get the separated bundle as a
> maven dependency. According to the current design there are three main sub
> components in secure vault.
>
> 1. Secret Repository
> 2. Master Key Reader
> 3. Secure Vault OSGI service.
>
> It can be plugged any secret repository implementation or any master key
> reader implementation to the code with the current implementation as
> pointed out in diagram [1].
> To expose these functionality via java SPI, it can be loaded secret
> repository and master key reader implementations to SecureVaultComponent
> via ServiceLoader class. Custom Secret Repositories and Custom Master key
> readers will be service providers. Then current SecureVault interface and
> implementation can be used without any redesign in code. Appreciate your
> thoughts and concerns on this.
>
> [1] SecureVault UML
> <https://drive.google.com/file/d/0B9KDy4GJKr1vS0NUOG5CRXhpMDg/view?usp=sharing>
>
> Thanks,
> --
> Lakshman Udayakantha
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
> Mobile: 0717429601
>
--
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
