SAS Viya 2025.11 Custom Application Authenticate with Client Assertion

[#1]

With the SAS Viya STABLE 2025.11 release SAS Logon Manager has been updated to enable authenticating a custom application using a Microsoft Entra ID Access Token. Using the client assertion replaces using the client credentials for authenticating the custom application with SAS Logon Manager. In this post we’ll examine how and why this can be configured. 

Why

Before we dive into the technical aspects of the topic we’ll discuss why we would want to use client assertions to authenticate. Traditionally, we would use client secrets to authenticate using the client-credentials grant type. But this involves sharing the client secret and then transmitting this over the network to authenticate.

Alternatively, using a client assertion to authenticate means only sending an Access Token to authenticate the client. The JWT access token will be generated by a third-party OIDC Provider such as Microsoft Entra ID. We need to authenticate initially to this third-party, but there are various options for how this can be accomplished. There is even password-less options for this stage. For example, we could leverage a Managed Identity with a virtual machine or something like an Azure Function App.

The access token used to authenticate against SAS Logon Manager will have a significantly shorter lifetime than the client secret. Obtaining the access token also requires us to separately authenticate proving our identity at that point in time. Finally, the access token’s digital signature is validated by SAS Logon Manager ensuring the information has not been tampered with in transit. Hence, we can see using the client assertion will be a more secure option for authenticating our custom application.

How

To be able to use a client assertion to authenticate the custom application registered with SAS Logon Manager we need to provide SAS Logon Manager with additional information. The client assertion will be a JSON Web Token (JWT) generated by the third-party OIDC provider. This will be signed and contain specific attributes or claims about the authenticated principal. For this scenario, the key claims are:

1. The issuer of the JWT (iss), which will be the third-party OIDC Provider,
2. The subject of the JWT (sub), which will be the authenticated principal,
3. The audience of the JWT (aud), which will be the party the JWT has been generated for.

The three items need to be added to the custom application (or client) registration in SAS Logon Manager. There is a specific data construct in the registration called the clientjwt that holds this information.

Currently, the SAS Viya CLI does not facilitate adding this information. Instead, we must use the SAS Logon Manager REST API to add this information. Also, this needs to be added after the custom application has been initially registered. This does mean that the initial registration must set a client secret, even though we will not be using it.

We can use a command like this to add the clientjwt settings to an existing custom application:

curl "$INGRESS_URL/SASLogon/oauth/clients/$client_ID/clientjwt" -X PUT \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $myToken" \
    -H 'Accept: application/json' \
    --data-urlencode "iss=$JWT_Issuer" \
    --data-urlencode "sub=$JWT_Subject" \
    --data-urlencode "aud=$JWT_Audience" \
    --data-urlencode "client_id=$client_ID"

Where we have the three attributes for the JWT as $JWT_Issuer, $JWT_Subject, and $JWT_Audience.

Example Scenario

Now, that we understand how we can implement client authentication with a JWT we’ll consider placing this into a specific scenario. In this scenario we have a SAS Viya environment that has just been deployed. This environment will be configured with SCIM and OpenID Connect with Microsoft Entra ID. At this initial point in time, there are no users or groups defined in SAS Viya. The only user that is available to us is the sasboot user.

We want to configure SCIM, but we want to be able to regularly update the Bearer Token that is part of the Entra ID configuration. We want to run this process without needing to store the client credential from SAS Viya in Azure.

So, our proposal is to use the Enterprise Application or Service Principal in Microsoft Entra ID that has SCIM configured for it. This assumes you have already completed the documented steps to create the Enterprise Application. We will authenticate to Microsoft Entra ID with this Service Principal and then use that authentication to authenticate to SAS Viya. To be able to authenticate as the Service Principal we need to have credentials registered for it. It is better to use a certificate for authentication, rather than a password.

The Azure CLI can reset the credentials for a Service Principal. The certificate can either be provided or automatically generated and stored in Azure KeyVault. For example, we could use OpenSSL to create private key and self-signed certificate for our Service Principal with the following:

openssl req  -nodes -new -x509  \
    -keyout ~/SCIM_SP.key \
    -out ~/SCIM_SP.cert \
    -subj "/CN=SCIM-SP"
cat ~/SCIM_SP.key > ~/SCIM_SP.pem
cat ~/SCIM_SP.cert >> ~/SCIM_SP.pem

Then we can fetch details of the Enterprise Application we have configured with SCIM, by referencing the display name:

mySCIM_SPID=$(az ad sp list --display-name ${MySCIMApp} --query "[].id" -o tsv)
mySCIM_SPAppID=$(az ad sp list --display-name ${MySCIMApp} --query "[].appId" -o tsv)
mySCIM_TenantID=$(az ad sp list --display-name ${MySCIMApp} --query "[].appOwnerOrganizationId" -o tsv)

Then we can use the Azure CLI to associate the certificate with the Enterprise Application:

az ad sp credential reset --id ${mySCIM_SPID} --append --cert @~/SCIM_SP.cert

Now, assuming you have already completed the steps to register the OAuth client, we can add the clientjwt settings. Remember currently we need to use the SAS Logon Manager REST API for these steps. First, we need to obtain an access token for calling the REST API as a member of SAS Administrators. However, if we have no users defined at this stage so we’ll need to use the sasboot user. We can login with the SAS Viya CLI to obtain the token:

/opt/sas/viya/home/bin/sas-viya auth login -u sasboot -p $(cat ~/SASBootPass.txt)
myToken=$(cat ~/.sas/credentials.json |jq -r '.Default."access-token"')

Then we can examine the current SCIM client registration with SAS Logon Manager using the following:

curl "$INGRESS_URL/SASLogon/oauth/clients/idp-client-id" -X GET \
    -H "Authorization: Bearer $myToken" \
    -H 'Accept: application/json' |jq -r

Now we can set the clientjwt settings for the client registration:

curl "$INGRESS_URL/SASLogon/oauth/clients/idp-client-id/clientjwt" -X PUT \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $myToken" \
    -H 'Accept: application/json' \
    -d "{
  \"iss\": \"https://sts.windows.net/${mySCIM_TenantID}/\",
  \"sub\": \"${mySCIM_SPID}\",
  \"aud\": \"https://management.core.windows.net/\",
  \"client_id\" : \"idp-client-id\"
}"| jq -r

So, where did we get the values we entered the clientjwt? The issuer is easy, that has a standard form for all version 1 tokens generated by Microsoft Entra ID and can be confirmed from here: https://login.microsoftonline.com/common/.well-known/openid-configuration. The subject is also relatively easy as that is the Service Principal ID we fetched earlier. Finally, we have the audience which depends on how we obtain the access token to authenticate to SAS Logon Manager.

The easiest way to obtain an access token to send to SAS Logon Manager is to use the Azure CLI. The Azure CLI has the function get-access-token which can be used as follows:

mySPToken=$(az account get-access-token --query accessToken --output tsv)

On this command since we have not specified resource, resource-type, or scope we have obtained an access token for the Azure Management endpoint. If we inspect the returned token, we will see the audience is https://management.core.windows.net/.

Now we have the clientjwt settings registered and the access token for the Service Principal we can obtain the access token from SAS Logon Manager to use in the SCIM configuration. The following command will return this access token:

curl "$INGRESS_URL/SASLogon/oauth/token" -X POST\
 -H 'Accept: application/json'\
 --data-urlencode "client_id=idp-client-id"\
 --data-urlencode "client_assertion=$mySPToken"\
 --data-urlencode "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer"\
 --data-urlencode "grant_type=client_credentials"\

Then if you inspect this token, you’ll find it correctly includes the "SCIM" authorities. This places the client in the SCIM custom group which provides the SAS Viya authorizations to access the SCIM endpoints. This token can then be used in the Microsoft Entra ID SCIM provisioning job.

We can then repeat these last two steps each time we want to update the token used in the Microsoft Entra ID SCIM provisioning job. We will leave the steps to automate updating the provisioning job for you to investigate.

Conclusion

In this post we have demonstrated how we can take an access token from Microsoft Entra ID and use that to authenticate to SAS Logon Manager as a custom application. We have seen how this is dependent on the clientjwt settings within the registration inside SAS Logon Manager. To be able to accept access tokens generated by Microsoft Entra ID SAS Logon Manager did require a slight code change. So, this is only supported from the SAS Viya 2025.11 Stable release.

In this post we looked at the example of obtaining the access token for the SCIM configuration using this approach. In future posts we’ll look at other scenarios this feature can be applied to.

Find more articles from SAS Global Enablement and Learning here.