How to use SecureVault when WSO2 Carbon servers are started as background processes

SecureVault can be used to encrypt the plain-text passwords specified in various configurations files in WSO2 Carbon products. You can find more information about how to secure plain-text passwords using securevault in this blog written by Asela.

When you use SecureVault to encrypt the passwords as explained there, you are supposed to specify the primary keystore password at the server startup. However, this is not possible when you start the server as a background process.

This post summarizes the complete procedure of securing plain text passwords using secure vault and additional configurations when you start the server as a background process.

Suppose, we need to encrypt the LDAP ConnectionPassword value in CARBON_HOME/repository/conf/user-mgt.xml

  1. Locate cipher-text.properties which can be found at CARBON_HOME/repository/conf/security directory
  2.  Keep a back up of the cipher-text.properties file
  3.  Now, remove all key-value pairs which have there by default in cipher-text.properties file.(In this example, we just need to encrypt ConnectionPassword value)
  4. Add the following line. Make sure to include your plain_text LDAP connection password in [plain_text_ldap_password]

    UserStoreManager.Property.ConnectionPassword=[plain_text_ldap_password]
  5.  Locate ciphertool.sh script which can be found at CARBON_HOME/bin directory
  6.  Run ciphertool.sh as follows
      ciphertool.sh -Dconfigure

    This will prompt "[Please Enter Primary KeyStore Password of Carbon Server : ]" message. Enter "wso2carbon" as the primary keystore password
  7.  If the script execution completed successfully, you will see the following message.
    "Secret Configurations are written to the property file successfully"
  8.  Now, go back and look at the cipher-text.properties file. The plain text LDAP password will be replaced by a cipher value.
  9.  You will also look at CARBON_HOME/repository/conf/user-mgt.xml where we have specified the connection password for LDAP user.
    You will notice that it will be modified by the ciphertool script as follows.
    <Property name="ConnectionPassword" svns:secretAlias="UserStoreManager.Property.ConnectionPassword">password</Property>
  10. Now, you can start the server.
    e.g:- sh wso2server.sh
  11. This will prompt "[Enter KeyStore and Private Key Password :]" at the server startup because we need to decrypt the encrypted passwords to connect to LDAP.
    You can enter "wso2carbon" and the server will be started successfully.

    But you will not be able to provide this password value if you start WSO2 Carbon server as a background process.
    i.e:- ./wso2server.sh start
    In that case, you can follow a simple set of additional steps as explained below
  12. Have a file named "password-tmp" in CARBON_HOME/ directory. Add "wso2carbon" (the primary keystore password) to this file and save
  13. Now, start the server as a background process.
    ./wso2server.sh start
  14. Keystore password will be picked up from password-tmp file. Once the server is started, this fill will automatically be deleted from the file system. Make sure to add this temporary file back whenever you start the sever as a background process.
          NOTE : If you make the name of the password file as "password-persist" instead of "password-tmp" then the fie will not be deleted after reading. Then you don't need to provide the password in subsequent startups.



        

Comments

Unknown said…
Very valuable post..thanks
November 12, 2013 at 10:16 AM
Anonymous said…
Very useful post Charitha ayya!
July 16, 2014 at 1:49 PM
Anonymous said…
"Have a file named "password-tmp" in CARBON_HOME/ directory. Add "wso2carbon" (the primary keystore password) to this file and save"

FYI, on windows platforms, this file has to be named "password-tmp.txt" otherwise it won't work.
September 16, 2014 at 9:20 AM
Post a Comment

Popular posts from this blog

WSO2 Stratos - Introducing WSO2 middleware Platform as a Service (PaaS)

Image
Yesterday we released our newest integrated cloud middleware platform, WSO2 Stratos . It is now online and ready for use! For the past few years, WSO2 has been doing many releases based on revolutionary Carbon platform , which helped to consistently improve the platform with introducing latest state-of-art technologies. The initial releases of Carbon product platform intended to improve the features of the individual products. For example, a lot of core features were introduced to WSO2 ESB, WSAS, Governance Registry etc.. Then we focused on ease of integration and more component based model. We introduced Equinox based provisioning model to build your SOA platform by picking and choosing the components as and when you need. Then, the core product platform has been enhanced to support multi-tenancy. With the multi-tenant supported architecture at hand, our brilliant development team was able to introduce the first ever comprehensive middleware PaaS. Why is this so important? Now, WSO2 C...
Read more

Common mistakes to avoid in WSO2 ESB - 1 - "org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL"

In the next few weeks, you could expect a series of blog posts from me which explain the remedies to avoid some common mistakes which we do when working with WSO2 ESB . This is the first of many. During the initial rounds of testing your integration solution or even in production systems, you may have come across the following error. org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL .... Some of you may have struggled hours figuring out a solution to address this issue. Let me explain this error in detail and possible causes of this. So, next time when you see this error in your WSO2 ESB setup, you will not have to spend time unnecessarily googling everywhere. There can be many different causes of this error. I have observed  four main reasons. Cause 1 This is the simplest cause. Suppose, you have a proxy service similar to the following. <proxy xmlns="http://ws.apache.org/ns/synapse" name="MistakesTest...
Read more

Working with HTTP multipart requests in soapUI

Image
You can use HTTP request test step in soapUI to submit messages with various Content-Types.  In this post, we will have a quick look into the multipart/form-data requests in soapUI. multipart/form-data requests usually come into action when you do HTML form submissions with file attachments. For example, have a look at the following HTML form post. <form action="http://localhost:8090/CKFileUploadApp/UploadServlet" method="post" enctype="multipart/form-data"> <input type="file" name="file"> <input type="text" name="paramName"> <input type="submit" name="Submit" value="Upload File"> </form> In the forms like above, we have file upload option as a form input where we can upload a file along with the form submission. In that case, the request's HTTP content type will be multipart/form-data. How can we simulate such a request using soapUI...
Read more