Linux DSN Configuration
This section describes how to set up ODBC connectivity and configure DSNs on several Linux distributions: Debian-based systems, like Ubuntu, and Red Hat Linux platforms, like Red Hat Enterprise Linux (RHEL) and Fedora.
Minimum Linux Versions
Here are the minimum supported versions for Red Hat-based and Debian-based systems:
OS | Min. Version |
Ubuntu | 18.04 |
Debian | 10 |
RHEL | 8 |
Fedora | 28 |
SUSE | 15 |
Installing the Driver Dependencies
Run the following commands as root or with sudo to install the necessary dependencies:
- Debian/Ubuntu:
apt-get install libc6 libstdc++6 zlib1g libgcc1
- RHEL/Fedora:
yum install glibc libstdc++ zlib libgcc
Installing the Driver
You can use standard package management systems to install the driver.
On Debian-based systems, like Ubuntu, run the following command with root or sudo:
dpkg -i /path/to/driver/setup/FHIRODBCDriverforUnix.deb
On systems that support the RPM package format, run the following command with root or sudo:
rpm -ivh /path/to/driver/FHIRODBCDriverforUnix.rpm
Licensing the Driver
Run the following commands to license the driver. To activate a trial, omit the <key> input.
cd /opt/cdata/cdata-odbc-driver-for-fhir/bin/
sudo ./install-license.sh <key>
Connecting through the Driver Manager
The driver manager loads the driver and passes function calls from the application to the driver. You need to register the driver with the driver manager and you define DSNs in the driver manager's configuration files.
The driver installation registers the driver with the unixODBC driver manager and creates a system DSN. The unixODBC driver manager can be used from Python and from many other applications. Your application may embed another driver manager.
Creating the DSN
See Using unixODBC to install unixODBC and configure DSNs. See Using the DataDirect Driver Manager to create a DSN to connect to OBIEE, Informatica, and SAS.
Connecting to FHIR
Set Url to the Service Base URL of the FHIR server. This is the address where the resources are defined in the FHIR server you would like to connect to.
Generic, Azure-based, AWS-based, and Google-based FHIR server implementations are supported.
Sample Urls for each implementation are found below:
- Generic: http://my_fhir_server/r4b/
- Azure: https://MY_AZURE_FHIR.azurehealthcareapis.com/
- AWS: https://healthlake.REGION.amazonaws.com/datastore/DATASTORE_ID/r4/
- Google: https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/
Authenticating to FHIR
Generic FHIR Instances
The driver supports connections to custom instances of FHIR.
Authentication to custom FHIR servers is handled via OAuth.
Before you can connect to custom FHIR instances, you must set ConnectionType to Generic.
OAuth
Set the AuthScheme to OAuth.
OAuth requires the authenticating user to interact with FHIR using the browser. The driver facilitates this in various ways as described in the following sections.
Before following the procedures below, you need to register an OAuth app with the service to obtain OAuthClientId and OAuthClientSecret.
Desktop Applications
Get and Refresh the OAuth Access Token
After setting the following, you are ready to connect:
- OAuthClientId: Set this to the client Id assigned when you registered your app.
- OAuthClientSecret: Set this to the client secret assigned when you registered your app.
- CallbackURL: Set this to the redirect URI defined when you registered your app. For example: https://localhost:3333
- OAuthAuthorizationURL: This is the URL where the user logs into the service and grants permissions to the application.
- OAuthAccessTokenURL: This is the URL where the request for the access token is made.
- OAuthRefreshTokenURL: This is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that, for your data source, this may be the same as the access token URL.
Headless Machines
To configure the driver to use OAuth with a user account on a headless machine, you need to authenticate on another device that has an internet browser.
- Choose one of two options:
- Option 1: Obtain the OAuthVerifier value as described in "Obtain and Exchange a Verifier Code" below.
- Option 2: Install the driver on a machine with an Internet browser and transfer the OAuth authentication values after you authenticate through the usual browser-based flow, as described in "Transfer OAuth Settings" below.
- Configure the driver to automatically refresh the access token on the headless machine.
Option 1: Obtain and Exchange a Verifier Code
To obtain a verifier code, you must authenticate at the OAuth authorization URL.
Follow the steps below to authenticate from the machine with an Internet browser and obtain the OAuthVerifier connection property.
- Choose one of these options:
- Create the Authorization URL by setting the following properties:
- InitiateOAuth: Set to OFF.
- OAuthClientId: Set to the client Id assigned when you registered your application.
- OAuthClientSecret: Set to the client secret assigned when you registered your application.
- Create the Authorization URL by setting the following properties:
- Log in and grant permissions to the driver. You are then redirected to the redirect URI, which contains the verifier code.
- Save the value of the verifier code. Later you will set this in the OAuthVerifier connection property.
On the headless machine, set the following connection properties to obtain the OAuth authentication values.
- InitiateOAuth: Set this to REFRESH.
- OAuthVerifier: Set this to the verifier code.
- OAuthClientId: Set this to the Client Id in your custom OAuth application settings.
- OAuthClientSecret: Set this to the Client Secret in the custom OAuth application settings.
- OAuthSettingsLocation: Set this to persist the encrypted OAuth authentication values to the specified location.
After the OAuth settings file is generated, you need to re-set the following properties to connect:
- InitiateOAuth: Set this to REFRESH.
- OAuthClientId: Set this to the client Id assigned when you registered your application.
- OAuthClientSecret: Set this to the client secret assigned when you registered your application.
- OAuthSettingsLocation: Set this to the location containing the encrypted OAuth authentication values. Make sure this location gives read and write permissions to the driver to enable the automatic refreshing of the access token.
Option 2: Transfer OAuth Settings
Prior to connecting on a headless machine, you need to install and create a connection with the driver on a device that supports an Internet browser. Set the connection properties as described in "Desktop Applications" above.
After completing the instructions in "Desktop Applications", the resulting authentication values are encrypted and written to the location specified by OAuthSettingsLocation. The default filename is OAuthSettings.txt.
Once you have successfully tested the connection, copy the OAuth settings file to your headless machine.
On the headless machine, set the following connection properties to connect to data:
- InitiateOAuth: Set this to REFRESH.
- OAuthClientId: Set this to the client Id assigned when you registered your application.
- OAuthClientSecret: Set this to the client secret assigned when you registered your application.
- OAuthSettingsLocation: Set this to the location of your OAuth settings file. Make sure this location gives read and write permissions to the driver to enable the automatic refreshing of the access token.
Azure FHIR Instances
The driver supports connections to instances of FHIR hosted on Microsoft Azure.
You can authenticate with Azure Active Directory, an Azure Service Principal, or Azure MSI.
Before you can connect to FHIR instances hosted on Azure, you must set ConnectionType to Azure.
Azure Active Directory
You can connect to FHIR instances hosted on Azure using an OAuth app registered with Azure Active Directory.Set AuthScheme to AzureAD.
Embedded App
CData provides an embedded OAuth application that simplifies OAuth desktop Authentication. To authenticate using the embedded OAuth app, connect without setting any additional connection properties.
Custom App
Alternatively, you can create a custom OAuth application. See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.
Once your OAuth app has been created, set the following to connect:
- OAuthClientId: Set this to the Application (client) ID, found on the Overview page of the OAuth app.
- OAuthClientSecret: Set this to the Value of the client secret, generated at the Certificates and secrets page of the OAuth app.
- AzureTenant (single tenant apps only): Set this to the Azure tenant Id, found on the Overview page of the OAuth app.
- CallbackURL: Set this to the value you specified for Redirect URI during the creation of your custom OAuth app.
Azure MSI
If you are running FHIR on an Azure VM, set AuthScheme to AzureMSI to authenticate using Managed Service Identity (MSI) credentials.
The MSI credentials will then be automatically obtained for authentication.
Azure Service Principal
You can authenticate to Azure-hosted instances of FHIR using an Azure service principal.
See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.
Once your OAuth app has been created, set the following to connect:
- AuthScheme: Set this to AzureServicePrincipal.
- OAuthClientId: Set this to the Application (client) ID, found on the Overview page of the OAuth app used to authenticate to FHIR on Azure.
- OAuthClientSecret: Set this to the Value of the client secret, generated at the Certificates and secrets page of the authenticating OAuth app.
- CallbackURL: Set this to the value you specified for Redirect URI during the creation of your custom OAuth app.
- OAuthJWTCert: Set this to the path of your service principal's certificate.
- OAuthJWTCertType: Set this to your service principal's certificate type.
AWS FHIR Instances
The driver supports connections to instances of FHIR hosted on AWS.
You can authenticate with AWS Root Keys, AWS EC2 Roles, or AWS IAM Roles.
Before you can connect to FHIR instances hosted on AWS, you must set ConnectionType to AWS.
AWS Root Keys
You can authenticate using the access keys for the root AWS user. Set the following:
- AuthScheme: Set this to AwsRootKeys.
- AWSAccessKey: Set this to your AWS account access key. This value is accessible from your AWS security credentials page.
- AWSSecretKey: Set this to your AWS account secret key. This value is accessible from your AWS security credentials page.
AWS IAM Roles
To authenticate to your AWS-hosted FHIR using IAM roles, set the following:
- AuthScheme: Set this to AwsIAMRoles.
- AWSAccessKey: Set this to your AWS account access key. This value is accessible from your AWS security credentials page.
- AWSSecretKey: Set this to your AWS account secret key. This value is accessible from your AWS security credentials page.
- AWSRoleARN: Set this to the Amazon Resource Name of the role you want to use when authenticating.
AWS EC2 Roles
If you are using the driver from an EC2 Instance and have an IAM Role assigned to the instance, you can use the IAM role to authenticate.
Set AuthScheme to AwsEC2Roles.
If you are also using an IAM role to authenticate, you must additionally set AWSRoleARN to the Role ARN for the role you'd like to authenticate with. This will cause the driver to attempt to retrieve credentials for the specified role.
Google FHIR Instances
The driver supports connections to instances of FHIR hosted on Google Cloud Platform.
You can authenticate with standard OAuth or Service account authentication (with a JWT).
Before you can connect to FHIR instances hosted on Google Cloud Platform, you must set ConnectionType to Google.
OAuth
Set AuthScheme to OAuth.
Embedded App
CData provides an embedded OAuth application that simplifies OAuth desktop Authentication. To authenticate using the embedded OAuth app, connect without setting any additional connection properties.
Custom App
Alternatively, you can create a custom OAuth application. See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.
Unlike the Generic connection type, when ConnectionType is set to Google, OAuthAuthorizationURL, OAuthRefreshTokenURL, and OAuthAccessTokenURL are not required to be set.
This is because, when connecting to an instance of FHIR hosted on Google Cloud Platform, these properties have default values embedded in the driver.
Aside from omitting those properties, follow the same procedures for configuring OAuth authentication as with generic implementations of FHIR (see the "OAuth" section under the "Generic FHIR Instances" section above).
Service Accounts (OAuth JWT)
To authenticate using a service account, you must create a new service account and have a copy of the accounts certificate.
Google JSON Certificates
If you would like to use a JSON file as the certificate, you need to set these properties:
- AuthScheme: Set this to OAuthJWT.
- OAuthJWTCertType: Set this to GOOGLEJSON.
- OAuthJWTCert: 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.
PFX File Certificates
If you would like to use a PFX file as the certificate, you need to set these properties instead:
- AuthScheme: Set this to OAuthJWT.
- OAuthJWTCertType: Set this to PFXFILE.
- OAuthJWTCert: Set this to the path to the .pfx file provided by Google.
- OAuthJWTCertPassword (optional): Set this to the .pfx file password. In most cases, you will need to set this 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: 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.
Refreshing OAuth Values
The driver can refresh the temporary OAuth access tokens obtained during the browser-based OAuth authentication exchange. By default, the driver saves the encrypted tokens in the odbc.ini file corresponding to the DSN. Access to this odbc.ini file can be restricted in the case of System DSNs.
To enable the automatic token exchange, you can give the driver write access to the system odbc.ini. Or, you can set the OAuthSettingsLocation connection property to an alternate file path, to which the driver would have read and write access.
OAuthSettingsLocation=/tmp/oauthsettings.txt
Installing Dependencies for OAuth Authentication
The OAuth authentication standard requires the authenticating user to interact with FHIR, using a web-browser. If the first OAuth interaction is to be done on the same machine the driver is installed on, for example, a desktop application, the driver needs access to the xdg-open program, which opens the default browser.
To satisfy this dependency, install the corresponding package with your package manager:
Debian/Ubuntu Package | RHEL/Fedora Package | File |
xdg-utils | xdg-utils | xdg-open |
Set the Driver Encoding
The ODBC drivers need to specify which encoding to use with the ODBC Driver Manager. By default, the CData ODBC Drivers for Unix are configured to use UTF-16 which is compatible with unixODBC, but other Driver Managers may require alternative encoding.
Alternatively, if you are using the ODBC driver from an application that uses the ANSI ODBC API it may be necessary to set the ANSI code page. For example, to import Japanese characters in an ANSI application, you can specify the code page in the config file '/opt/cdata/cdata-odbc-driver-for-fhir/lib/cdata.odbc.fhir.ini':
[Driver]
AnsiCodePage = 932