Maven brought a major change in build process of a project. Prior to Maven, we enjoyed freedom of project structure and library location etc. But maven has taken the JEE project structure contract to next level. It has solved many problems from a project deployment e.g. control over project library, simple xml based definition of dependencies, creation of project structure that can be directly imported in standard libraries. In this article, I am expecting readers to be aware of maven technology and how the maven builds work.

Prior to maven 2.1, there is little that directly addresses security of the files and folders involved in build. First question would be – where do we need security? Let us try to find out what all we would like to secure during a build process. Then, we see the alternatives available prior to this maven version. Last, we explore the new feature provided by maven.

Where do we need security?

Answer is simple, security is need for the files and folders involved in build process. Here is the list of files that are involved:

• Source Files
• Repositories
• Files Created During Build

Let us leave the source file security to the source control mechanism used. We just get the files extracted from source control and use those for build. Maven can be used to build on development environment as well as for test or production deployments. If it is development environment, then we are not much concerned about security as that for other two environments. For development box, we may want to apply security to the centralized repositories only. But in case of test or production environments, we may have many files that store passwords and other security information. Also we may want to strictly control the repository access.

Next, we discuss how the security was implemented prior to this maven release.

Security Implementation Prior to Maven 2.1:

To secure repositories, we controll access to the repositories itself, i.e. access to the repository folders can be defined using operating system security. Whenever someone performs build using these repositories, permissions to that user play a role while connecting to the repositories and accessing information. If it is read only access,the user can read the libraries, download those to local machine and continue building those. But cannot add or modify anything in the repositories.

Second is the security of the files. These files are created on locations defined through the server tags as shown below.

<server>
      <username/>
      <password/>
      <privateKey/>
      <passphrase/>
      <filePermissions/>
      <directoryPermissions/>
      <configuration/>
      <id/>
</server>

In this server definition, we have file permissions element which can be used to define the permission of files getting created. Also, the directories getting created will have permission being defined. Thus the distribution of these files will be managed.

If we observe above xml snippet, then we can see the problem clearly. This xml snippet contains user and password information required to connect to the server. If we have access to the build box containing this snippet in setting.xml then the password is clearly visible, and can be used for other unwanted purposes. In recent release of maven (2.1.0), it goes further and tries to protect the authentication parameters required to connect to the distribution servers.

Security with Maven 2.1.0:

There are two features to fix above problem.

• Maven allows encryption of the password in server element
• Encrypted password can be stored at remote location

Encrypt Password:

Password can be encrypted using following command.

>mvn –encrypt-password <password>

This command will encrypt the password to a string something like this.

>{abCDEF12345Xyz+}

In This password, { and } are used to enclose the password. When maven finds these two braces in password field, it understands that this is an encrypted password. If the encrypted string itself contains any of these braces, we need to escape those. This escaping feature is going to be part of maven 2.2.0, in which this can be escaped using ‘\’ prior to the braces.

Add this password to the server definition in settings xml.

    <server>
      <id>server1</id>
      <username>userName</username>
      <password>{abCDEF12345Xyz+}</password>
    </server>

Remote Storage of Encrypted Master Password:

Above encryption command changes slightly when it is master password.

>mvn -encrypt-master-password <password>

To store the encrypted password at remote location, create a settings-security.xml file and add password as shown below.

	<settingsSecurity>
		<master>{abCDEF12345Xyz+}</master>
	</settingsSecurity>

Store this file to some location say ‘/Data/myUSBDrive/settings-security.xml’ and give the location in original settings-security.xml that is stored in local ‘../m2′ directory, as shown below. This is how we relocate the file.

<settingsSecurity>
  <relocation>/Data/myUSBDrive/settings-security.xml</relocation>
</settingsSecurity>

Finally this secured server definition will be used in distributionManagement tag of pom.xml files.

    <distributionManagement>
        <site>
            <id>server1</id>
            <name>Server1</name>
            <url>
                scp://repository/internal
            </url>
        </site>
    </distributionManagement>

 

 

Summary:

Recent version of maven takes security concern in it’s own tray and solves it. This is not a major security feature, but still it is good start and we can hope more in upcoming releases.

 

 

More Related Posts in Tech Notes