Security

In previous releases, TotalAgility used two security keys for encryption of secure data:

• AesKey, which is stored in a configuration file and is used to encrypt Integration site passwords and connection strings.

• Security Key, which is stored in System settings in Designer and is used to encrypt secure global variables and secure server variables.

Now, a single Security Key is used for both areas. This key uses AES encryption and is available in System settings (replacing the existing Security Key) in Designer.

An upgrade from previous TotalAgility version also decrypts and re-encrypts existing data using the single Security Key as required.

When the Security Key is regenerated in Designer System settings, all the data that has already been encrypted is automatically decrypted with the old Security Key value and re-encrypted with the new Security Key value. This includes integration site passwords, connection strings, secure server variables and secure global variables.

A new value is generated for the Security Key with each TotalAgility on-premise installation or a new tenant creation.

When the Security Key is regenerated, all the server variables and integration site configurations are re-encrypted for the new key.

For import and export of server variables or integration sites to a new TotalAgility server, the imported secure data will not work as the security key on the new TotalAgility server is different. In this case, the secure data must be manually updated again after import.

In previous releases, when using Federated Security in TotalAgility, you had to append the SAMLRequest QueryString parameter to the provider endpoint URL using “?” and any existing QueryString parameters in the endpoint URL were ignored.

In TotalAgility 7.10.0, you can append the SAMLRequest QueryString parameter using “?” or “&”, depending upon whether the endpoint URL already has any QueryString parameters.

This change supports Federated Providers that already have QueryString parameters in their endpoint URLs.

Anti CSRF in TotalAgility is enhanced to optionally support a per-request token instead of a per-session token. This helps in preventing replay attacks where the same request is manually edited and sent again.

The following new settings are available in the TotalAgility Core Worker Service config file:

• Enable Replay Protection: Enables per HTTP request validation to prevent replay attacks.

• Request Token Timeout Interval in Minutes: Specifies the interval for clearing orphaned request tokens used for replay protection.

The Cleartext password reset token is now encrypted in the TotalAgility database.