Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
To connect to a Gen 2 DataLakeStorage account, you should first set the following properties:
Schema: Set this to ADLSGen2.
Account: Set this to the name of the storage account.
FileSystem: Set this to the file system name which will be used for this account. For example, the name of an Azure Blob Container
Directory: (Optional) Set this to the path which will be used to store the replicated file. If not specified, the root directory will be used.
Gen 2 supports the following authentication methods: using an AccessKey, using a Shared Access Signature, Azure Active Directory OAuth (AzureAD), Managed Service Identity (AzureMSI).
To connect using a Shared Access Signature set the AccessKey property and the AuthScheme to AccessKey.
You can obtain an access key for the ADLS Gen2 storage account using the Azure portal:
Go to your ADLS Gen2 Storage Account in the Azure portal.
Under Settings, select Access keys.
Copy the value for one of the available access keys to the AccessKey connection property.
To connect using a Shared Access Signature set the SharedAccessSignature property to a valid signature of a resource to connect to and the AuthScheme to SAS. The SharedAccessSignature may be generated with a tool such as Azure Storage Explorer.
Azure AD is a connection type that leverages OAuth to authenticate. Set your AuthScheme to AzureAD. The rest of the AzureAD flows assume that you have done so.
Custom AzureAD App
See Creating a Custom AzureAD App for information about creating custom applications and reasons for doing so.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
Admin Consent Permissions
When creating a new OAuth app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked stating "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, there will be a button for Grant Consent. You can consent here for your app to have permissions on the tenant it was created under.
Once an admin grants consent, authentication may be performed as normal.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
Client OAuth Flow
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the applicable permissions you require for your integration.
You are ready to connect after setting one of the below connection properties groups depending on the authentication type.
Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can cuse InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connet to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the Client Id in your app settings.
OAuthClientSecret: Set this to the Client Secret in your app settings.
Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the Client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials will take place automatically like any other connection, except there will be no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Azure Data Lake Storage on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
All connections to Google BigQuery are authenticated using OAuth. The provider supports using user accounts, service accounts and GCP instance accounts for authentication.
AuthScheme must be set to OAuth in all of the user account flows
Set InitiateOAuth to GETANDREFRESH.
When testing the connection, it will open a browser and Google BigQuery will request your login information. The provider will use the credentials you provide to access your Google BigQuery data. These credentials will be saved and automatically refreshed as needed.
To authenticate using a service account, you must create a new service account and have a copy of the accounts certificate.
For a JSON file, you will need to set these properties:
AuthScheme: Required. Set this to OAuthJWT.
InitiateOAuth: Required. Set this to GETANDREFRESH.
OAuthJWTCertType: Required. Set this to GOOGLEJSON.
OAuthJWTCert: Required. Set this to the path to the .json file provided by Google.
OAuthJWTSubject: Optional. Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.
For a PFX file, you will need to set these properties instead:
AuthScheme: Required. Set this to OAuthJWT.
InitiateOAuth: Required. Set this to GETANDREFRESH.
OAuthJWTCertType: Required. Set this to PFXFILE.
OAuthJWTCert: Required. Set this to the path to the .pfx file provided by Google.
OAuthJWTCertPassword: Optional. Set this to the .pfx file password. In most cases this will need to be provided since Google encrypts PFX certificates.
OAuthJWTCertSubject: Optional. Set this only if you are using a OAuthJWTCertType which stores multiple certificates. Should not be set for PFX certificates generated by Google.
OAuthJWTIssuer: Required. Set this to the email address of the service account. This address will usually include the domain iam.gserviceaccount.com.
OAuthJWTSubject: Optional. Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.
If you do not already have a service account, you can create one by following the procedure in Creating a Custom OAuth App.
When running on a GCP virtual machine, the provider can authenticate using a service account tied to the virtual machine. To use this mode, set AuthScheme to GCPInstanceAccount.
To connect to a Gen 1 DataLakeStorage account, you should first set the following properties:
Schema: Set this to ADLSGen1.
Account: Set this to the name of the account.
AzureTenant: Set this to the tenant Id. See the property for more information on how to acquire this.
Directory: (Optional) Set this to the path which will be used to store the replicated file. If not specified, the root directory will be used.
Gen 1 supports the following authentication methods: Azure Active Directory OAuth (AzureAD) and Managed Service Identity (AzureMSI).
Azure AD is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with Azure Data Lake Storage using an internet browser. The provider facilitates this in several ways as described below. Set your AuthScheme to AzureAD. The rest of the AzureAD flows assume that you have done so.
Custom Azure oAuth App
See Creating a Custom AzureAD App for information about creating custom applications and reasons for doing so.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Admin Consent
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
Admin Consent Permissions
When creating a new OAuth app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked stating "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, there will be a button for Grant Consent. You can consent here for your app to have permissions on the tenant it was created under.
Once an admin grants consent, authentication may be performed as normal.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
All permissions related to the client oauth flow require admin consent.
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the applicable permissions you require for your integration.
You are ready to connect after setting one of the below connection properties groups depending on the authentication type.
Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can cuse InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connet to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the Client Id in your app settings.
OAuthClientSecret: Set this to the Client Secret in your app settings.
Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the Client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials will take place automatically like any other connection, except there will be no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Azure Data Lake Storage on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
To authenticate, set the following:
AuthScheme: Set this to PersonalAccessToken.
Token: The token used to access the Databricks server. It can be obtained by navigating to the User Settings page of your Databricks instance and selecting the Access Tokens tab.
To authenticate to Databricks using Azure Service Principal:
AuthScheme: Set this to AzureServicePrincipal.
AzureTenantId: Set this to the tenant ID of your Microsoft Azure Active Directory.
AzureClientId: Set to the application (client) ID of your Microsoft Azure Active Directory application.
AzureClientSecret: Set to the application (client) secret of your Microsoft Azure Active Directory application.
AzureSubscriptionId: Set this to the Subscription id of your Microsoft Azure Databricks Service Workspace.
AzureResourceGroup: Set this to the Resource Group name of your Microsoft Azure Databricks Service Workspace.
AzureWorkspace: Set this to the name of your Microsoft Azure Databricks Service Workspace.
To connect to a Databricks cluster, set the properties as described below.
Note: The needed values can be found in your Databricks instance by navigating to Clusters, and selecting the desired cluster, and selecting the JDBC/ODBC tab under Advanced Options.
Database: Set to the name of the Databricks database.
Server: Set to the Server Hostname of your Databricks cluster.
HTTPPath: Set to the HTTP Path of your Databricks cluster.
Token: Set to your personal access token (this value can be obtained by navigating to the User Settings page of your Databricks instance and selecting the Access Tokens tab).
The provider supports DBFS, Azure Blob Storage, and AWS S3 for uploading CSV files.
To use DBFS for cloud storage, set the following:
CloudStorageType: Set this to DBFS.
StoreTableInCloud: Set this to True to store tables in cloud storage when creating a new table.
Set the following to use Azure Blob Storage for cloud storage:
CloudStorageType: Set this to Azure Blob storage.
StoreTableInCloud: Set this to True to store tables in cloud storage when creating a new table.
AzureStorageAccount: Set this to the name of your Azure storage account.
AzureAccessKey: Set to the storage key associated with your Databricks account. Find this via the azure portal (using the root acoount). Select your storage account and click Access Keys to find this value.
AzureBlobContainer: Set to the name of you Azure Blob storage container.
Set the following to use AWS S3 for cloud storage:
CloudStorageType: Set this to AWS S3.
StoreTableInCloud: Set this to True to store tables in cloud storage when creating a new table.
AWSAccessKey: The AWS account access key. This value is accessible from your AWS security credentials page.
AWSSecretKey: Your AWS account secret key. This value is accessible from your AWS security credentials page.
AWSS3Bucket: Set to the name of your AWS S3 bucket.
AWSRegion: The hosting region for your Amazon Web Services. The AWS Region value can be obtained by navigating to the Buckets List page of your Amazon S3 service, such as: us-east-1.
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
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 connector.
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.
Set User and Password to a Snowflake user and set AuthScheme to PASSWORD.
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.
Set the AuthScheme to Okta. The following connection properties are used to connect to Okta:
User: Set this to the Okta user.
Password: Set this to Okta password for the user.
MFAPasscode (optional): Set this to the OTP code that was sent to your device. This property should be used only when the MFA is required for OKTA sign on.
The following SSOProperties are needed to authenticate to Okta:
Domain: Set this to the OKTA org domain name.
MFAType (optional): Set this to the multi-factor type. This property should be used only when the MFA is required for OKTA sign on. This property accepts one of the following values:
OKTAVerify
SMS
APIToken (optional): Set this to the API Token that the customer created from the Okta org. It should be used when authenticating a user via a trusted application or proxy that overrides OKTA client request context.
The following is an example connection string:
The following is an example connection string for OKTA MFA:
Set the AuthScheme to AzureAD. The following connection properties are used to connect to AzureAD:
User: Set this to your AD user. When connecting, your browser will open allowing you to login to Azure AD to complete the authentication.
The following is an example connection string for AzureAD:
Set the AuthScheme to PingFederate. The following connection properties are used to connect to PingFederate:
User: Set this to your PingFederate user, the user should been added to PingFederate Data Stores. When connecting, your browser will open allowing you to login to PingFederate to complete the authentication.
The following is an example connection string for PingFederate(Assuming that Active Directory is used as a Data Store):
To authenticate with OAuth, set the AuthScheme to OAuth. You can authenticate by Creating a Custom OAuth App to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
After setting the following, you are ready to connect:
OAuthClientId: Set to the Client ID in your OAuth Integration settings.
OAuthClientSecret: Set to the Client Secret in OAuth your Integration settings.
CallbackURL: Set to the Redirect URL in your OAuth Integration settings.
InitiateOAuth: Set to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
When you connect, the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the following OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation to be persisted across connections.
If the authenticating user maps to a system-defined role, specify it in the RoleName property.
In addition to providing authentication (see below), set the following properties to connect to a Azure Synapse database:
Server: The server running Azure. You can find this by logging into the Azure portal and navigating to Azure Synapse Analytics -> Select your database -> Overview -> Server name.
Database: The name of the database, as seen in the Azure portal on the Azure Synapse Analytics page.
Connect to Azure Synapse using the following properties:
User: The username provided for authentication with Azure.
Password: The password associated with the authenticating user.
Azure AD is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with Azure Synapse using an internet browser. The provider facilitates this in several ways as described below. Set your AuthScheme to AzureAD. All AzureAD flows assume that you have done so.
You can use a custom AzureAD application to authenticate a service account or a user account. You can always create a custom AzureAD application, but note that desktop and headless connections support embedded OAuth, which simplifies the process of authentication.
Create a Custom AzureAD App
Follow the steps below to obtain the AzureAD values for your application, the OAuthClientId and OAuthClientSecret.
In the left-hand navigation pane, select Azure Active Directory, then applicationRegistrations, and click New registration.
Enter an application name and select the desired tenant setup. When creating a custom AzureAD application in Azure Active Directory, you can define whether the application is single- or multi-tenant. If you select the default option, "Accounts in this organizational directory only", you must set the AzureTenant connection property to the Id of the Azure AD Tenant when establishing a connection with the CData ADO.NET Provider for Azure Synapse. Otherwise, the authentication attempt fails with an error. If your application is for private use only, "Accounts in this organization directory only" should be sufficient. Otherwise, if you want to distribute your application, choose one of the multi-tenant options.
Set the redirect url to http://localhost:33333, the provider's default. Or, specify a different port and set CallbackURL to the exact reply URL you defined.
Click Register to register the new application. This opens an application management screen. Note the value in Application (client) ID as the OAuthClientId and the Directory (tenant) ID as the AzureTenant.
Navigate to the "Certificates & Secrets" and define the application authentication type. There are two types of authentication available: using a client secret or a certificate. The recommended authentication method is using a certificate.
Option 1: Upload a certificate: In "Certificates & Secrets", select Upload certificate and the certificate to upload from your local machine.
Option 2: Create a new application secret: In "Certificates & Secrets", select New Client Secret for the application and specify its duration. After saving the client secret, the key value is displayed. Copy this value as it is displayed only once. You will need it as the OAuthClientSecret.
Select API Permissions > Add. If you plan for your application to connect without a user context, select Application Permissions (OAuthGrantType = CLIENT). Otherwise, use the Delegated permissions.
Save your changes.
If you have selected to use permissions that require admin consent (such as the Application Permissions), you can grant them from the current tenant on the API Permissions page.
Set the AuthScheme to AzureAD. This is required to create users for the OAuth app.
Add the user to the database by running: CREATE USER [OAuth_APP] FROM EXTERNAL PROVIDER. This command must be run by the SQL Active Directory admin asssigned to the Azure Synapse instance.
Enable the Directory readers role for the Active Directory admin user.
When authenticating using an Azure Service Principal, you must create both a custom AzureAD application and a service principal that can access the necessary resources. Follow the steps below to create a custom AzureAD application and obtain the connection properties for Azure Service Principal authentication.
Create a Custom AzureAD App with an Azure Service Principal
Follow the steps below to obtain the AzureAD values for your application.
In the left-hand navigation pane, select Azure Active Directory then App Registrations and click New registration.
Enter an app name and select Any Azure AD Directory - Multi Tenant. Then set the redirect url to http://localhost:33333, the provider's default.
After creating the application, copy the Application (client) Id value displayed in the "Overview" section. This value is used as the OAuthClientId
Define the app authentication type by going to the "Certificates & Secrets" section. There are two types of authentication available: using a client secret and using a certificate. The recommended authentication method is via a certificate.
Option 1 - Upload a certificate: In "Certificates & Secrets", select Upload certificate and the certificate to upload from your local machine.
Option 2 - Create a new application secret: In "Certificates & Secrets", select New Client Secret for the application and specify its duration. After saving the client secret, the key value is displayed. Copy this value as it is displayed only once. You will use it as the OAuthClientSecret.
On the Authentication tab, make sure to select Access tokens (used for implicit flows).
For authentication, the only difference between the two methods is that you must set two additional connection properties when using custom OAuth applications.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
Client OAuth Flow
All permissions related to the client oauth flow require admin consent.
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the permissions you require for your integration.
You are ready to connect after setting one of the connection properties groups depending on the authentication type.
Authenticating using a Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials takes place automatically like any other connection, except there is no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
Note: You must create a custom application prior to assigning a role.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Azure Synapse on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
The following connection properties are usually required in order to connect to Amazon Redshift.
Server: The host name or IP of the server hosting the Amazon Redshift database.
Database: The database that you created for your Amazon Redshift cluster.
You can also optionally set the following:
Port: The port of the server hosting the Amazon Redshift database. 5439 by default.
You can obtain these values in the AWS Management Console:
Open the Amazon Redshift console (http://console.aws.amazon.com/redshift).
On the Clusters page, click the name of the cluster.
On the Configuration tab, obtain the properties from the Cluster Database Properties section. The connection property values will be the same as the values set in the ODBC URL.
The provider provides secure communication with Amazon Redshift server using SSL encryption. You can optionally turn off SSL encryption by setting UseSSL to false.
You can also leverage SSL authentication to connect to Amazon Redshift data. For that configure the following connection properties:
SSLClientCert: Set this to the name of the certificate store for the client certificate. Used in the case of 2-way SSL, where truststore and keystore are kept on both the client and server machines.
SSLClientCertPassword: If a client certificate store is password-protected, set this value to the store's password.
SSLClientCertSubject: The subject of the TLS/SSL client certificate. Used to locate the certificate in the store.
SSLClientCertType: The certificate type of the client store.
SSLServerCert: The certificate to be accepted from the server.
The following is the example connection string to connect Amazon Redshift using standard user/password and inactive SSL encryption:
Note: If you already have an active Azure AD user account, skip to Connecting with Azure AD.
In the Azure Active Directory tenant, click:
Users
New user
Create new user
Fill out your details and click Create.
Log in and choose the Consent on behalf of your organization option, then the Need admin approval window appears.
Click Accept.
Note: Only non-B2C Azure tenants will be able to complete the Azure AD authentication scheme.
Note: You must have an active Azure AD account. If you do not have an active account, make one before beginning this process.
First, create an OAuth app for logging into your Amazon Redshift database via Azure. On the Azure Active Directory Overview page, in the left navigation bar:
Click App registrations.
Click New registrations at the top of the App registrations page.
On the Register an application page, fill in your details and click Register at the bottom of the page. Make note of your CallbackURL.
From the newly registered application, click Expose an API in the left navigation bar.
Next to the Application ID URI, click Set.
The Set the App ID URI dialog appears with the information filled in from registering. Click Save.
Click Add a scope.
Fill in your details and click Add scope at the bottom of the form.
Next, create another OAuth app, which will serve as the client application for your Amazon Redshift database. In the left navigation bar, click App registrations.
From the Azure Active Directory management page, click New registrations at the top of the App registrations page.
On the Register an application page, fill in your details and click Register at the bottom of the page.
Following the creation of the app, you will be brought to its overview page. From there, in the left navigation bar:
Click on Certificates & secrets.
Click on New client secret.
In the Add a client secret window, add in your details and click Add at the bottom of the window.
Make a note of your OAuthClientSecret (the Value field of the OAuth secret that is displayed).
In the left navigation bar of the client app's management page:
Click API permissions.
Click Add a permission.
Choose Microsoft Graph API.
Click Application permissions.
Set Client app permissions to Directory.Read.All.
Click Add at the bottom.
Click Grant admin consent.
Click Yes.
In the Azure Active Directory left navigation bar:
Click Groups.
On the Groups page, click New group and fill in the details.
Click No owners selected.
The Add owners window appears. Select the user.
Click Create.
In the Azure Active Directory left navigation bar:
Click App registrations.
Click the tab All applications, and choose your first OAuth application.
On the OAuth screen, in the left navigation bar, click Manifest. Look in the editor for the accessTokenAcceptedVersion. If the value is null, it is a v1.0 token. If the value is set to 2, this is a v2.0 token.
From the Amazon Redshift instance's query box, submit the identity provider query, following the example below:
Terminology Guide:
Your issuer ID: The issuer ID to trust when a token is received. The unique identifier for the tenant_id is appended to the issuer. If using a v1.0 token, use https://sts.windows.net/<your_tenant_id_here>/. If using a v2.0 token, use https://login.microsoftonline.com/<your_tenant_id_here>/v2.0.
Your client_id: The unique, public identifier of the application registered with the identity provider. This is referred to as the application ID.
Your client_secret: A secret identifier, or password, known only to the identity provider and the registered application.
audience: The Application ID (URI) assigned to the OAuth app.
You can use any name you like for the NAMESPACe.
In Amazon Redshift, place the CREATE IDENTITY PROVIDER query (like above example) into the query text box.
Click Run at the bottom of the query box.
In the query text box, create a role on the Redshift database in this format:
Replace with your identity provider's namespace provided in the CREATE IDENTITY PROVIDER query and the name of Azure group you created earlier. Click the Run button at the bottom of the query box.
In the query text box, grant table access to this new role as follows:
Replace the above example with your namespace and Azure group name.
Click Run at the bottom of the query box.
AuthScheme: Set this to AzureAD.
Server: Set this to the name of your Amazon Redshift server endpoint.
Database: Set this to the name of your Amazon Redshift database that you'd like to connect to.
User: Set this to the name of the authenticating Amazon Redshift user.
AzureTenant: Set this to the ID of the Azure Tenant that your OAuth and client apps were created under. Find this in the Overview page of one of the apps under Directory (tenant) ID.
SSOLoginURL: Set this to the value of the Application ID URI, visible on the Overview page of your OAuth app.
Scope: For v1.0 OAuth tokens, set this to the Scopes field in the Expose an API page of your OAuth app. For v2.0 OAuth tokens, this will be the same as the OAuth app's Client ID.
OAuthClientID: Set this to the Application (client) ID in the Overview page of the Amazon Redshift client app you created.
OAuthClientSecret: Set this to the Value of the OAuth client secret noted upon its creation in your client app's Certificates & secrets page.
CallbackURL: Set this to the callback URL of the OAuth app.
Troubleshooting Note: If an "Azure JWT token does not have 'upn' field" error is encountered:
On the Azure Active Directory management page, navigate to App Registrations and select your OAuth app.
Click Token configuration in the left navigation bar.
Click Add optional claim.
In the Add optional claim screen, under Token type, click Access.
Under the Claim column, select upn.
Click Add at the bottom.
Select Turn on the Microsoft Graph profile permission (required for claims to appear in token).
Click Add.
Repeat this process for the client app.
Attempt the connection again.
Set the AuthScheme to Basic in order to connect to Amazon Redshift with login credentials. In addition, set the following connection properties:
User: The user which will be used to authenticate with the Amazon Redshift server.
Password: The password which will be used to authenticate with the Amazon Redshift server.
The following is an example connection string:
Set the AuthScheme to IAMCredentials. The following is an example connection string:
If you are connecting IAM role with temporary credentials you are also required to apply AWSSessionToken.
You can optionally apply:
AutoCreate: Create a database user with the name specified for User if one does not exist while connecting.
DbGroups: Database groups the database user joins for the current session.
Set the AuthScheme to ADFS. The following connection properties need to be set:
User: Set this to the ADFS user.
Password: Set this to ADFS password for the user.
SSOLoginURL: Set this to the login url used by the SSO provider.
Below is an example connection string:
The ADFS Integrated flow indicates you are connecting with the currently logged in Windows user credentials. To use the ADFS Integrated flow, simply do not specify the User and Password, but otherwise follow the same steps in the ADFS guide above.
Set the AuthScheme to PingFederate. The following connection properties need to be set:
User: Set this to the PingFederate user.
Password: Set this to PingFederate password for the user.
SSOLoginURL: Set this to the login url used by the SSO provider.
The following SSOProperties are needed to authenticate to PingFederate:
AuthScheme (optional): The authorization scheme to be used for the IdP endpoint. The allowed values for this IdP are None or Basic.
Additionally, you can use the following SSOProperties to configure mutual SSL authentication for SSOLoginURL, the WS-Trust STS endpoint:
SSLClientCert
SSLClientCertType
SSLClientCertSubject
SSLClientCertPassword
Below is an example connection string:
Log in to .
Log in to .
|
|
|
|
|
|
|
|
|
|
|
|