webMethods

I would like to setup security around Deployer in such a way that only a specific user (not Administrator) can build and deploy projects from our QA system to the Prod system. Is this possible?

This will actually be me doing the deployments, signed on as this user, but this user will only exist within AD and will be kept Locked or Disabled until I request the account be activated and the password changed, I will login to Deployer, create and deploy the packages, logout and the account will be Disabled until needed again.

Does anyone use a similar process or can they recommend other options?

No other users, including Administrator, should be allowed to run any Deployer functions on this system.

the other Developers and Administrator can perform all of the deployer functions from our Dev system TO the QA system but not from QA TO Production.

I don’t have info for your specific question but have a related query.

Why would you deploy from QA to prod? Wouldn’t that entail creating a new Deployer project? And a new “build?” Seems like the build from dev should go to QA, then that same build would go to prod (assuming testing indicates all is okay). This helps test/prove the Deployer project is doing all it is supposed to as well as the code.

That is another alternative but I don’t know how to secure promotion to QA and/or PRD from DEV to a specific user where the Administrator user CANNOT perform the same functions. This is a requirement coming from our GRC/Audit group, where I can demonstrate that only a specific user can promote new/changed code to production and give the GRC/Audit group control of this account so they can prove to the auditors that nothing can (and has) been promoted to production without thier prior approval. The Developer and Admin group use the Administrator account & functions to monitor and trouble shoot webMethods processes. We have ACL list security in place (on each package) that prevents us from directly changing code within the Prod environments directly from Developer/Designer.

Based on the above you have a good work around solution with utilizing AD active/deactivate user and ACL list based security in place…So why is that solution not working as expected or looking for more robust deployment security measures that Audit is asking?

Hi,

You can create a separate ACL for Deployer user and assign that to WmDeployer. Remove Administrator from that group. Also check .access file inside WmDeployer package for manually mentioning ACL(Like * DeployerAdmin). Hope this helps…

My 0.02$
Niteesh

And consider changing the Administrator account password so that only administrators have it. If someone needs access to admin functions they should still use their own ID (with appropriate permissions). The Administrator account should not be used by anyone (even administrators) except when all other accounts lose access (e.g. MWS loses connectivity to LDAP).