SAS Viya 2024.02 Azure Key Vault Backed Authentication Domain

[#1]

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.

Use-Case for Azure Key Vault Backed Authentication Domains

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.

How to Configure Azure Key Vault Backed Authentication Domains

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:

1. Choose Microsoft Entra ID from the list of Azure services.
2. Navigate to App Registrations and select the App registration that you are using for SAS Viya.
3. Select API permissions, and then click the + button to add a permission.
4. Search for Azure Key Vault.
5. Select Delegated permissions (the application needs to access the API as the signed-in user). For Permissions, select user_impersonation.

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:

1. Only a secret object is supported.
2. The name should be chosen with care as this will also be the name of the SAS Viya authentication domain. The name can only contain alphanumeric characters and dashes.
3. The value will be the password of the credential set.
4. The content type must be password.
5. A tag must be added, where:
   1. The Tag Name must be userId.
   2. The Tag Value must be the actual username/userid for the credential set that corresponds to the password in the value.

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:

1. For keyVault, specify the URL to the Azure Key Vault.
2. For name, specify the name of the secret.

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.

Conclusion

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.