Karaf
  1. Karaf
  2. KARAF-34

Provide a way to have passwords encrypted and not in clear in the configuration files

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0
    • Component/s: None
    • Labels:
      None

      Activity

      Hide
      Jean-Baptiste Onofré added a comment -

      I propose to use commons-codec with Base64 to encode/decode strings containing senstitive data such as passwords.

      I'm gonna submit a patch around this.

      Show
      Jean-Baptiste Onofré added a comment - I propose to use commons-codec with Base64 to encode/decode strings containing senstitive data such as passwords. I'm gonna submit a patch around this.
      Hide
      Jean-Baptiste Onofré added a comment -

      The code/decode logic will be added in the ProxyLoginModule of the jaas/boot module.

      Show
      Jean-Baptiste Onofré added a comment - The code/decode logic will be added in the ProxyLoginModule of the jaas/boot module.
      Hide
      Charles Moulliard added a comment -
      Show
      Charles Moulliard added a comment - As ActiveMq project will use jasypt in version 5.4, why don't we use also jasypt http://old.nabble.com/encrypt-database-password-in-broker-config.xml-td25966501.html https://issues.apache.org/activemq/browse/AMQ-2460
      Hide
      Guillaume Nodet added a comment -

      It looks like a good solution.

      JB, why did you envision putting that logic in ProxyLoginModule rather than PropertiesLoginModule ?
      The proxy is loaded by the system bundle so we should avoid adding any dependency to it.

      Show
      Guillaume Nodet added a comment - It looks like a good solution. JB, why did you envision putting that logic in ProxyLoginModule rather than PropertiesLoginModule ? The proxy is loaded by the system bundle so we should avoid adding any dependency to it.
      Hide
      Jean-Baptiste Onofré added a comment -

      @Charles, thanks, it looks good to me.

      @Guillaume, agree, it's more elegant to put it in the PropertiesLoginModule.

      Show
      Jean-Baptiste Onofré added a comment - @Charles, thanks, it looks good to me. @Guillaume, agree, it's more elegant to put it in the PropertiesLoginModule.
      Hide
      Guillaume Nodet added a comment -

      Btw, I'm not really sure we need a two way encryption. A more secured one way encryption would work maybe even better. This would allow making sure the passwords are safe.

      Show
      Guillaume Nodet added a comment - Btw, I'm not really sure we need a two way encryption. A more secured one way encryption would work maybe even better. This would allow making sure the passwords are safe.
      Show
      Guillaume Nodet added a comment - See http://camel.apache.org/jasypt and http://www.jasypt.org/
      Hide
      Ioannis Canellos added a comment -

      Maybe, the logic should be put in KarafAbstractLoginModule, so that all LoginModule can inherit it.

      Show
      Ioannis Canellos added a comment - Maybe, the logic should be put in KarafAbstractLoginModule, so that all LoginModule can inherit it.
      Hide
      Jean-Baptiste Onofré added a comment -

      I think that we need to consider two kinds of passwords:

      • the passwords used in JAAS. This kind of passwords can be one-way crypted as the user retype it. I'm fine to implement the enhancement in the KarafAbstractLoginModule.
      • the "resources" passwords used internally in Karaf. This kind of passwords is not related at all to JAAS. For example, we can imagine that Karaf provide a kind of cypher service to crypt/uncrypt some properties such as database connection password, RMI registry connection password, etc.

      We can consider the enhancement in two steps. I begin with the first one.

      Show
      Jean-Baptiste Onofré added a comment - I think that we need to consider two kinds of passwords: the passwords used in JAAS. This kind of passwords can be one-way crypted as the user retype it. I'm fine to implement the enhancement in the KarafAbstractLoginModule. the "resources" passwords used internally in Karaf. This kind of passwords is not related at all to JAAS. For example, we can imagine that Karaf provide a kind of cypher service to crypt/uncrypt some properties such as database connection password, RMI registry connection password, etc. We can consider the enhancement in two steps. I begin with the first one.
      Hide
      Jean-Baptiste Onofré added a comment -

      For now, I implement it in the PropertiesLoginModule.

      Implementing in the login() method of the AbstractKarafLoginModule can be interesting but I prefer to focus on the PropertiesLoginModule first as it will update the users properties file.

      Show
      Jean-Baptiste Onofré added a comment - For now, I implement it in the PropertiesLoginModule. Implementing in the login() method of the AbstractKarafLoginModule can be interesting but I prefer to focus on the PropertiesLoginModule first as it will update the users properties file.
      Hide
      Jean-Baptiste Onofré added a comment -

      Usage of Jasypt in the PropertiesLoginModule involve that the JAAS module bundle has a new import package (org.jasypt).

      I raised a task on ServiceMix Jira to provide a Jasypt OSGi bundle (as it's not one by default):
      https://issues.apache.org/activemq/browse/SMX4-590

      Show
      Jean-Baptiste Onofré added a comment - Usage of Jasypt in the PropertiesLoginModule involve that the JAAS module bundle has a new import package (org.jasypt). I raised a task on ServiceMix Jira to provide a Jasypt OSGi bundle (as it's not one by default): https://issues.apache.org/activemq/browse/SMX4-590
      Hide
      Jean-Baptiste Onofré added a comment -

      ServiceMix Jasypt OSGi bundle created and deployed on the maven snapshot repository.

      Show
      Jean-Baptiste Onofré added a comment - ServiceMix Jasypt OSGi bundle created and deployed on the maven snapshot repository.
      Hide
      Jean-Baptiste Onofré added a comment -

      After discussing with Ioannis:

      • the AbstractKarafLoginModule will contain a new "crypt" attribute. It contains the encryption algorithm. If the crypt attribute is "plain" or null, no encryption is used.
      • all *LoginModule will embed the crypt logic module as they extend the AbstractKarafLoginModule
      • it means that the etc/users.properties file should contain password encrypted using the AbstractKarafLoginModule "crypt" algorithm (it can be plain as currently). We have to provide a user: shell commands to manage the user add/delete and password encryption (and write the etc/users.properties file in the case of the PropertiesLoginModule usage).
      Show
      Jean-Baptiste Onofré added a comment - After discussing with Ioannis: the AbstractKarafLoginModule will contain a new "crypt" attribute. It contains the encryption algorithm. If the crypt attribute is "plain" or null, no encryption is used. all *LoginModule will embed the crypt logic module as they extend the AbstractKarafLoginModule it means that the etc/users.properties file should contain password encrypted using the AbstractKarafLoginModule "crypt" algorithm (it can be plain as currently). We have to provide a user: shell commands to manage the user add/delete and password encryption (and write the etc/users.properties file in the case of the PropertiesLoginModule usage).
      Hide
      Jean-Baptiste Onofré added a comment -

      After thinking again about this, it's not easy to implement the encryption login in the AbstractKarafLoginModule as the login() method is delegated to each login module. The encryption login should be located in the login() method.

      The "common" part between all login module is that they call passwordCallback() in the login() method to get the password provided by the user.

      I propose to make a kind of encryptedPasswordCallback() on top of the passwordCallback(). It will get the plain password provided by the user and crypt using the crypt algorithm defined as attribute of the AbstractKarafLoginModule.

      Like this, each login module which uses the encryptedPasswordCallback() in place of passwordCallback() will get encrypted password.

      Show
      Jean-Baptiste Onofré added a comment - After thinking again about this, it's not easy to implement the encryption login in the AbstractKarafLoginModule as the login() method is delegated to each login module. The encryption login should be located in the login() method. The "common" part between all login module is that they call passwordCallback() in the login() method to get the password provided by the user. I propose to make a kind of encryptedPasswordCallback() on top of the passwordCallback(). It will get the plain password provided by the user and crypt using the crypt algorithm defined as attribute of the AbstractKarafLoginModule. Like this, each login module which uses the encryptedPasswordCallback() in place of passwordCallback() will get encrypted password.
      Hide
      Jean-Baptiste Onofré added a comment -

      After discussing with Guillaume, overriding callback has a huge impact on JAAS clients.

      I updated the AbstractKarafLoginModule to use jasypt and provide "util" methods to manipulate password.

      See revision 995565.

      The Karaf distributions have been updated too to load Apache ServiceMix Jasypt bundle at startup (required by JAAS Module bundle).

      Next steps are:

      • use these password methods in login modules (such as the PropertiesLoginModule)
      • update the PropertiesLoginModule to automatically crypt password provided in clear

      Any comments are welcome.

      Show
      Jean-Baptiste Onofré added a comment - After discussing with Guillaume, overriding callback has a huge impact on JAAS clients. I updated the AbstractKarafLoginModule to use jasypt and provide "util" methods to manipulate password. See revision 995565. The Karaf distributions have been updated too to load Apache ServiceMix Jasypt bundle at startup (required by JAAS Module bundle). Next steps are: use these password methods in login modules (such as the PropertiesLoginModule) update the PropertiesLoginModule to automatically crypt password provided in clear Any comments are welcome.
      Hide
      Jean-Baptiste Onofré added a comment -

      NB: to be able to use Jasypt, I added commons-codec and commons-lang ServiceMix bundles in the startup.

      Show
      Jean-Baptiste Onofré added a comment - NB: to be able to use Jasypt, I added commons-codec and commons-lang ServiceMix bundles in the startup.
      Hide
      Guillaume Nodet added a comment -

      I wonder if we should make this feature optional so that those three dependencies become a bit more optional.

      Show
      Guillaume Nodet added a comment - I wonder if we should make this feature optional so that those three dependencies become a bit more optional.
      Hide
      Jean-Baptiste Onofré added a comment -

      Yes, Guillaume.

      I propose:

      • to create an encryption feature including commons-codec, commons-lang and jasypt servicemix bundle + a karaf encryption bundle which register two password related services: one to encrypt, one to check password
      • in the AbstractKarafLoginModule, the default encryption algorithm is plain (no encryption)
      • if the encryption algorithm is different from plain (MD5, SHA-1, etc), the AbstractKarafLoginModule delegates the check and encrypt to the encryption service. If the service is not registered, I raise an IllegalStateException.

      What do you think ?

      Show
      Jean-Baptiste Onofré added a comment - Yes, Guillaume. I propose: to create an encryption feature including commons-codec, commons-lang and jasypt servicemix bundle + a karaf encryption bundle which register two password related services: one to encrypt, one to check password in the AbstractKarafLoginModule, the default encryption algorithm is plain (no encryption) if the encryption algorithm is different from plain (MD5, SHA-1, etc), the AbstractKarafLoginModule delegates the check and encrypt to the encryption service. If the service is not registered, I raise an IllegalStateException. What do you think ?
      Hide
      Guillaume Nodet added a comment -

      Looks perfect.

      Show
      Guillaume Nodet added a comment - Looks perfect.
      Hide
      Jean-Baptiste Onofré added a comment -

      NB: it means that we have a Karaf encryption interface and we will have a first implementation using jasypt.

      Show
      Jean-Baptiste Onofré added a comment - NB: it means that we have a Karaf encryption interface and we will have a first implementation using jasypt.
      Hide
      Jean-Baptiste Onofré added a comment -

      I have rollbacked my latest changes.

      I begin to add an ecnryption feature.
      In the Karaf feature core, we will have the encryption interface and the encryption feature bundle will implement the interface using Jasypt.

      Revision 995953.

      Show
      Jean-Baptiste Onofré added a comment - I have rollbacked my latest changes. I begin to add an ecnryption feature. In the Karaf feature core, we will have the encryption interface and the encryption feature bundle will implement the interface using Jasypt. Revision 995953.
      Hide
      Jean-Baptiste Onofré added a comment -

      After discussing with Guillaume, as the LoginModule is loaded by the JRE, it's not easy to "inject" something on it.

      The only way is to create a ThreadLocal in OsgiConfiguration storing the Encryption service reference (or the BundleContext):

      protected static ThreadLocal<Map<String,?>> params;

      public static void setParams(Map<String, ?> params)

      { AbstractKarafLoginModule.params.set(params); }

      and push it into the AbstractKarafLoginModule.

      Like this any LoginModule will get at least the BundleContext and so be able to use the Encryption service when needed.

      Show
      Jean-Baptiste Onofré added a comment - After discussing with Guillaume, as the LoginModule is loaded by the JRE, it's not easy to "inject" something on it. The only way is to create a ThreadLocal in OsgiConfiguration storing the Encryption service reference (or the BundleContext): protected static ThreadLocal<Map<String,?>> params; public static void setParams(Map<String, ?> params) { AbstractKarafLoginModule.params.set(params); } and push it into the AbstractKarafLoginModule. Like this any LoginModule will get at least the BundleContext and so be able to use the Encryption service when needed.
      Hide
      Jean-Baptiste Onofré added a comment -

      Revision 996679.

      Performed:

      • move jasypt encryption feature in jaas module
      • upgrade the encryption feature description
      • modify the Config JaasRealm to add the bundleContext in the login module options map
      • use the encryption service in the AbstractKarafLoginModule

      TODO:

      • add a AdminConfig property placeholder to inject the encryption attribute
      • use encryption it in the PropertiesLoginModule
      • crypt password when need and store it in the user properties file (in the PropertiesLoginModule).
      Show
      Jean-Baptiste Onofré added a comment - Revision 996679. Performed: move jasypt encryption feature in jaas module upgrade the encryption feature description modify the Config JaasRealm to add the bundleContext in the login module options map use the encryption service in the AbstractKarafLoginModule TODO: add a AdminConfig property placeholder to inject the encryption attribute use encryption it in the PropertiesLoginModule crypt password when need and store it in the user properties file (in the PropertiesLoginModule).
      Hide
      Jean-Baptiste Onofré added a comment -

      Revision 996922.

      Show
      Jean-Baptiste Onofré added a comment - Revision 996922.

        People

        • Assignee:
          Jean-Baptiste Onofré
          Reporter:
          Guillaume Nodet
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development