Hi Chetan,
2015-12-10 12:54 GMT+01:00 Chetan Mehrotra <chetan.mehro...@gmail.com>:
> Hi Timothée,
>
> On Thu, Dec 10, 2015 at 4:59 PM, Timothée Maret
> <timothee.ma...@gmail.com> wrote:
> > However, I think that encryption and decryption go in pair (use the same
> > algo) and maybe it would be best to reflect it in the API.
>
> From what I understand Its main usecase is to allow components in Oak
> to make use of encrypted credentials which interacting with third
> party services. For e.g. in LDAP the password to access LDAP server
> can be encrypted and Oak LDAP logic would need to use some API to
> decrypt it. How it is encrypted and what is the encryption algo is not
> the concern of this logic. The encryption algo might be encoded in the
> encrypted config itself.
>
I agree, LDAP requirement described in OAK-3626 is the primary driver for
this API.
Encrypting an OSGI configuration property (e.g. "bindPassword" in the case
of LDAP) would require encrypting the value using a tool and then store the
encrypted value in the OSGI configuration.
The component bind to the OSGI configuration would decrypt the property
using the API when needed.
>
> So just having support for following call would be sufficient
>
> -----
> //one can use a byte[] also as argument type but keeping it string
> //as the key would be provided via some property file/OSGi
> //config and hence would be expected to be encoded say in base64
>
> byte[] decrypt(String cipherText)
> -----
>
We still need a tool to encrypt the values. The tool would need an
"encrypt" signature.
If the "encrypt" signature is part of the API we could swap the
implementation while keeping the tool as is.
If this is not required and as long as we don't see a use case for an Oak
component to invoke the "encrypt" signature, then I agree that we could
avoid exposing this signature in the API.
Once the requirement exists, the API could still be extended with an
"encrypt" signature.
>
> And this is the api which can be used in other places also (say
> decrypting Mongo connection credentials)
>
Ok, so the implementation must not leverage the mongo storage.
>
> Further the implementation might vary quite a bit
>
> 1. Credentials obtained from third party service - cipherText might be
> a logical name of some credential config - Say prod1LdapPwd. And in
> that deployment there is support for some third party credential
> storage server which can provide the credentials at runtime. In such
> deployment even the encrypted key would not be present in local system
> and the crypto implementation would use that service SDK to fetch the
> credential at runtime (using some off band authentication to that
> service)
>
> 2. cipherText having algo encoded - For some impl the cipherText would
> be like '{AES/CBC/PKCS5Padding}<encrypted key base64>' -
> Implementation can then decode the value as per requirement
>
> So how the encrypted key is created and managed is not a concern for
> Oak logic. For Oak it just need a way to get plain text credential
> given some opaque key data. Any method related to encrypting would not
> be used by other part of Oak so need not be part of API which we
> expose as extension point
>
>
Ok we could start with the very minimal requirement.
I'll work on a patch that only exposes the decrypt signature but provide a
tool to encrypt values.
> Chetan Mehrotra
>
Regards,
Timothee
