Yes, that would work but it requires:

1. either a change at ConfigAdmin layer (difficult and not accurate IMHO)
2. a Karaf service that application (like Pax JDBC) can leverage when a
{CRYPT}hash{CRYPT} property value pattern is detected.

Karaf JAAS already has EncryptionService providing encryption only. We have two
implementation of this service:
- Basic (BasicEncryptionService)
- Jasypt (JasyptEncryptionService)

I can extend the EncryptionService to also provide decrypt and check.

Regards
JB

On 02/19/2018 01:56 PM, Alex Weirig wrote:
> That's correct and that's what I'm trying to solve (or work around).
> 
> E.g.
> 
> I need to store my mysql password in the config file. The password is 1234pwd.
> 
> Imagine we have a karaf command that's config:encrypt.
> 
> I use config:encrypt 1234pwd and it returns a hash, this hash would computed
> using a master password that would be different for each karaf instance based 
> on
> it's "environment".
> 
> Now when ConfigAdmin reads the configuration file it will know how to compute
> the master password and decrypt the password and use the decrypted password
> (1234pwd) with the datasource or JDBC connection.
> 
> Since there would be no "API" to do this decryption "by hand" nobody would
> "easily" be able to get access to the decrypted password.
> 
> I'm currently looking if each karaf instance has some kind of a GUID or if 
> there
> is some kind of GUID available from the system or something else that could be
> used to compute the instance related master password.
> 
> So basically the idea is to make the decryption "configuration" a system 
> feature?
> 
> Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards,
> 
> Alex Weirig
> Responsable Technique
> 
> Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
> LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel:
> +352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu 
> <http://www.technolink.lu>
> 
> On 19/02/2018 13:44, Jean-Baptiste Onofré wrote:
>> Hi Alex,
>>
>> The problem is the "direction".
>>
>> Let me take an example: the encryption service we have to crypt passwords in
>> etc/users.properties.
>> Here's the direction is pretty simple: the user provides the password, we
>> encrypt the password using the configuration defined in
>> etc/org.apache.karaf.jaas.cfg and we compare the hashes: if the hash is the 
>> same
>> as the one contained in the etc/users.properties, then, it's OK.
>>
>> But the user provides his password.
>>
>> In any cfg configurations, it's the opposite: the application (let's say
>> pax-jdbc or your own application) expects the property value in clear text
>> whereas it's stored encrypted. So, it means that somehow we have to start 
>> from
>> the encrypted property value to provide the clear text one.
>> For instance, you are using pax-jdbc for datasources. You want to store the
>> database password encrypted in the cfg file. However, to actually establish 
>> the
>> connection, we have to use the password in clear text. So, we have to 
>> decrypt.
>>
>> So a generic solution at ConfigAdmin layer would require decrypt->clear
>> direction which obviously require the decryption "configuration".
>>
>> Regards
>> JB
>>
>> On 02/19/2018 01:31 PM, Alex Weirig wrote:
>>> Hi Jean-Baptiste,
>>>
>>> that sounds like an interesting idea but you are pointing at an obvious 
>>> drawback
>>> with these solutions...
>>>
>>> If we're using a "master password" (like jasypt) we need to provide this 
>>> master
>>> password in order to allow decryption of the password. That master password 
>>> has
>>> to be available in clear text but then, at the end of day you're only 
>>> protecting
>>> your environment against "hackers" that are able to "hack" you systems but 
>>> "too
>>> stupid" to decrypt the password using the master password.
>>>
>>> Possibly storing the password in a file with limited ownership access rights
>>> might help a little bit but if the hacker has (root) access he will get 
>>> around
>>> that too.
>>>
>>> I was thinking if it would be possible to create a "karaf password 
>>> encryption
>>> feature" where each karaf instance would have it's own computable (since we
>>> can't store it) "master password" (maybe based on a machine identifier) and
>>> would allow you to encrypt the password but there would be no "API or 
>>> utility"
>>> to allow the user to decrypt the password.
>>>
>>> Now the "hacker" would need more knowledge to get access to the passwords 
>>> ...
>>>
>>> Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind 
>>> regards,
>>>
>>> Alex Weirig
>>> Responsable Technique
>>>
>>> Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
>>> LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel:
>>> +352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu 
>>> <http://www.technolink.lu>
>>>
>>> On 19/02/2018 08:03, Jean-Baptiste Onofré wrote:
>>>> Hi Alex,
>>>>
>>>> We can imagine to add a feature that detect property values with a pattern
>>>> (for instance {CRYPT}hash{CRYPT}) and decrypt the value (so it has to be a
>>>> symetric encryption to allow to decrypt).
>>>>
>>>> I already thought about a Karaf ConfigAdmin "interceptor" to do that. But 
>>>> it
>>>> has to be at ConfigAdmin level to be reliable.
>>>>
>>>> Jasypt works that way assuming you are in blueprint (it provides a 
>>>> blueprint
>>>> specific namespace that decrypt the property values at blueprint:cm level).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 19/02/2018 07:52, Alex Weirig wrote:
>>>>> Thank you very much to everybody who responded to my question.
>>>>>
>>>>> I will have a look at your recommended approaches.
>>>>>
>>>>> Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind 
>>>>> regards,
>>>>>
>>>>> Alex Weirig
>>>>> Responsable Technique
>>>>>
>>>>> Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
>>>>> LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> 
>>>>> Tel:
>>>>> +352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu 
>>>>> <http://www.technolink.lu>
>>>>>
>>>>> On 10/02/2018 21:06, Jean-Baptiste Onofré wrote:
>>>>>> True, but jasypt namespace is blueprint specific.
>>>>>>
>>>>>> Outside of blueprint (directly in ConfigAdmin), you have to use your own
>>>>>> wrapper.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 02/10/2018 05:32 PM, Ryan Moquin wrote:
>>>>>>> You can still put the placeholders in a config file without using
>>>>>>> blueprint, but
>>>>>>> you need them injected into something that will resolve those
>>>>>>> placeholders.  In
>>>>>>> this case, the only thing I can suggest offhand (and it's not hard), 
>>>>>>> would
>>>>>>> be to
>>>>>>> use a Configuration listener (I think that's the name of the interface,
>>>>>>> it's for
>>>>>>> listening to when. PID is available in configuration admin), then when 
>>>>>>> your
>>>>>>> config becomes available, you check for the encrypted properties and 
>>>>>>> decrypt
>>>>>>> them.  You'd have to retrieve the encryption service via your listener. 
>>>>>>> That is
>>>>>>> probably how Blueprint does it.
>>>>>>>
>>>>>>> Ryan
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 10, 2018, 9:22 AM Weirig, Alex <alex.wei...@technolink.lu
>>>>>>> <mailto:alex.wei...@technolink.lu>> wrote:
>>>>>>>
>>>>>>>      Hello,
>>>>>>>
>>>>>>>      I wonder if there is a way to use the jasypt feature in Karaf 
>>>>>>> 4.1.4 to
>>>>>>>      encrypt passwords in configuration files without having to define 
>>>>>>> the
>>>>>>>      placeholders using Blueprint but rather using a cfg file in /etc/?
>>>>>>>
>>>>>>>      All the examples I've found so far are rather "old" and still rely 
>>>>>>> on
>>>>>>>      Blueprint ... I'm not using Blueprint at all in my applications 
>>>>>>> and I
>>>>>>> would
>>>>>>>      appreciate if I didn't have to use it just for this configuration.
>>>>>>>
>>>>>>>      If it was possible to define these placeholders in a cfg file in 
>>>>>>> /etc/ it
>>>>>>>      would make things easier ... or is there even an easier way to 
>>>>>>> support
>>>>>>>      encrypted properties with the current Karaf releases?
>>>>>>>
>>>>>>>      Thank you very much for your support
>>>>>>>
>>>>>>>      ---
>>>>>>>
>>>>>>>      Schéin Gréiss,
>>>>>>>      Mit freundlichen Grüßen,
>>>>>>>      Meilleures salutations,
>>>>>>>      Kind regards,
>>>>>>>
>>>>>>>      Alex Weirig
>>>>>>>      Responsable Technique
>>>>>>>
>>>>>>>      Ville de Luxembourg - Centre Technolink
>>>>>>>      2, rue Charles de Tornaco
>>>>>>>     
>>>>>>> <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g>
>>>>>>>      L - 2623 LUXEMBOURG
>>>>>>>      alex.wei...@technolink.lu  <mailto:alex.wei...@technolink.lu>
>>>>>>>
>>>>>>>      Tel: +352 4796 - 6127
>>>>>>>      Fax: +352 42 88 81
>>>>>>>      www.technolink.lu  <http://www.technolink.lu>
>>>>>>>
>>>>>>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to