RapidIdentity Product Guide: New UI

Globals.properties Files

RapidIdentity Connect installs and uses two .properties files to provide a way to centrally manage global variables to be used by Action Sets within individual projects (Globals.properties) as well as across all projects (SharedGlobals.properties).


The SharedGlobals.properties file appears only in the <Main> project, but can be accessed by Action Sets from any project in RapidIdentity Connect. Each project will contain its own Globals.properties file that can be edited individually for that project.

  1. To edit either of the .properties files, navigate to the associated project and click on the file. Then choose Edit from the Action Bar at the bottom.

  2. Enter the variable(s) you wish to define in the following syntax: variableName=Value.


    The values of the property will usually be interpreted as a string, unless it is wrapped in json(...). This will cause the value to be parsed as JSON, making it also possible to define variables that are objects, arrays, numbers, booleans, or null.

    Unlike using an Action Set for global variables, you cannot refer to variables in the values of other variables within a .properties file.



    There is a native encrypt functionality for sensitive information used in these files. Also consider the difference between defining variables in one project versus defining variables for all projects when entering these fields.

  3. Once the changes have been saved, the variable can be referenced by an Action Set.


    The variables must be referenced with the prefix Global.

Using Global Properties v. Shared Global Properties

The two .properties files used by RapidIdentity Connect, Globals.properties and SharedGlobals.properties, serve the same purpose but at two separate levels. Historically, in order to define all the variables for a Project, a new Action Set would have to call a previously created Action Set called Globals and define variables individually. These new .properties files allow Connect Administrators to define variables that can apply by default to all projects across the cluster through SharedGlobals.properties, or only variables that apply to one project with Globals.properties.

Globals Priority

Consider that there are three levels of variable definition by practice, and they are prioritized in this order:

  1. Defined by an Action Set named Globals

  2. Defined by Globals.properties

  3. Defined by SharedGlobals.properties

This means that if a variable with the same name is defined in more than one of these levels, the level that is "closest" to the Action Set calling the variable will be the active definition.

Globals Priority Example

To illustrate this concept, we have created the variable message in three different locations with three separate values.

  • A Globals Action Set that sets the variable message as "This is a message from the Globals Action Set"

  • A Globals.properties variable statement that defines message as "This is a message from Globals.properties"

  • A SharedGlobals.properties variable statement that defines message as "This is a message from SharedGlobals.properties"

  1. In the Action Set GlobalsTest, first we run the Globals Action Set, then log Global.message.

  2. Because the Globals Action Set contains a command to define the variable message, that is the Global.message that was picked up for this Action Set's output.

  3. However, if we delete the Globals Action Set from GlobalsTest, we now still have variables with the same name and different values in Globals.properties and SharedGlobals.properties.

  4. When this Action Set is run, the Globals.properties value takes precedence.

  5. To verify the SharedGlobals.properties still apply, we disabled the message variable in Globals.properties and ran the Action Set once more. Note that the message from SharedGlobals.properties now displays.

Interacting with Files

Any files, including Globals.properties .txt files, can be imported into a project's Files menu by using the Import function. To replace a Globals.properties or SharedGlobals.properties file with a .txt file, simply upload a file with that name.


Any SharedGlobals.properties file uploaded as a Project file instead of a file in <Main> will be ignored by RapidIdentity.


Each Project, when created, comes populated with its own Globals.properties file, and the <Main> project comes populated with its own set of both by default at installed. These can be altered or overwritten, but must remain in place for core functionality.

Encryption in .properties Files

Variables such as passwords can be coded and encrypted within one of the Globals.properties files, and accessible by any Action Set within that project. For sensitive values that should be encrypted, you may set the value to encrypt(unencrypted-value). The value will automatically be encrypted upon saving, and the value will then be stored as decrypt(encrypted-value). When accessed as a property of Globals from an Action Set, the property will be automatically decrypted and the original unencrypted value will be available for use.

  1. These AD credentials have been entered in a section of Globals.properties for a RapidIdentity project. Note that the adPwd variable is set to encrypt(value).

  2. After the files have been saved, re-opening the Globals.properties file will show encrypted code as decrypt(new value) instead of the unencrypted password value.



    Encrypted Global Variables can only be decrypted from within the same RapidIdentity cluster in which they were originally encrypted. If this file is migrated to an Action Set on another cluster, it will not function properly.