Securing the build, promotion, and deployment of your mainframe application

The purpose of this article is to address two areas for consideration when configuring Rational Team Concert for building your mainframe applications, in order to protect the integrity of your streams, host resources, and build environment. First, it is necessary to properly restrict access to your dependency builds, promotions, and deployments. Second, you must consider the authority under which the build will execute on the host.

Restricting access to Builds, Promotions and Deployments

In order to comply with organizational standards or for compliance reasons, you may want to constrain or otherwise limit who is able to perform builds, promotions, packaging and deployments to certain environments. For example, it may be fine for a developer to promote into the development test environment, but you wouldn't want him to do so into the system integration test environment. 

First, to have visibility at all to the definitions to request these operations, you need to be a member of the Project Area and second have a Developer for IBM Enterprise Platforms license to act upon them.  Therefore, the first order of limiting access to submit a request for such as a build is to not make outsiders members of the project area nor grant them a license that enables the Enterprise Extensions functionality.

Limiting project membership and license assignment is a very coarse grained approach; something more fine grained is needed. Fortunately, Rational Team Concert provides two additional mechanisms: role-based permissions governing the roles that can submit a request, and operation pre-conditions restricting the teams that can do so.

Rational Team Concert provides options to limit the roles that can request a Build, Promotion, Package and Deployment. Since the Rational Team Concert build system underlies all of these capabilities, a user must have the Request Build permission to request a dependency build, perform a promotion, create a package or request a deployment. One caveat to this is a source-only promotion, which doesn't require a build to take place.

The next level of permissions governs the specific operations.

To request a Dependency Build, one need only have the Request Build permission from the previous figure. Permissions can be placed on the dependency build to limit whether a user can set the ignore changes flag on a file or request a full build regardless of the changes detected.

There are two types of promotion requests: Promote Components and Promote Work Items.  To Promote Components, only the Request Build permission is needed. To Promote Work Items, the Promote Work Items permission is additionally needed. 

To Create a Package by Work Item or Ship List, the Request Package permission is needed.

To request a Deployment, the Request Deployment permission is needed.

An additional layer of restrictions that may be placed on Builds, Promotions and Deployments is to limit requests to users who are members of the team that owns the build, promotion, package or deployment definition. Since these are all based on Rational Team Concert build definitions, this restriction is put in place by adding a Restrict the Users Requesting A Build precondition to the Request Build operations. This precondition requires that the requester be a member of the team that owns the build definition being used. 

Let's go through an example. The JKE Banking project has two development feature teams, Business Recovery Matters and Energy Efficiency Matters. The project also has a Release Engineering team focused on build, promotion and deployment into the various test and production environments.

JKE Banking
      Team Organization

The project has the following stream structure in place that mirrors the development, test and production environments.

      stream structure

Correspondingly, dependency builds are defined for each environment. Those supporting the development environment are owned by the Business Recovery Matters development team. Those representing the project's test and production environments are owned by the Release Engineering team.

Dependency Build Definition ownership

Promotion, packaging and deployment through the Test, QA and Production environments will be owned by the Release Engineering team. Thus, all the definitions for these operations will be owned by that team.

Promotion, Packaging and Deployment Ownership

Finally, the previously described Restrict the Users Requesting A Build precondition is placed on the Request Build operation so that the build through deployment lifecycle operations can only be performed by members of the appropriate team.

Based on this team structure, build ownership and preconditions, the following scenario is performed.

  1. Deb, a developer, makes a change to the source code and delivers that change to the Mortgage Development Stream.

  2. Deb requests the dependency build.  Since she is a member of the Business Recovery Matters team that owns that build, the build proceeds. Had Deb not been a member of the team, the following error would have occurred.

    Request Build
          failed: Not authorized to request a build

  3. The release engineer, Rebecca, promotes Deb's change to the Test environment by requesting a work item promotion of Since Rebecca is a member of the Release Engineering team that owns the promotion, and also has the Promote Work Items permission, the promotion proceeds. Had Rebecca not been a member of the team, she would have received the same error in the Team Advisor as Deb received in the step above. Without Promote Work Items permission, the following errors would have occurred.

  4. Rebecca packages the changes that have been promoted by requesting the package. She is able to perform this action because she is a member of the Release Engineering team that owns the package, and because she has Request Package permissions. Otherwise, she would see errors similar to those we have seen above.

  5. Upon completion of the package, Rebecca deploys it by requesting the deployment. Again, she is successful because she is a member of the Release Engineering team that owns the deployment, and she has Request Deployment permissions.
Note this is just a notional example of how a project could structure the ownership of the various environments and the supporting build, promotion, packaging and deployment definitions. Often times an even more fine-grained access is necessary, and a team area is created at each level in the hierarchy (Development, Test, Quality Assurance, Production) with the appropriate definitions assigned. The relevant point is that Rational Team Concert provides the ability for teams to manage the ownership of the definitions and restrict who can perform them to members of the appropriate team. In addition, Work Item Promotion, Packaging, and Deployment requests all require specific additional permissions as described above.

Rational Build Agent security on z/OS

In order to leverage dependency build or JCL build capabilities provided by Rational Team Concert, you will need to install and configure a Rational Build Agent on the z/OS system where the builds will be performed. It is important to consider the authority under which these builds will run on z/OS, both for team builds and for personal builds requested by individual developers. You have several options for securing your builds, as defined in the Information Center under Security considerations for the Rational Build Agent. This article will explore in detail the most common approach.  

There are two to three TSO user IDs involved with Rational Build Agent builds. They are:
  1. The TSO user that launches the Rational Build Agent on z/OS
  2. The TSO user that is configured in the Build Engine in Rational Team Concert
  3. Potentially a different TSO user specified at build request time using Build Agent Authentication Override
Most often, user #1 is a superuser (UID 0). By starting the Rational Build Agent with superuser, the build will run under the authority of user #2, unless a Build Agent Authentication Override is performed to run the build as user #3.

For example, here the superuser RYEHLE starts the build agent:

Superuser starting Build Forge Agent

The Build Engine is configured with non-superuser BUILDER (though a superuser could be used):

Build Engine configured with TSO user

A command line build that simply runs the whoami Unix command for validation of the configuration will print BUILDER to the build log, indicating that the build is running under the authority of the BUILDER ID.

The same command line build could be requested using Build Agent Authentication Override:

Build Agent Authentication Override

In this case, whoami will print USER11 to the build log.

Keep in mind that the user ID the build runs under must have authority to:
  • Write to the build agent temporary directory (/tmp by default)
  • In the case of a command line build:
    • Set the working directory to the location specified
    • Execute the specified command
  • In the case of a dependency build:
    • Write to the data set high level qualifier (HLQ) specified in the build definition
    • Write to the load directory (USS) specified in the build definition
    • Write to the USS folder SCM_WORK/SCM configured in
When developers request personal builds to verify changes in their repository workspace before delivering to the stream, they specify a load directory and resource prefix (HLQ). If your developers will not be performing Build Agent Authentication Overrides, the TSO user specified in the Build Engine will need permission to write to these locations. One way to achieve this is to have one common root USS directory and HLQ, and assign each user a unique subdirectory and segment to use for personal builds. For example, Joe uses /u/builder/joe and BUILDER.JOE for his directory root and HLQ, and Bob uses /u/builder/bob and BUILDER.BOB. Built programs could then be packaged and deployed to a shared test environment as necessary.

Personal build request

You may want to force each of your developers to perform a Build Agent Authentication Override, so that their personal builds are always running under the authority of their own individual TSO user IDs. This can be done by specifying a dummy ID in the Build Engine, causing the build request to fail if no override is specified. One drawback to this approach is that scheduled builds are not possible because they would always fail. An alternative approach is to configure the Build Engine with a TSO user that can write to the load directory and HLQ specified in the build definition but can not write to the individual developers' load directories and HLQs. Personal builds would fail unless they were requested using Build Agent Authentication Override. If you decide to take this approach, you will want to consider coding a precondition that confirms the user has specified a load directory and HLQ different from what is specified in the build definition for all personal build requests (or that he has used Build Agent Authentication Override), as today there is nothing preventing the user from reusing these values. This could in particular cause issues for other developers who are relying on the team build data sets to be in sync with the contents of the stream.

Additional configuration is required to perform overrides when using a command line build to submit JCL, as discussed in the Information Center in the Prerequisites and security considerations topic.

For more information

About the authors

Robin Yehle Bobbitt was the build and promotion component lead for the Rational Team Concert Enterprise Extensions development team. She is currently the development lead for the Rational Adapter for Git. Robin can be contacted at

Tim Feeney is a CLM solution architect and member of the Unleash the Labs (ULL) team. The ULL teams work with key customers worldwide to architect lifecycle solutions across the breadth of the Rational portfolio and industry solution domains.  He can be contacted at

Was this information helpful? Yes No 1 person rated this as helpful.