Using password handle when calling deployer

Hello,

we create and execute our deployer projects automatically (using “projectautomator.bat” and “Deploy.bat”).

The project automator can use password handles instead of passwords.

But we can’t find out how to use password handles in Deploy.bat (this would be the password the program uses to establish the connection to the deploy server).

Our goal is to avoid using the passwords (encrypted or clear text); we’d like to specify only handles.

Is it possible to use Deploy.bat with password handle? I couldn’t find an appropriate Option in webMethods Deployer User’s Guide.

Thanks!

1 Like

you can create the password handle in the Deployer and use that handle in the automater file
see screenshot.

Hello,

I know that it’s possible in the project automator. But in the deployer, I think, it’s not possible. It’s weird that two such closely related programs use different ways to specify the password.

I agree with you, that its very weird of not having the support of pwd handles in Deployer.bat.

Coming to your question -

  • ProjectAutomator will encrypt the password which is there in the pwd tag (for the first time). Copy this encrypted password
  • You create a configuration file under /packages/WmDeployer/bin/config.cnf

    Sample config file (D:\SoftwareAG\IntegrationServer\instances\WM_IS_Dev\packages\WmDeployer\bin\config.cnf) -
    host=enterpriseESB.com
    port=5555
    user=Deployer
    pwd={AES}345zUapDRbe5L8GqZtVQfA== (This password is the one which you copied in above step)

sample target from Build.xml for deploying the project (which uses the above config file) -


<target name="DeployProject">
		<echo message="Deploying the project to .... ${env}...!"/>
			<exec executable="cmd" dir="${deployer.home}/bin" failonerror="true">
				<arg value="/c" />
				<arg value="Deployer.bat"/>
				<arg value="--deploy" />
				<arg value="-dc" />
				<arg value="${proj.dc}" />
				<arg value="-project" />
				<arg value="${proj.name}" />
				<arg value="-configfile" />
				<arg value="D:\SoftwareAG\IntegrationServer\instances\WM_IS_Dev\packages\WmDeployer\bin\config.cnf" />
				<arg value="-reportFilePath" />
				<arg value="${build.output.dir}/deploymentReport" />
			</exec>
	</target>

Hello Naidu,

the password is encrypted, yes, but it can be easily decrypted. Our goal is to not have a password in any easily accessible file, neither encrypted nor in clear text.

fml2,

It’s not ideal but one thing you could do:

  1. Store your passwords in a password store that you trust
  2. In your automated script, retrieve the password from the store immediately before calling deploy.bat
  3. Do one of these two things:
    (a) Create the deployer config file dynamically using the password you retrieved from the store
    (b) Pass the password directly to deploy.bat via the -pwd argument

If you choose 3a above, be sure to delete the temporary config file after you call deploy.bat. If you choose 3b, make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file.

The password store could be the IS outbound store or really any other trustworthy store of your choosing.

Percio

fml2,

It’s not ideal but one thing you could do:

  1. Store your passwords in a password store that you trust
  2. In your automated script, retrieve the password from the store immediately before calling deploy.bat
  3. Do one of these two things:
    (a) Create the deployer config file dynamically using the password you retrieved from the store
    (b) Pass the password directly to deploy.bat via the -pwd argument

If you choose 3a above, be sure to delete the temporary config file after you call deploy.bat. If you choose 3b, make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file.

The password store could be the IS outbound store or really any other trustworthy store of your choosing.

Percio

Percio,

thank you for your ideas! We’ve eventually implemented something very similar to 3.b. We use the password store of the deployer IS. It works well for us.

The problem with “make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file” is that you can never know for sure who and how calls the script and how debugging and log redirection is configured.

But IMO we have now the best the product allows for.