SAS Viya Azure AD Single Sign-On to Other Azure Services
SAS Viya has supported single sign-on from SAS Viya to other Microsoft Azure services since February 2021 with the Stable V.... Further data sources have been added through-out 2021. This functionality enables end-users to access Azure services from SAS Compute jobs or SAS Cloud Analytic Services without needing to provide additional credentials. In this blog I want to present an overview of how the single sign-on operates, discuss what is required in the Azure Active Directory configuration, and present how to set this configuration using the Azure CLI.
Support for Azure AD Single Sign-On
The table below lists the SAS Viya Stable versions which introduced Azure AD single sign-on with some different SAS procedures and SAS/ACCESS engines.
Overview of Azure AD Single Sign-On
At a high-level Azure AD Single Sign-on allows a SAS Viya environment configured with OpenID Connect authentication to provide access to Azure resources without needing the end-users to provide additional credentials. End-user’s log into SAS Viya using OpenID Connect and then seamlessly as part of the login process the required tokens are requested by SAS Logon Manager from Azure Active Directory.
Specifically, when the end-user authenticates with SAS Logon Manager using OIDC SAS Viya requests and stores an Azure AD Refresh Token for the end-user. This Refresh Token is stored with the Credentials microservice, in a domain with the same name as the OIDC configuration. Then when the end-user runs code to access another Azure resource, like Azure SQL Server, the LIBNAME or CASLIB requests an Azure Access Token using the Refresh Token that was stored. The following diagram illustrates this:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Calling the different SAS Viya components uses the Viya Access Token, so for example in SAS Studio launching a SAS Compute Server session. Then only when the end-user submits code to use the data source is the Azure Access Token requested.
This does require some additional configuration of OIDC settings within SAS Viya, as covered in the documentation. The sas.logon.oauth.providers configuration must include the following for Azure AD Single Sign-On:
- The additionaConfiguration setting containing the property credentials.enabled with the value true.
- The scopes setting including offline_access in the comma separated list.
Adding offline_access to the scopes that will be requested from Azure AD when authenticating end-users with OIDC does require some additional Azure Active Directory configuration. We’ll look at the Azure Active Directory configuration next.
Azure Active Directory Configuration
SAS Viya is represented in Azure Active Directory as an App Registration. This App registration is created as part of the configuration of OIDC authentication with Azure Active Directory. The key part of the configuration of the App registration that enables Azure AD Single Sign-on is the API permissions. More information on the permission model within Azure AD can be found in the Microsoft documentation (https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent).
The offline_access scope that we included in the SAS Viya configuration must be granted within the API permissions settings of the App registration. The offline_access scope is what allows SAS Viya to request Refresh tokens from Azure AD. If you are adding this permission within the Azure Portal, then offline_access is part of Microsoft Graph and is grouped under OpenId permissions, as shown here:
Then for Azure AD Single Sign-on to provide access to other resources (see below) these must also be added via the API Permissions. From the SAS Viya documentation we have the following table:
This table shows the Azure Service Name and which Azure resources this will provide access to. The Azure Service Name is what you would search for in the Azure Portal when assigning the additional API permissions. For each of these you will need to provide the SAS Viya App registration with delegated permissions. Microsoft describes this as "Delegated permissions are used by apps that have a signed-in user present. For these apps, either t...
For the services listed in the table the only scope of delegated permission that can be added is user_impersonation. The user_impersonation scope allows the application to access the Azure Service acting as the users themselves.
For example, for the first entry Azure Data Lake, the API permissions in the Azure Portal would look like the following:
Once the API permissions have been added as an administrator, we can consent for all the end-users. This is required for the Azure AD Single Sign-on API permissions, since when the permissions are required there will be no-way for end-users themselves to consent. Also, providing the admin consent for offline_access will simplify the login process for end-users since they will not be presented with a possibly confusing consent screen as part of the login flow. Finally, if this is a multi-tenant App registration, so where users from different Azure Active Directory tenants can sign into the application, then we must always provide admin consent. Granting admin consent can be performed on the API permissions screen and will apply to all API permissions listed for the application. To grant admin consent, you need an Azure AD user account with one of the following roles:
- Global Administrator or Privileged Role Administrator, for granting consent for apps requesting any permission, for any API.
- Cloud Application Administrator or Application Administrator, for granting consent for apps requesting any permission for any API, except Azure AD Graph or Microsoft Graph app roles (application permissions).
- A custom directory role that includes the permission to grant permissions to applications, for the permissions required by the application.
Using the Azure CLI
So far, we have looked at setting the API permissions using the Azure Portal. This is not always the most efficient mechanism to make configuration changes. Quite often it’s preferable to be able to script such configuration changes. Here we will look at how we can make the same changes using the Azure CLI. We can use the command az ad app permission to manage an application’s OAuth2 permissions. Specifically, the command az ad app permission add allows you to add the API permission to an App registration. This command has the form:
az ad app permission add --api
--api-permissions
--id
Where --api is the unique identifier for the resource that the application requires access to and --id is the Identifier uri, application id, or object id. The --api-permissions parameter is a space-separated list of {id}={type}. {id} is resourceAccess.id - The unique identifier for one of the oauth2PermissionScopes or appRole instances that the resource application exposes. {type} is resourceAccess.type - Specifies whether the id property references an oauth2PermissionScopes or an appRole. The possible values are Scope (for OAuth 2.0 permission scopes) or Role (for app roles).
Then we also have the command az ad app permission grant to grant the application an API delegated permission. This command has the form:
az ad app permission grant --api,
--id,
--scope
[--consent-type {AllPrincipals, Principal}]
[--principal-id]
Where --api has the same value as the az ad app permission add command and the --scope parameter will take the ID value that is used in the --api-permissions parameter.
To be able to find the correct values of --api and --api-permissions we can use the command az ad sp show --id {{SERVICE}} --query '[appId,oauth2PermissionScopes]'. Where {{SERVICE}} could take one of the following values:
Azure Data Lake = https://datalake.azure.net/Azure OSSRDBMS Database = https://ossrdbms-aad.database.windows.netAzure Service Management = https://management.azure.com/Azure SQL Database = https://database.windows.netAzure Storage = https://storage.azure.com
Running the command for Azure Data Lake:
az ad sp show --id https://datalake.azure.net/ --query '[appId,oauth2PermissionScopes]'
You should see the following:
This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
[
"e9f49c6b-5ce5-44c8-925d-015017e9f7ad",
[
{
"adminConsentDescription": "Allow the application full access to the Azure Data Lake service on behalf of the signed-in user",
"adminConsentDisplayName": "Have full access to the Azure Data Lake service",
"id": "9f15d22d-3cdf-430f-ba48-f75401c0408e",
"isEnabled": true,
"type": "User",
"userConsentDescription": "Allow the application full access to the Azure Data Lake service on your behalf",
"userConsentDisplayName": "Have full access to the Azure Data Lake service",
"value": "user_impersonation"
}
]
]
Of this output the first ID value is what you will use for --api and the second ID is the value for --api-permissions. As such, the command to add API permissions to access Azure Data Lake to an App registration with the appId given by ${myAppID} will be:
az ad app permission add --id ${myAppID} --api e9f49c6b-5ce5-44c8-925d-015017e9f7ad --api-permissions 9f15d22d-3cdf-430f-ba48-f75401c0408e=Scope
az ad app permission grant --id ${myAppID} --api e9f49c6b-5ce5-44c8-925d-015017e9f7ad --scope 9f15d22d-3cdf-430f-ba48-f75401c0408e
Finally, once all the required API permissions have been added and granted, you can use the command az ad app permission admin-consent to grant the admin consent for all API permissions assigned to the application. This command just takes a single parameter to target the App registration ID, for example:
az ad app permission admin-consent --id ${myAppID}With these steps completed you have replicated the steps we outlined above in the Azure Portal, but by using the Azure CLI. At this point your configuration of Azure AD Single Sign-On is complete.
Conclusion
We have seen that SAS Viya Azure AD Single Sign-On provides the end-users with seamless access to other resources also secured with Azure Active Directory. The configuration for this from the SAS Viya side is straight forward and only requires two minor changes to the OIDC configuration. From the Azure Active Directory side, the configuration itself is also straight forward and can be performed either in the Azure Portal or by using the Azure CLI. However, the only slight complexity is selecting the correct delegated permissions to apply to the App registration.
Find more articles from SAS Global Enablement and Learning here.
