The SAS Viya Stable 2024.02 release has introduced support for Azure Key Vault backed Authentication Domains. This means that an authentication domain as seen from SAS Viya is a reference to a secret in an Azure Key Vault. The initial release of this feature is targeted only at Password Authentication Domains. So that a userId and password are stored in an Azure Key Vault secret rather than stored in SAS Viya. This password authentication domain can then be used in SAS code, a caslib statement, or other locations an authentication domain could be used. The connection to Azure Key Vault will use Microsoft Entra ID OpenID Connect outbound Single Sign-On. Therefore, access to the secret in Azure Key Vault will be as the individual end-user and controlled via standard Microsoft Entra ID RBAC. In this post we will examine the use-case that benefits from this new feature and how to configure this feature.
Azure Key Vault backed authentication domains work very well when dealing with a shared credential that needs to be securely made available to a group of users. This might be the userId and password used to access a shared data source like Oracle. Specifying an authentication domain is valid for the LIBNAME statement and caslibs. This feature is not aimed at individual access to a data source where something like Microsoft Entra ID outbound Single Sign-On would be a more appropriate mechanism. For example, if you have a Microsoft SQL Server instance in Azure and require individual access to the data you should use Microsoft Entra ID SSO.
The SAS documentation covers how to configure SAS Viya to use external credentials stored in Azure Key Vault. This relies on using OpenID Connect authenticate with Microsoft Entra ID and the additional settings to enable outbound Single Sign-On. To enable SAS Viya to be able to access Azure Key Vault as the authenticated individual an additional API permission will be required. To allow the App Registration for SAS Viya in Microsoft Entra ID to use user_impersonation to access Azure Key Vault in the Azure portal you would:
Alternatively, with the Azure CLI you could use the following commands to set the same API permissions:
myPermAdd=$(az ad app permission add --id ${myAppID} --api cfa8b339-82a2-471a-a3c9-0fc0be7a4093 --api-permissions f53da476-18e3-4152-8e01-aec403e6edc0=Scope)
myPermGrant=$(az ad app permission grant --id ${myAppID} --api cfa8b339-82a2-471a-a3c9-0fc0be7a4093 --scope user_impersonation)
Where you have first defined ${myAppID} to be the AppId of the App registration that you are using for SAS Viya. The two long UUID values are fixed for the Azure Key Vault Service in the Azure Commercial Cloud, these values will be different in the Azure Government Cloud or Azure China Cloud.
Remember, either when first adding the API permissions or when adding to the API permissions you will need to grant admin consent. Admin consent is required since the individual users will not be able to grant consent themselves as the connection is happening in the background.
The Azure Key Vault itself does not require any specific configuration. You might want to consider limiting the network access to the Azure Key Vault such that only the SAS Viya Kubernetes environment is able to access it. The network access can be limited to either specified virtual networks in Azure or to specific IP addresses or ranges of IP addresses. The secret object you create in the Azure Key Vault does require specific configuration:
For example, this might look like the following:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Equally, the Azure CLI could be used to define the secret with the following:
mySecret=$(az keyvault secret set --name azurePG --vault-name "$PREFIX-Vault" --description password --tags userId=$pgUser --value $pgPass)
Notice: with some versions of the Azure CLI the content type is defined as the description.
Azure RBAC can then be used to secure access to both the Azure Key Vault and the secret itself.
Once the configuration in Azure is complete SAS Viya can be configured to use the Azure Key Vault secret as an authentication domain. The SAS Viya 2024.02 Stable release introduces the sas.credentials.azure configuration type. The configuration for sas.credentials.azure only has two properties:
You can specify as many instances of the sas.credentials.azure configuration as you require. So long as the name is unique and only contains alphanumeric characters and dashes. For example, if you have a shared Oracle account for each department, you would create a secret in an Azure Key Vault for each departmental shared user and then a corresponding definition under sas.credentials.azure.
A virtual authentication domain is created in SAS Viya that now maps to the secrets stored in Azure Key Vault. However, this authentication domain is not displayed in the SAS Environment Manager Domains window or when using the SAS Viya CLI.
Azure Key Vault backed Authentication Domains, introduced with the SAS Viya 2024.02 Stable release, enable you to off-load the storing of shared credentials to Azure Key Vault. This is dependent on you using OpenID Connect authentication with Microsoft Entra ID and having correctly configured outbound Single Sign-On. This feature allows you to manage the access controls for the shared credentials purely within Azure. Your SAS Viya environment and data sources you are accessing do not need to be running in Azure to leverage this feature.
If you want to explore this topic in more detail, you can refer to Advanced Topics in Authentication on SAS Viya.
Find more articles from SAS Global Enablement and Learning here.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.