date:20170316

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Vidura Nanayakkara

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 
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 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 <
> niran...@wso2.com> wrote:
>
>> Hi Jayanga,
>>
>>
>> On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake 
>> 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: jaya...@wso2.com
>>> mobile: +94772207259 <+94%2077%20220%207259>
>>> 
>>>
>>> On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham <
>>> niran...@wso2.com> 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 <
 lakshm...@wso2.com> wrote:

> Hi Vidura,
>
> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
> 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
>>
>>

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Vidura Nanayakkara

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

> Hi Jayanga,
>
>
> On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake 
> 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: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>> On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham <
>> niran...@wso2.com> 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 <
>>> lakshm...@wso2.com> wrote:
>>>
 Hi Vidura,

 On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
 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]
> 
> , we decided to move Carbon Secure Vault out of Carbon Kernel for the
> specified reasons in [1]
> .
> 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

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Kishanthan Thangarajah

Could you explain the advantage of this proposed approach based on OSGi vs
non-OSGi mode of execution?

On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
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.
> DefaultSecretRepository
>   parameters:
> privateKeyAlias: wso2carbon
> keystoreLocation: resources/security/wso2carbon.jks
> masterKeyReader:
>   type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader
>
> However, according to the discussion made in [1]
> 
> , we decided to move Carbon Secure Vault out of Carbon Kernel for the
> specified reasons in [1]
> .
> 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).
>
> *Suggestion:*
>
> secretRepository:
>   type: org.wso2.carbon.secvault.securevault.repository.
> DefaultSecretRepository
>   parameters:
> privateKeyAlias: wso2carbon
> keystoreLocation: securevault/resources/security/wso2carbon.jks
> secretProperties: securevault/resources/security/secrets.properties
> masterKeyReader:
>   type: org.wso2.carbon.secvault.securevault.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)
> 
>
>
> Best Regards,
>
> *Vidura Nanayakkara*
> Software Engineer
>
> Email : vidu...@wso2.com
> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
> Web : http://wso2.com
> Blog : https://medium.com/@viduran 
> Twitter : http://twitter.com/viduranana
> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
> 
>



-- 
*Kishanthan Thangarajah*
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com *
Twitter - *http://twitter.com/kishanthan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Niranjan Karunanandham

Hi Jayanga,

On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake 
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: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham  > 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 > > wrote:
>>
>>> Hi Vidura,
>>>
>>> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
>>> 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]

 , we decided to move Carbon Secure Vault out of Carbon Kernel for the
 specified reasons in [1]
 .
 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

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Jayanga Dissanayake

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.

Thanks,
Jayanga.

*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: jaya...@wso2.com
mobile: +94772207259


On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham 
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 
> wrote:
>
>> Hi Vidura,
>>
>> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
>> 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.DefaultMasterKeyReader
>>>
>>> However, according to the discussion made in [1]
>>> 
>>> , we decided to move Carbon Secure Vault out of Carbon Kernel for the
>>> specified reasons in [1]
>>> .
>>> 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)
>>> 
>>>
>>>
>>> Best Regards,
>>>
>>> *Vidura Nanayakkara*
>>> Software Engineer
>>>
>>> Email : vidu...@wso2.com
>>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>>> Web : http://wso2.com
>>> Blog : https://medium.com/@viduran 
>>> Twitter : http://twitter.com/viduranana
>>> LinkedIn :

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Niranjan Karunanandham

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

> Hi Vidura,
>
> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
> 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.DefaultMasterKeyReader
>>
>> However, according to the discussion made in [1]
>> 
>> , we decided to move Carbon Secure Vault out of Carbon Kernel for the
>> specified reasons in [1]
>> .
>> 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)
>> 
>>
>>
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : vidu...@wso2.com
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran 
>> Twitter : http://twitter.com/viduranana
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> 
>>
>
>
>
> --
> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Lakshman Udayakantha

Hi Vidura,

On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara 
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.
> DefaultSecretRepository
>   parameters:
> privateKeyAlias: wso2carbon
> keystoreLocation: resources/security/wso2carbon.jks
> masterKeyReader:
>   type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader
>
> However, according to the discussion made in [1]
> 
> , we decided to move Carbon Secure Vault out of Carbon Kernel for the
> specified reasons in [1]
> .
> 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.
> DefaultSecretRepository
>   parameters:
> privateKeyAlias: wso2carbon
> keystoreLocation: securevault/resources/security/wso2carbon.jks
> secretProperties: securevault/resources/security/secrets.properties
> masterKeyReader:
>   type: org.wso2.carbon.secvault.securevault.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)
> 
>
>
> Best Regards,
>
> *Vidura Nanayakkara*
> Software Engineer
>
> Email : vidu...@wso2.com
> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
> Web : http://wso2.com
> Blog : https://medium.com/@viduran 
> Twitter : http://twitter.com/viduranana
> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
> 
>



-- 
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: *0717429601*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

2017-03-16 Thread Minoli Perera

Hi Kasun,

On Thu, Mar 16, 2017 at 1:55 PM, KasunG Gajasinghe  wrote:

>
>
> On Thu, Mar 16, 2017 at 8:50 AM, Pushpalanka Jayawardhana 
> wrote:
>
>>
>>
>> On Thu, Mar 16, 2017 at 8:46 AM, Pushpalanka Jayawardhana > > wrote:
>>
>>> Hi All,
>>>
>>> I am working on implementing 'add group' and 'update group' UIs for IS
>>> 6.0.0 as per the wire-frames [1] and [2].
>>>
>>> In group addition, user experience will be as, in the 'General' tab user
>>> provides name and description of the role.
>>> User can either conclude the group addition flow here or go to 'Users'
>>> tab to select users who will be in this group.
>>> User can either conclude the flow here or go to 'Roles' tab to select
>>> the roles to be assigned to all the users in the newly added group.
>>>
>>
> What this means is this the 'General', 'Users', 'Roles' tabs are part of a
> wizard. Further, users don't need to complete all the pages in wizard; they
> can finish at any step.
>
> I think the current UI fails to capture that each of them are part of a
> wizard. It looks quite ambiguous to me. @Dakshika, Minoli, can you guys
> review this again to see what we can do? It may be as simple as adding a
> 'Next' button, or a complete overhaul.
>
> We apply wizards when there is a step by step mandatory process we want
the user to go through. But in this scenario adding users and roles are
optional. So IMO we cannot apply a wizard for this scenario. But we will
further review this and will update.

>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>
>


Thanks & Regards,
-- 
Minoli Perera,
Software Engineer, WSO2, Inc.
E-mail : mino...@wso2.com
Mobile : +94771567527 <+94%2077%20156%207527>

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5] Carbon Secure Vault YAML Configuration

2017-03-16 Thread Vidura Nanayakkara

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.DefaultSecretRepository
  parameters:
privateKeyAlias: wso2carbon
keystoreLocation: resources/security/wso2carbon.jks
masterKeyReader:
  type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader

However, according to the discussion made in [1]

, we decided to move Carbon Secure Vault out of Carbon Kernel for the
specified reasons in [1]
.
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).

*Suggestion:*

secretRepository:
  type:
org.wso2.carbon.secvault.securevault.repository.DefaultSecretRepository
  parameters:
privateKeyAlias: wso2carbon
keystoreLocation: securevault/resources/security/wso2carbon.jks
secretProperties: securevault/resources/security/secrets.properties
masterKeyReader:
  type:
org.wso2.carbon.secvault.securevault.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)



Best Regards,

*Vidura Nanayakkara*
Software Engineer

Email : vidu...@wso2.com
Mobile : +94 (0) 717 919277
Web : http://wso2.com
Blog : https://medium.com/@viduran 
Twitter : http://twitter.com/viduranana
LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Define Username Claim in Domain Level

2017-03-16 Thread Sagara Gunathunga

On Wed, Mar 15, 2017 at 6:50 AM, Thanuja Jayasinghe 
wrote:

> Hi Nuwandi,
>
> On Tue, Mar 14, 2017 at 1:54 PM, Nuwandi Wickramasinghe  > wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:42 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi Gayan,
>>>
>>> Yes. We need to specially handle username claim("http://wso2.org/claims/
>>> username").
>>>
>> So, it will always be http://wso2.org/claims/username, not configurable?
>>
>
> I see following performance related concerns if we marked some claim as
> the username claim using a property,
>
>
>
>- In every operation which we are going to specially handle for
>username claim, we need to check that property
>- If we want to get the username claim value, first we need to go
>through claims to identify the username claim and then retrieve the value
>for that claim
>
> Also, it will be much easier for the User object to retrieve username
> claim from a claim URI rather than a property. (We don't have the API
> support for retrieving claim value from a property)
>
> In a case like "email as username", we can still map the username claim to
> the email attribute. Then we can map the same email attribute to email
> claim to avoid the confusion.
>

If our implementation allows to map same attribute with 2 or more claims in
a consistence manner ( consistent in all CURD operations) then I'm +1 to
follow this approach

Thanks !

>
>
>>> Shall we add a method to User[1] class to retrieve username?
>>>
>> +1 to have a method in User.java
>>
>>>
>>> [1] -  https://github.com/wso2/carbon-identity-mgt/blob/master/com
>>> ponents/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/
>>> carbon/identity/mgt/User.java
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Tue, Mar 14, 2017 at 12:12 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 Don't we have to provide an API to get username claim from domain
 level.
 I am suggesting to have some thing like

 org.wso2.carbon.identity.mgt.User userStoreUser = identityStore.
 getUser(userId);
 userStoreUser.getUsernameClaim();

 Currently we handle username claim as just an another claim but it
 should be treated as special claim because username is the human friendly
 unique identifier for users.

 In domain-config.yaml we can define username claim for each domain.

 Also another requirement is when we get username from out side
 application, we need to retrieve corresponding user from identity store so
 we need to set value got from out side to appropriate claim. In that case
 there should be a way to identify username claim.

 WDYT?

 Thanks,
 Gayan


 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

>>>
>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Nuwandi Wickramasinghe
>>
>> Software Engineer
>>
>> WSO2 Inc.
>>
>> Web : http://wso2.com
>>
>> Mobile : 0719214873
>>
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>



-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

2017-03-16 Thread Sagara Gunathunga

On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana  wrote:

> Hi All,
>
> We are in the process of implementing password history validation feature
> for IS 6.0.0. Architecture of this feature was previously discussed in [1]
> by Isura for IS 5.3.0. We plan to follow same architecture with minor
> changes.
>
> Previously history validation has been done by checking only last 'n'
> number of attempts. Ex. you cannot use a password which is inside last 5
> attempts. This time we additionally validate time factor as well Ex. you
> cannot use a password, if there is a similar password with created date
> inside last 7days.
>

Can I assume followings ?

- As Identity Admin (IA) I don't want to make any restriction on new
passwords.

- As Identity Admin (IA) I can restrict not to use same password again
during next 'N' number of  password change attempts.

- As IA I can restrict  not to use same password again during 'T' time
duration in future regardless of number of attempts (check only time
duration) .

- As IA I can restrict  not to use same password again during next 'N'
number of password change attempts within  'T' time duration.

- As IA I can configure values for above "N" and "T" using deployment.yaml
file.


Also different questions about password management

- As IA can I force "all the users" in the system to change their password
after "T" duration, after this "T" duration when they login back with
current password they will redirect to update password page of the user
portal, without completing this step user can't perform any other actions.
Additionally I should able to apply one of above rule when changing the
password.

- IA should able to configure above "T" value using deployment.yaml file.

- IA should able to apply above rule only for selected set of users of the
system, say one or more groups

- IA should able to configure different values for above "T" per group
basis.


Thanks !


>
> Table structure will be changed as below since we have unique user ID in
> C5.
>
> *Previous *
>
> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>   ID INTEGER NOT NULL AUTO_INCREMENT,
>   USER_NAME   VARCHAR(255) NOT NULL,
>   USER_DOMAIN VARCHAR(127) NOT NULL,
>   TENANT_ID   INTEGER DEFAULT -1,
>   SALT_VALUE  VARCHAR(255),
>   HASHVARCHAR(255) NOT NULL,
>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>   PRIMARY KEY(ID),
>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
> )ENGINE INNODB;
>
>
> *New *
> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>   ID INTEGER NOT NULL AUTO_INCREMENT,
>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>   SALT_VALUE  VARCHAR(255),
>   HASHVARCHAR(255) NOT NULL,
>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>   PRIMARY KEY(ID),
>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
> )ENGINE INNODB;
>
> Password Hashing algorithm will be a configurable property.
>
> [1] [Architecture] Force Password Reset and Password History validation
>
> Thanks,
> Gayan
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

2017-03-16 Thread KasunG Gajasinghe

On Thu, Mar 16, 2017 at 8:50 AM, Pushpalanka Jayawardhana 
wrote:

>
>
> On Thu, Mar 16, 2017 at 8:46 AM, Pushpalanka Jayawardhana 
> wrote:
>
>> Hi All,
>>
>> I am working on implementing 'add group' and 'update group' UIs for IS
>> 6.0.0 as per the wire-frames [1] and [2].
>>
>> In group addition, user experience will be as, in the 'General' tab user
>> provides name and description of the role.
>> User can either conclude the group addition flow here or go to 'Users'
>> tab to select users who will be in this group.
>> User can either conclude the flow here or go to 'Roles' tab to select the
>> roles to be assigned to all the users in the newly added group.
>>
>
What this means is this the 'General', 'Users', 'Roles' tabs are part of a
wizard. Further, users don't need to complete all the pages in wizard; they
can finish at any step.

I think the current UI fails to capture that each of them are part of a
wizard. It looks quite ambiguous to me. @Dakshika, Minoli, can you guys
review this again to see what we can do? It may be as simple as adding a
'Next' button, or a complete overhaul.

Thanks,
KasunG



> At initial phase, only general and user tabs will be there as role
> management features are still to be reviewed.
>
>>
>> Same goes with the update flow.
>>
>> Claims will be defined for the group, to keep track of the attributes of
>> the group, such as group description.
>> Any thoughts are welcome to improve the flow or design.
>>
>> [1] - https://github.com/wso2-dev-ux/product-is/blob/master/Wire
>> frames/admin-portal/v3/4.2%20Add%20group%20-%20general%20info.png
>> [2] - https://github.com/wso2-dev-ux/product-is/blob/master/Wire
>> frames/admin-portal/v3/4.8%20Edit%20group%20-%20general%20info.png
>>
>> Thanks,
>> --
>> Pushpalanka.
>> --
>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
>> Mobile: +94779716248
>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>> ushpalanka/ | Twitter: @pushpalanka
>>
>>
>
>
> --
> Pushpalanka.
> --
> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
> Mobile: +94779716248
> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/
> pushpalanka/ | Twitter: @pushpalanka
>
>


-- 

*Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
phone: +1 650-745-4499, 77 678 0813
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

2017-03-16 Thread Imesh Gunaratne

On Thu, Mar 16, 2017 at 9:39 AM, Gayan Gunawardana  wrote:

>
> On Wed, Mar 15, 2017 at 10:19 AM, Imesh Gunaratne  wrote:
>>
>>
>> Would you mind explaining the purpose of the field SALT_VALUE?
>>
>

> In order to compare user given password with stored password salt value is
> required.
>

Thanks Gayan! I thought we use hash for that.

Thanks

>
>> Thanks
>> Imesh
>> 
>>
>>>
>>> Password Hashing algorithm will be a configurable property.
>>>
>>> [1] [Architecture] Force Password Reset and Password History validation
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



-- 
*Imesh Gunaratne*
Software Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

[Architecture] [C5] Carbon Secure Vault YAML Configuration

Re: [Architecture] Define Username Claim in Domain Level

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

Re: [Architecture] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

13 matches

Site Navigation

Mail list logo

Footer information