SAS Viya with Non-Human Identities

In this post we’ll discuss how we can use Non-Human Identities with SAS Viya. We will cover what we mean by Non-Human Identity and how we can leverage these types of identities with SAS Viya. You will need to be running a version of SAS Viya after the Stable 2026.02 release, to make full use of these features discussed here.

Defining Non-Human Identities

We will start by looking at what is meant by Non-Human Identity, or non-personal accounts. There is a wider more generic definition which is provided by the NHI Index and then also a more specific definition provided by Microsoft.

The definition provided by the NHI Index; is that a Non-Human Identity (commonly abbreviated as "NHI") refers to any digital credential used programmatically by machines, workloads, applications, or automated processes to authenticate and perform operations on a given resource. These identities are crucial for ensuring seamless interactions across cloud services, SaaS platforms, and on-premises data centers. As NHIs proliferate in modern IT environments, their secure management becomes vital to protect against unauthorized access.

The NHI Index positions that non-human accounts vary based on their origin and purpose within an IT environment. The NHI Index believes they are typically categorized into several types.

Tokens – these are small pieces of data, often temporary, used to authenticate and authorize access to services (e.g., OAuth tokens for API access).
Secrets are sensitive data such as passwords, encryption keys, or API tokens, used for authentication and encryption (e.g., an API key stored in a secure vault).
API Keys are unique identifiers that are used to authenticate to APIs and perform programmatic operations, facilitating access to specific resources and functionalities (e.g., a cloud service API key used to manage resources).
Service Accounts are specialized accounts used by applications or automated processes to access resources and perform tasks (e.g., a service account managing backups in a cloud environment).
Certificates are digital certificates that verify the identity of entities and enable encrypted communications (e.g., an SSL certificate for a secure website).

The NHI Index thinks that it's important to distinguish between NHIs and IAM roles, as they serve different functions even though they may seem similar in cloud environments. NHIs - such as tokens, secrets, or service accounts - are credentials used to directly authenticate and authorize access to resources. In other words, NHIs are like digital "keys" that prove an entity's identity and allow it to access certain systems.

Microsoft has a slightly different view on non-human identities. Microsoft considers that not all identities in a digital environment represent people. As organizations use more automation and cloud services, it’s important to understand the key differences among human, non-human, and machine identities.

Human identities are assigned to real people - like employees or partners - who interact with systems manually. They’re typically managed by roles, multifactor authentication, and access policies.
Non-human identities are software-based agents - such as programs, bots, AI agents, or digital tools - that access systems automatically. They’re essential for automation but often go unnoticed in traditional identity governance.
Machine identities are a specialized type of non-human identity, used to secure communication between devices, servers, or virtual machines. These often rely on certificates or cryptographic keys to authenticate infrastructure components.

Further, Microsoft proposes strategies that organizations should employ when dealing with non-human identities. Microsoft suggests the following best practices help reduce risk, avoid identity sprawl, and ensure your systems stay protected as your system grows.

Apply least-privilege access. Grant only the permissions each identity needs - and nothing more. Try to avoid assigning broad or admin-level access. This minimizes the impact if an identity is compromised.
Automate lifecycle management. Use identity tools to automate the creation, rotation, and removal of non-human identities. Tying identities to the lifecycle of the task or service they support helps prevent unused accounts from remaining in your environment.
Use managed identities where possible. In cloud environments, managed identities take care of secure access and password updates automatically. This means there’s no need to store sensitive information like passwords or access keys in your code.
Centralize visibility and control. Track all non-human identities through a centralized IAM system. Visibility across cloud, on-premises, and hybrid environments makes it easier to spot unused, misconfigured, or risky identities.
Secure credentials. Keep sensitive information - like passwords, access keys, and security certificates - in a secure storage system, not in your application code or settings files. Update them regularly and watch for any unusual activity.
Monitor and audit activity. Set up logging and alerts to track how non-human identities are being used. Look for unusual, excessive access attempts, or unexpected behaviour that could indicate misuse.
Review and clean up regularly. Schedule regular reviews of non-human identities and their permissions. Remove unused identities and tighten overly broad access to keep your environment clean and secure.

Adopting these best practices helps organizations stay ahead of identity-related risks, while supporting automation and innovation with confidence.

Use Cases

The key requirements for leveraging a non-human identity are:

We need to be able to connect to SAS Viya and authenticate in an automated way.
We need to ensure we are not storing or sharing any long-lived credentials that will then need additional management overhead.
Finally, we need the process to occur in the context of a system account and not as a named individual user.

If we take Microsoft Entra ID as our identity provider, then what types of identity will we be using for the non-human identity?

We might use a service principal. Service principals are security identities used by applications or services to access cloud resources. They act as the application’s identity within an identity platform and are widely used in automation and scripting tasks, or build, test, and deployment workflows, and connections between cloud services and third-party tools. Service principals offer flexible, detailed control over what software can access, but they need to be closely monitored to avoid misuse and keep systems secure.

Or we might use a managed identity. Managed identities are automatically created and managed by cloud platforms, making it easier to control what software can be accessed. Each identity is tied to a specific system or service and only exists for as long as it’s needed. This removes the need for developers to manually handle usernames or passwords - lowering the chance of exposure and improving security. They’re often used to authenticate securely to various cloud services without storing secrets like passwords, API keys, or access tokens, as well as assign access permissions based on roles, with minimal setup, and manage software identities more efficiently as cloud environments grow. Using managed identities helps simplify access, reduce credential management, and lower the risk of software having more access than it needs.

Our SAS Viya solution to meet these requirements and allow either service principals or managed identities to connect will need to use the following. We need to configure a custom application of SAS Logon Manager and configure this custom application to allow authentication using JWT. So that we will be able to authenticate as the custom application using the Microsoft Entra ID access token.

Then the other key part is to preserve the use of the non-human identity throughout SAS Viya. This means being able to run the SAS or SAS Cloud Analytic Services sessions as the defined custom application. This is different to previous discussions where we discussed using custom applications of SAS Logon Manager. In that case we were running sessions in the context of a specific user account. The ability to run sessions as the non-human identity was added with the SAS Viya Stable 2026.02 release.

SAS Viya Configuration

To allow the non-human identity to authenticate as the custom application, and to run processes as the non-human identity, we need to set some specific items in the client registration. First, the value of the client_id registered with SAS Logon Manager should be the object ID or principal ID of the Microsoft Entra ID Managed Identity or Service Principal. This will make it easier for you to track activities performed as the non-human identity.

Next, when we register a custom application, we do not want to specify a value for the client_secret. We must not set it to a blank value but instead exclude the attribute when defining the custom application.

When we launch a SAS session, we need to be able to provide user attributes for the pod that is launched. We need to have a UID and GID for that pod to launch correctly. We can specify the UID and GID the non-human identity will use, as part of the client registration.

Finally, we will need to register the client JWT settings against the custom application. We need to specify the issuer, subject, and audience from the Microsoft Entra ID access token that will be used to authenticate the non-human identity. This ensures SAS Logon Manager only accepts JWT tokens generated for our specific Managed Identity or Service Principal. This fixes that mapping between the Managed Identity or Service Principal and the custom application.

Those are the specific items we need to include in the custom application to enable non-human identity processing.

There will be two steps to correctly configure the custom application. First, we create the client with something like the following:

curl -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-d "{ 
    \"client_id\":\"${ManagedIdentity_ID}\",
    \"scope\": [\"uaa.none\"],
    \"authorities\": [\"${ManagedIdentity_ID}\",
                      \"sas-compute.app_impersonation\",
                      \"cas-shared-default.app_impersonation\"],
    \"authorized_grant_types\": [\"client_credentials \"],
    \"uid\": \"2001\",
    \"gid\": \"2001"}"

Remember, to be able to submit this request we need to have authenticated as a member of SAS Administrators to obtain the $ACCESS_TOKEN. Notice that the client_id is set to the Microsoft Entra ID object ID for the service principal or managed identity. We have not included the client secret attribute, and the authorities attribute includes an optional custom group with the same name as the client_id. Additionally, the authorities attribute contains the permissions the custom application should have. Finally, within the initial custom application registration we set the UID and GID to be used with the SAS Compute Server.

The UID and GID you specify here will be used to launch the pod for the SAS Compute Server. As such, any operating system access, for example to mounted file systems, will be as this UID and GID value. Hence, you should ensure the values are valid for your non-human identity to access any mounted file systems. Remember, for actual users UID and GID information is returned by the Identities microservice.

Then, we need to provide the client JWT settings for the custom application we have just registered. These will allow SAS Logon Manager to validate the provided Microsoft Entra ID access token and tie it to our specific custom application. We would use something like the following:

curl -X PUT "${INGRESS_URL}/SASLogon/oauth/clients/${ManagedIdentity_ID}/clientjwt" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-d "{\"client_id\": \"${ManagedIdentity_ID}\",
     \"iss\": \"https://sts.windows.net/${Tenant_ID}\",
     \"sub\": \"${ManagedIdentity_ID}\",
     \"aud\": \"https://management.core.windows.net\"
    }"

Again, this needs to be completed using the SAS Logon Manager REST API, and we need to include a token generated by authenticating as a member of the SAS Administrators group. Notice the URL now includes the client_id of the custom application we registered, and the method is PUT which means we are updating the existing custom application registration. You will need to obtain some information from your specific Microsoft Entra ID tenant.

The data we submit as part of the put request is the client ID, and subject of the Microsoft Entra ID access tokens, which both are the ID of our Managed Identity or Service Principal. Then we also have two URLs. These are the issuer, which is the URL for Microsoft Entra ID with your tenant ID appended. This will be the https://sts.windows.net address if you obtain an access token for any of the default Microsoft Entra ID scopes. Then the audience of the Microsoft Entra ID access token, this will depend on how you obtain the token from Microsoft Entra ID. We show the URL for the Microsoft Entra ID management endpoint, which will be the default audience for just an initial login to Microsoft Entra ID.

We’ll take a moment to look at those client JWT settings in a bit more detail. The Issuer, obviously this is the OpenID Connect Identity Provider that issues the client JWT. With Microsoft Entra ID providing tokens it can be a little confusing.

Microsoft Entra ID can issue either V1 or V2 tokens. The V1 tokens use https://sts.windows.net with the tenant ID as the issuer. While the V2 tokens use https://login.microsoftonline.com again with the tenant ID. Requesting tokens for most Microsoft endpoints, such as the management endpoint used when logging into the Azure CLI, use V1 tokens.

If you want to use V2 tokens you will need to have a custom application in Microsoft Entra ID which you configure for V2 tokens and expose an API via this custom application. Then when you request an access token to your API, you’ll get a V2 access token.

Next the audience. The audience will be the endpoint or API that you have requested an access token for. For example, when you log in via the Azure CLI you request an access token for the Azure management endpoint, as used above. Anyone logging into the Azure CLI will obtain a token with this audience value, the difference will be the subject of the token.

If you’d prefer to use a different audience, you need to request an access token for a different API. To do this you will need a custom application in Microsoft Entra ID that exposes an API. Then when you request an access token for this API from Microsoft Entra ID the audience will be the API URI.

Given these considerations on the issuer and audience, for production workloads, we would recommend using a custom application with an exposed API. You can then also limit this custom application so that it is only available to the specific non-human identities that you want to be able to connect to SAS Viya.

SAS Viya Usage

Once the custom application of SAS Logon Manager has been defined, we are able to authenticate to SAS Viya as the Non-Human Identity. You will need to have already authenticated to Microsoft Entra ID as the non-human identity. That could be as the managed identity assigned to a resource like a virtual machine, or as a service principal using its certificate.

First, we use the Azure CLI to obtain a fresh access token, in the example below we don’t specify a scope so the audience will be the URL https://management.core.windows.net.

MS_ACCESS_TOKEN=$(az account get-access-token|jq -r '.accessToken')

Then we can use the SAS Logon Manager REST API to obtain the SAS Viya token:

SAS_ACCESS_TOKEN=$(curl "${INGRESS_URL}/SASLogon/oauth/token" -X POST \
  -H 'Accept: application/json' \
  --data-urlencode "client_id=${ManagedIdentity_ID}" \
  --data-urlencode "client_assertion=${MS_ACCESS_TOKEN}" \
  --data-urlencode "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \
  --data-urlencode "grant_type=client_credentials" 2> /dev/null | jq -r .access_token)

On that request we include the client_id, a client assertion, and client assertion type. The client assertion is the access token from Microsoft Entra ID. While the client assertion type is the specific string for the type, which tells SAS Logon Manager we are submitting a client JWT. The final part of the submission is the grant type which is set to client credentials.

This request will return the SAS Viya token which we can then use to interact with the other SAS Viya services. The SAS Viya Forge contains a well-documented example of executing a job with a non-human identity.

Conclusion

Here we have discussed what we mean by either a Non-Human Identity or a non-personal account. We’ve presented the specific example when using Microsoft Entra ID where the Non-Human Identity is a Managed Identity or Service Principal. We’ve walked through how we need to configure the custom application for SAS Logon Manager that represents the Non-Human Identity in SAS Viya. Then shown how you authenticate to SAS Viya as this Non-Human Identity.

If you want to explore these concepts in more detail you can review this topic in the SAS® Viya® Core Authentication Topics workshop, which has just been updated for SAS Viya 2026.03 LTS release.

Find more articles from SAS Global Enablement and Learning here.