WebLogic Encryption and Domains

When building out WebLogic domains, some of the biggest tasks to accomplish are scripting of creating a domain, scripting WebLogic resources, and utilizing our build architecture to provide jobs for pushing out resources to our WebLogic domain. The reason is I should never be manually configuring a domain because that increases the room for error when promoting domain changes between environments, and complicates the ability to rebuild a new domain based on a previous one. By scripting out the domain creation, along with the ability to promote resources via a build environment, I greatly increase the time required to build a brand new environment. The Hudson CI build server can be used to produce SCP jobs that copy necessary logging files or classpath jars, and I can utilize the maven-weblogic-plugin to deploy JMS and JDBC resources, however the plugin has bugs in deploying optional packages.

When creating WebLogic domains, I can configure the domain to be either Development or Production Modes. In order to do development against clustered environments like production environments, the WebLogic Server will be configured as “Production Mode” in all environments. The one issue that this can cause is that resources (such as JDBC Configurations) require the database password to be encrypted. In order to do this, a user must encrypt the password utilizing the domains salt file (SerializedSystemIni.dat). This can be done via command line in the WebLogic Domain, by configuring the maven exec plugin, or by using WebLogic custom APIs as in this post that has a class named SecurityHelper.

In order to encrypt passwords via a maven project, all I need to do is take advantage of the weblogic.security.Encrypt class and utilize a maven plugin that will allow us to execute it. One way to do this is to utilize the exec-maven-plugin. As the documentation describes, it helps execute system or Java programs. So in order to invoke weblogic.security.Encrypt, I will need to understand what type of parameters are necessary. The main piece of configuration it needs is the domain root directory, but it does not need this information to access any executables. It only needs this pathing because it is going to append a relative path to it (security/SerializedSystemIni.dat) to determine where the salt is located. So I can utilize this parameter to utilize different salt files for different environments (therefore enabling us to encrypt passwords for any environment I store a salt file for).

So in the following image, I have 3 environments (sandbox, development, production) and I have our salt files from the server checked into this project. I now only have to flip the env folder (like sandbox) as the WebLogic Root Domain parameter, when I want to build a password based on this env.

The following is the sample pom file which uses the mvn exec:exec plugin/goal to execute the Encrypt class.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <name>WLS ENV Encrypt</name>
    <description>Encrypts WLS JDBC Passwords - mvn exec:exec</description>
                        <!-- automatically creates the classpath using all project dependencies,
                            also adding the project build directory -->
                        <classpath />
                        <!-- Password can be supplied as an argument or entered when
                        the maven build is run -->

So I can invoke mvn exec:exec -Ddomain.root=dev, then the dev/security/SerializedSystemIni.dat file will be used to encrypt the properties. This greatly simplifies the creation of data sources, as an administrator doesn’t have to log into the remote server and run a shell script that invokes the Encrypt class.

But what if you have multiple domains, it would seem to complicate the issue to have all the SerializedSystemIni.dat files in SVN. This does have some benefits though incase the file/domain gets corrupted, which can happen. So to resolve this issue, I can share a salt file between multiple domains (like all non-prod servers use the same salt and all prod servers use the same salt). When WebLogic Server builds out a domain, it creates the salt file and then uses that to encrypt passwords within the config.xml and also the weblogic username/password within the boot.properties. The interesting thing is that you can override a pre-existing domains configuration with another domains configuration in order to share the salt files.

  1. Install our first non-prod domain
  2. Backup the SerializedSystemIni.dat, config.xml, and the boot.properties file
  3. Create our second non-prod domain
  4. First backup the files listed in step #2 on this second domain
  5. Copy the SerializedSystemIni.dat from our first domain to the security folder in our second domain
  6. Either do a straight copy or use a compare tool to copy over passwords from our domain one config.xml to our domain two’s config.xml
  7. Do the same thing for the boot.properties

It was really surprisingly that simple. Once the domain was brought up, I was able to use my maven project to create an encrypted password that I placed into a JDBC Resource Config file and deployed to the container and it was testable through the WebLogic console. As I stepped through this process, the domain would not correctly start if I used the wrong encrypted username/password in the boot.properties. I was able to easily resolve these issues primarly by making sure that the config.xml and boot.properties used the correct new salt for encrypting any of the passwords.

As I stated in the first paragraph, the reason for doing all these steps is really because I don’t want to be creating JDBC or JMS resources through the console. So in order to promote these types of resources via a Hudson Job, I have to figure how I would encrypt the JDBC password for the different domains (each that had their own salt file). So by utilizing the same salt in specific environments, having the salt files in SVN was more manageable and helped our ability to backup these files as well.

I have had some issues where the Managed Server fails to login with the WebLogic credentials, so the following steps are a cleaner way of backing up domain salt and config.xml, and using it to configure another domain with the same salts.

  1. Take a 64 bit (or 32 bit) domain install and backup the SerializedSystemIni.dat and the config.xml
  2. Go to another server and stop Admin/Mgd Server that is being modified.
  3. Delete data/cache under the Mgd Server
  4. SCP the backed up SerializedSystemIni.dat to the server.
  5. Replace $/security/SerializedSystemIni.dat with the one that was SCP’d to the server.
  6. Vi the config.xml: $/config/config.xml and replace 3 three passwords in it with the config.xml that I backed up in step 1 (these passwords are encrypted according to the salt).
  7. Go to $/servers/sandboxAdminServer/security/boot.properties and change the user/pwd to what you want weblogic/admin
  8. Start the Admin Server Only.
  9. Copy $/servers/sandboxAdminServer/security folder to $/servers/sandboxMgdServer1/security
  10. Start the Mgd Server.

Share and Enjoy