Using credentials on job definitions

If you enter the username of a credentials definition in the related section of a job definition, the password field can be resolved at runtime with the password value retrieved from the database.

For example, when defining a job using the Dynamic Workload Console, you can enter the username of a credentials definition and then select User from the Password type widget as shown below:

This picture displays the credentials option field selected. — Figure 1. Credentials definition

There are four available options to define a password. You can find descriptions below and the related examples:

Password

You can define a password by typing it.

For example:

$job

/WS_AGT_0#/JOB_WITH_PASSWORD
  TASK
    {
      "executable" : {
        "interactive" : false,
        "path" : "netstat",
        "credential" : {
          "userName" : "User1",
          "password" : "{aes}/VemdckN397hwTTRFi22ero1lyVg/C5keemnrNafguf5nLE\\=",
          "arguments" : {
            "arguments" : [ {
              "value" : "-an"
            } ]
          }
        }
      }
    }
  RECOVERY STOP

User

Password is resolved at run time using the password value retrieved from the database defined for Username, using either the Credentials definition panel or the

ocli model
              user

command.

You can also code this option in the JSDL section of the job definition in ocli model. You can find more information in the related sections.

To use this option when defining a job, you need the authorization with use access keyword for item type userobj in the security file as follows:

userobj    access=use

Attention: Credentials definitions lack referential integrity, so if a credentials definition that is referenced in the related section of a job definition is changed or deleted, no warning or error messages are return until the job runs.

For example:

$job

/WS_AGT_0#/JOB_WITH_USER_PASSWORD
  TASK
    {
      "executable" : {
        "interactive" : false,
        "path" : "netstat",
        "credential" : {
          "userName" : "User1",
          "password" : "${password:User1}",
          "arguments" : {
            "arguments" : [ {
              "value" : "-an"
            } ]
          }
        }
      }
    }
  RECOVERY STOP

Agent user

Using the param command, password is resolved at run time using the password value defined locally for User Name on the dynamic agent that runs the job.

For example:

$job

/WS_AGT_0#/JOB_WITH_AGENT_USER_PASSWORD
  TASK
    {
      "executable" : {
        "interactive" : false,
        "path" : "netstat",
        "credential" : {
          "userName" : "User1",
          "password" : "${agent:password.User1}",
          "arguments" : {
            "arguments" : [ {
              "value" : "-an"
            } ]
          }
        }
      }
    }
  RECOVERY STOP

Variable

Password is resolved at run time using the value defined for the variable you enter in the field (using the ${variable_name} notation).

The variable must have been defined in one of the following ways:

Locally on the agent, using the param command, for example:

$job

/WS_AGT_0#/JOB_WITH_AGENT_VARIABLE
  TASK
    {
      "executable" : {
        "interactive" : false,
        "path" : "netstat",
        "credential" : {
          "userName" : "User1",
          "password" : "${agent:variableSection.User1}",
          "arguments" : {
            "arguments" : [ {
              "value" : "-an"
            } ]
          }
        }
      }
    }
  RECOVERY STOP

In the HCL Universal Orchestrator database, using a variable table definition. For example:

$job

/WS_AGT_0#/JOB_WITH_VARIABLE
  TASK
    {
      "executable" : {
        "interactive" : false,
        "path" : "echo '${J:$}'",
        "credential" : {
          "userName" : "User1",
          "password" : "${var.PASSWORD_USER1}"
        }
      }
    }
  RECOVERY STOP

You can use the Variable option to specify the password of the remote user of a different workstation by entering the following string in the related field:

${password:workstation_name#value_of_user_name_field}

Note: The remote user of a different workstation must be defined in the database.

When HCL Universal Orchestrator has to resolve username and password at runtime, it follows the sequence below:

If the workstation is not specified (for example, ${password:myuser}):
1. Searches myuser on the workstation running the job applying a case sensitive policy.
2. Searches myuser on the workstation running the job applying a case insensitive policy.
3. Searches myuser without an associated workstation applying a case sensitive policy.
4. Searches myuser without an associated workstation applying a case insensitive policy.
If the workstation is specified (for example, ${password:agent#myuser}):
1. Searches myuser on workstation agent applying a case sensitive policy.
2. Searches myuser on workstation agent applying a case insensitive policy.
3. Searches myuser without an associated workstation applying a case sensitive policy.
4. Searches myuser without an associated workstation applying a case insensitive policy.
If the workstation is specified but is empty (for example, ${password:#myuser}):
1. Searches myuser without an associated workstation applying a case sensitive policy.
2. Searches myuser without an associated workstation applying a case insensitive policy.