Universal Data Mover Gateway 2.0.0 Release Notes

Web Transfer Client

UDMG Admin UI

From UDMG Admin UI, ad-hoc file transfer information is visible in the Transfers Activity Dashboard and Ad-Hoc Activity service via the navigation pane. 

Transfers Dashboard 

Ad-Hoc Activity 

New endpoints added on the UDMG Server API: 

Note that the creation of the share link is only possible from the UDMG Web Transfer Client.

The following endpoints allow the management of the existing links.

This enhancement allows the deletion of a file after it is downloaded from SFTP using the MOVE command. The enhancement only applies to send or receive files. The change removes the need for additional configuration and monitoring in UAC and UDMG.

Before this change, the local file could only be deleted in the UDMG Server with the DELETE post-task. The remote file could not be deleted in UDMG and UAC was required for the transfers where remote delete was required. 

• New transfer info flag udmg_xfer_move, can have values true and false (bool). If set to true, the customer will delete the file being sent during the removepipeline step.
  • udmg_xfer_move flag is checked for accepted values when the transfer is created.
  • udmg_xfer_move flag is checked for protocol implementation when the pipeline is created. This is only supported for SFTP.
• New pipeline step: remove, between data and post tasks.
• Local file is removed after transfer for send rule (PUT).
• Remote file is removed after transfer for receive rule (GET).

Examples:

udmg-client transfer add -f "README.md" -p "TestSftpPartner" -l "user" -r "Rule1"  -w receive -i udmg_xfer_move:true

udmg-client transfer add -f "README.md" -p "TestSftpPartner" -l "user" -r "Rule1S" -w send -i udmg_xfer_move:true

Implemented Error Messages:

• TeInternal: move not supported for this protocol
• TeInternal: failed to remove local file: %s
• TeDataTransfer: Failed to remove remote SFTP file: %s

Adds a parameter to disable the implicit assignment of Transfer Rules. Before this change, a Transfer Rule was allowed for all servers, partners, and accounts right after creation. It was only restricted after an explicit assignment (whitelisting) to at least one server, partner, or account. The prior functionality created confusion for UDMG users and allowed unauthorized access to files and folders for third-party accounts during the time between the rule creation and its explicit assignment. The change allows the functionality to be disabled with the new UDMG Server configuration parameter ExplicitRuleAssignment. When set to true, a Transfer Rule is only effective when it is explicitly linked with the intended target (local server, remote partner, remote or local account).

The default value remains false but is likely to change with future releases.

[rule]
; Disables global rules, requiring rules to be explicitly allowed to be used.
; ExplicitRuleAssignment = false

Improves security with a default NGINX configuration including the recommended security HTTP headers, hiding the server version, and disabling weak TLS ciphers. The following changes are now the default for the manual installation procedure and the installation with Linux packages (RPM/DEB). For upgrades, the parameter must be manually reviewed and added to the NGINX configuration file.

Note: When installing UDMG 2.0 a new configuration file is generated with "new" added at end.

• B-19918: Hides NGINX Version
  • Changes improve defenses against specific security vulnerabilities by removing the NGINX server banner information (technical and detailed web server version information in HTTP response header) from displaying on every server response.
• B-19919: Improves Clickjacking Prevention

  • To improve malicious Clickjacking attacks, the following enhancements were implemented:

    • Prevents the browser from loading the page in frame using the X-Frame-Options or Content Security Policy (frame-ancestors) HTTP headers.

    • Prevents session cookies from being included when the page is loaded in a frame using the SameSite cookie attribute.

    • Implements JavaScript code in the page to attempt to prevent it from being loaded in a frame (known as a "frame-buster").

• B-19920: Security Headers
  • The following HTTP response headers were added to provide an additional layer of security to Universal Data Mover Gateway.
    • HTTP response headers: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security, Permissions-Policy, X-Permitted-Cross-Domain-Policies, X-Frame-Options. X-XSS-Protection

# DEPRECATED Security Headers
    add_header X-XSS-Protection "0";
    add_header X-Frame-Options "SAMEORIGIN";
    # Security Headers
    add_header Content-Security-Policy "frame-ancestors 'self'";
    add_header X-Content-Type-Options nosniff;
    add_header Referrer-Policy "strict-origin";
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
    add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()";
    add_header X-Permitted-Cross-Domain-Policies none;

• B-19921: Disables Weak TLS Ciphers
  • Changes improve defenses against LUCKY13, a security vulnerability that specifically targets certain implementations of the TLS (Transport Layer Security) and DTLS (Datagram Transport Layer Security) protocols when they use the CBC mode with block ciphers for encryption, by disabling the CBC mode cipher encryption and enabling CTR or GCM cipher mode encryption. 
  • Recommended cipher list from https://ssl-config.mozilla.org
  • Minimum TLS version 1.2

This enhancement allows the user to quickly view the server status, including server state and information in the Local Servers list for all local servers. The "Status" column was added to the list of local server details.  Before this change, the local server status details were only displayed in the “UDMG Server Status” popup.

The color-coded bars show the internal service status:

This enhancement provides a tool to parse an SSH public key. The UDMG Server only accepts the OpenSSH format for public keys, so customers who use the PKCS8 and DER format were not previously able to convert keys to OpenSSH using standard tools (openssl and ssh-keygen). 

The udmg-sshkey tool enables the conversion from another format to the OpenSSH format.

The supported input formats are:

• OpenSSH authorized key line
• PEM encoded formats (PKCS8, PKCS1)
• SSH wire format (Binary ASN1 DER)

The output of the tool shows the key details and the OpenSSH format that is suitable for use during the setup of SFTP servers on UDMG:

• Key format
• Key algorithm
• Key size (only for RSA)
• SHA256 fingerprint
• MD5 fingerprint
• Conversion to authorized key line format

Command line usage:

udmg-sshkey -h
Usage:
  udmg-sshkey [OPTIONS] <parse | version>
Help Options:
  -h, --help  Show this help message
Available commands:
  parse    Parse an SSH Public key file
  version  Print version and exit
   
udmg-sshkey parse -h
Usage:
  udmg-sshkey [OPTIONS] parse [parse-OPTIONS]
Help Options:
  -h, --help      Show this help message
[parse command options]
      -f, --file= The public key file, accepted formats are PKCS8 (x509), OpenSSH (authorized keys), and SSH wire.

See Utilities Reference Guide: udmg-sshkey for additional details.

This enhancement allows the sharing of accounts between servers. It avoids duplicate configurations for FTP and SFTP local servers by allowing accounts to be shared between local servers.

Before this change, a local account was only defined for a given local server and not allowed to have the same account for multiple protocols. For instance, to allow a partner to transfer files over SFTP and FTP, it was required to have both an SFTP and FTP local server, each with their own local account. Each account was then maintained independently, which created additional overhead in configuration and maintenance (password or key updates).

The Local Account service located in the UDMG Admin UI navigation pane is replaced by Shared Accounts service. 

Updated Shared Account process:

1. Click on Shared Accounts from UDMG Admin UI navigation pane.
2. Create a Shared Account by populating the required details and following the current process (tabs are the same).  
   1. Note: A local server does not have to be created yet.
   2. Note: If a local server has been created, then click on the Local Servers tab. 
      1. Click the Pencil (edit) icon. 
      2. Add and/or remove the shared accounts via the pop-up box.

1. Click on Local Servers from UDMG Admin UI navigation pane.
2. Create a local server by populating the required details and following the current process OR select a Local Server record. 
3. Click the Accounts tab.
4. Click the Pencil (edit) icon.
5. Add and/or remove the shared accounts via the pop-up box. 
   
   1. Note: All created shared accounts are available to be add to the local server.

New permission for the management of Shared Accounts:

sharedAccounts on User Permissions

and user group Permissions

New endpoints added on the UDMG Server API: 

• GET /api/sb_local_accounts
• POST /api/sb_local_accounts
• GET /api/sb_local_accounts/:account
• DELETE /api/sb_local_accounts/:account
• PUT /api/sb_local_accounts/:account
• PATCH /api/sb_local_accounts/:account
• PUT /api/sb_local_accounts/:account/enable
• PUT /api/sb_local_accounts/:account/disable
• PUT /api/sb_local_accounts/:account/allow/:server
• PUT /api/sb_local_accounts/:account/disallow/:server
• GET /api/sb_local_accounts/:account/certificates
• PUT /api/sb_local_accounts/:account/certificates/:cert/revoke
• PUT /api/sb_local_accounts/:account/certificates/:cert/revoke
• PUT /api/sb_local_accounts/:account/certificates/:cert/authorize
• PUT /api/sb_local_accounts/account/authorize/:rule/receive
• PUT /api/sb_local_accounts/account/authorize/:rule/send
• PUT /api/sb_local_accounts/account/revoke/:rule/receive
• PUT /api/sb_local_accounts/account/revoke/:rule/send

Updates to the udmg-client CLI: 

Both the new and old command lines can be used to add a new shared account. 

New CLI commands:

udmg-client account share add -l user -p pass -n user

Current CLI commands: 

udmg-client account local $SERVER add -l user -p password

This change incorporates license management within Universal Data Mover Gateway. All environments are required to have an attached license key, including non-production environments.  The Universal Data Mover Gateway is licensed for a set time period, number of UDMG Server instances, and number of transfer executions per month and environment. The counted file transfer executions only include the number of transfer instances completed as DONE over one month. 

To receive and apply your license keys, please follow the below steps and reference UDMG Licensing. 

Dynamic Local Paths Expansion

This enhancement allows users to use the same virtual folder name for multiple user accounts. Multiple user accounts can now use the same local server and the same vpath, but each account will point to a separate ("private") local directory.

Note: The local directory must have read/write permission for the UDMG Server operating system user.

For the protocols: SFTP, FTP/E/S, local-auth

Placeholders are allowed in the transfer rule paths (local directory and temp directory):
#REQUESTERHOST# : local account name, for SFTP, local-auth, and FTP protocols.
#REQUESTEDHOST# : local server name, only for SFTP and local-auth.

They are expanded at runtime (when the transfer is starting or when an FTP/SFTP command is executed).

For instance, /home/Users/Input/#REQUESTERHOST# is expanded to differently for each account:

• /home/Users/Input/sftp_user1 for account "sftp_user1"   
• /home/Users/Input/sftp_user2 for account "sftp_user2".

Example:

udmg-client rule add -n Rule10   -d receive -p /data-host        --local-dir '/data/#REQUESTEDHOST#'

The UDMG Authentication Proxy supports TOML and YAML file formats for the configuration of the SSO service providers.

This is in addition to JSON format that is already supported. The main configuration file remains in TOML format.

Examples of SSO Google provider in the different formats:

{
    "issuer": "https://accounts.google.com",
    "clientID": "xxxxxxx-6le4dqr2cabn80bc9bel444q0cirnkom.apps.googleusercontent.com", "clientSecret": "GOCSPX-lhtwS4mtJ3ryKtDw9_xxxxxxx", "redirectURI": "https://mft-udmg-rhel-qa.stonebranch.org/service/auth/sso/google/callback" } 

issuer = "https://accounts.google.com" 
clientID = "xxxxxxx-6le4dqr2cabn80bc9bel444q0cirnkom.apps.googleusercontent.com" clientSecret = "GOCSPX-lhtwS4mtJ3ryKtDw9_xxxxxxx" redirectURI = "https://mft-udmg-rhel-qa.stonebranch.org/service/auth/sso/google/callback" 

issuer: https://accounts.google.com
clientID: xxxxxxx-6le4dqr2cabn80bc9bel444q0cirnkom.apps.googleusercontent.com clientSecret: GOCSPX-lhtwS4mtJ3ryKtDw9_xxxxxxx redirectURI: https://mft-udmg-rhel-qa.stonebranch.org/service/auth/sso/google/callback