Connecting to Snowflake
In addition to providing authentication (see below) set the following properties to connect to a Snowflake database:
- Url: Both AWS and Azure instances are supported. For example:
- AWS: https://myaccount.region.snowflakecomputing.com
- Azure: https://myaccount.region.azure.snowflakecomputing.com
- Warehouse
Account is only required if your Url does not conform to the usual syntax containing the account name at the beginning. Snowflake provides the Account name needed in this case.
Optionally, you can set Database and Schema to restrict the tables and views returned by the provider.
Authenticating to Snowflake
The provider supports Snowflake user authentication, federated authentication, and SSL client authentication. To authenticate, set User and Password, and select the authentication method in the AuthScheme property.
Using Snowflake Password Authentication
Set User and Password to a Snowflake user and set AuthScheme to PASSWORD.
Using Snowflake Key Pair Authentication
The provider allows you to authenticate using key pair authentication by creating a secure token with the private key defined for your user account. To connect with this method, set AuthScheme to PRIVATEKEY and set the following values:
- User: The user account to authenticate as.
- PrivateKey: The private key used for the user such as the path to the .pem file containing the private key.
- PrivateKeyType: The type of key store containing the private key such as PEMKEY_FILE, PFXFILE, etc.
- PrivateKeyPassword: The password for the specified private key.
Using Federated Authentication
To use federated authentication, set the User and Password that you need to authenticate to your SSO identity provider and set the following properties to configure the authentication scheme.
Set AuthScheme based on your IdP (currently, the provider supports Okta only).
- OKTA: Set AuthScheme to OKTA and set SSOIDP to the Okta SAML endpoint.
Using SSL Client Authentication
To authenticate with an SSL client certificate, set SSLClientCert, SSLClientCertPassword, SSLClientCertSubject, SSLClientCertType, and SSLServerCert.
Configuring Access Control
If the authenticating user maps to a system-defined role, specify it in the RoleName property.
Customizing the SSL Configuration
By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.
Connecting Through a Firewall or Proxy
HTTP Proxies
To connect through the Windows system proxy, you do not need to set any additional connection properties. To connect to other proxies, set ProxyAutoDetect to false.
In addition, to authenticate to an HTTP proxy, set ProxyAuthScheme, ProxyUser, and ProxyPassword, in addition to ProxyServer and ProxyPort.
Other Proxies
Set the following properties:
- To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
- To tunnel the connection, set FirewallType to TUNNEL.
- To authenticate, specify FirewallUser and FirewallPassword.
- To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.
Troubleshooting the Connection
To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.
- Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
- Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.
- The certificate presented by the server cannot be validated: This error indicates that the provider cannot validate the server's certificate through the chain of trust. If you are using a self-signed certificate, there is only one certificate in the chain.
To resolve this error, you must verify yourself that the certificate can be trusted and specify to the provider that you trust the certificate. One way you can specify that you trust a certificate is to add the certificate to the trusted system store; another is to set SSLServerCert.