For integration with other systems, we recommend creating a separate user for each system with a User Type of Service Account. In most cases, service accounts have no additional permissions beyond secure file transfer protocol (SFTP) access since the sole purpose of this user account is to retrieve or place files on the SFTP area for data integration.
While having one service account user for all data integrations is possible, creating separate user accounts provides more secure user management by allowing the Security Administrators to disable individual accounts (such as when ending a contract with a third party) without impacting other data integration processes.
In addition, managing separate service accounts enables an institution to limit access to specific SFTP directories and ensure that an external system has access to only the data necessary for its specific integration. Refer to the next section on Path Restriction for additional details.
Configuring an account for SFTP access
To configure a service account for SFTP access:
Go to Database → User Permissions.
Select New User (or select an existing user, and then select Edit User).
Select the Roles tab.
Select SFTP Access.
Authentication is required through either a username/password pair or a username/certificate pair. Certificate-based authentication is considerably more secure than password-based authentication and requires that you generate an SSH2 certificate pair to be used when authenticating.
If you’re using username/certificate authentication, see Generating a certificate key pair.
If you’re using password authentication:
Select Reset Password to generate a new password. A confirmation dialog appears.
Enter
RESET.Select OK.
A new password is auto-generated to replace and invalidate any previously stored password.
Copy and save the password before saving changes because the password will not be visible once saved.
If password authentication has been enabled but is no longer desired, select Clear Password.
Select Save.
Generating a certificate key pair
A Public/Private key pair can be generated using PuTTYgen, an SFTP client (e.g., FileZilla, WinSCP), or the terminal via ssh-keygen on Mac/Linux devices. The key pair needs to be:
An RSA key type
At least 2048 bits or longer
If using PuTTYgen, the latest version should be used.
If you using a Mac or Linux machine, you can use the following command line prompt within the Terminal to generate the RSA key pair:
ssh-keygen -t rsa -b 4096 -m PEM -f ssh_key.pem -N ""This will generate an RSA private key file called ssh_key and a public key file called ssh_key.pub in the current working directory.
If using PuTTYgen, see the notes in the next section (“SSH Private Key”).
SSH Private Key
An SSH Private Key should be used when setting up a Service Account (Remote). If using PuTTYgen, use the Conversions > Export OpenSSH Key to format the newly generated Private Key correctly. You will want to save the OpenSSH Key without a passphrase by ignoring PuTTYgen's warnings.
SSH2 Public Key
For extra security, a Service Account can use an SSH2 Public Key (i.e., certificate-based authentication ), which will typically begin with the comments ---- BEGIN SSH2 PUBLIC KEY ---- and end with ---- END SSH2 PUBLIC KEY ----.
Path restriction
Enabling Path Restriction is recommended since it limits access to specific folders in the SFTP area.
Enter a file path to allow a user access to those folders and any subfolders they contain. To permit access to the incoming and outgoing folders, enter /incoming/vendor_name/ and /outgoing/vendor_name/ on separate lines. If no path restriction is specified, the account can read and write files and folders from all folders.
🔔 ImportantMake sure that the specified folder in the Path Restriction setting exists, or the user or service account will not be able to access the SFTP site. To create the folder, manually connect to the SFTP site externally (using a client that supports the SFTP protocol) or create it by setting it as the Import Path/Mask on a Source Format's Import Automation tab.
Allowed networks (required)
Enter any IP addresses or CIDR subnet ranges here where access should be allowed.
Commas should separate multiple IP addresses or ranges.
Test environments need all desired IP addresses to be allowed on a production database.
Allowed Networks currently accepts only IPv4 addresses.
Make sure to use the public-facing IP address rather than an internal IP address.