By default, SAS Logon Manager uses a registered client_id and client_secret to authenticate itself to your Microsoft Entra ID Tenant. SAS Logon Manager must authenticate to exchange the Authorization Code for an ID Token when using OpenID Connect authentication with Entra ID. Microsoft refers to this as client_secret in their documentation. With SAS Viya 2024.03 SAS Viya now also supports the use of private_key_jwt for the authentication of SAS Logon Manager to Microsoft Entra ID. In this post we’ll look at why you might want to use private_key_jwt and how you can configure this. Why use private_key_jwt   The Microsoft documentation states:   SOMETIMES CALLED A PUBLIC KEY, A CERTIFICATE IS THE RECOMMENDED CREDENTIAL TYPE BECAUSE THEY'RE CONSIDERED MORE SECURE THAN CLIENT SECRETS.   The same documentation also states:   CLIENT SECRETS ARE CONSIDERED LESS SECURE THAN CERTIFICATE CREDENTIALS. APPLICATION DEVELOPERS SOMETIMES USE CLIENT SECRETS DURING LOCAL APP DEVELOPMENT BECAUSE OF THEIR EASE OF USE. HOWEVER, YOU SHOULD USE CERTIFICATE CREDENTIALS FOR ANY OF YOUR APPLICATIONS THAT ARE RUNNING IN PRODUCTION.   Further details are available in the Microsoft Security Best Practices for App Registration.   Private Key JWT is a method of client authentication where the client creates and signs a JWT using its own private key. This method is described in a combination of RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile for Client Authentication), and referenced by OpenID Connect and FAPI 2.0 Security Profile.   Using private_key_jwt means that no secret is shared between SAS Logon Manager and Entra ID. The private_key_jwt mechanism is based on asymmetric cryptography rather than symmetric cryptography which offers stronger algorithms. Also, the use of private_key_jwt is a requirement for the Open Banking APIs under the Financial Grade API (FAPI).   So, we can see you might want to move to using private_key_jwt instead of client_secret; either because of regulatory requirements, or generally because you want to improve the security of the OIDC implementation you are using.   Configuring private_key_jwt   The SAS documentation covers the steps to configure JWT Client Authentication with Microsoft Entra ID. You will need to complete steps in both SAS Viya and your Entra ID tenant.   SAS Viya 2024.01 introduced an update to the sas.logon.oauth.providers configuration. This update is the addition of the property jwtclientAuthentication. The jwtclientAuthentication property has the description: "Use OIDC private key JSON web tokens (JWTs) for client authentication. The public key must be registered with the provider. Only effective if relyingPartySecret is not set." This is a Boolean property so can either be turned on or turned off, the default value is false or turned off.   Therefore, if we want to use private_key_jwt with Microsoft Entra ID we must change both jwtclientAuthentication and relyingPartySecret. The property jwtclientAuthentication must be turned on or set to true. At the same time the value of relyingPartySecret must be removed or set to the empty string. Then we need to consider how to register the public key with our Microsoft Entra ID tenant.   SAS Logon Manager automatically generates a public/private key pair that is used to sign the JSON Web Tokens that are provided to the SAS Viya web applications and other clients of SAS Logon Manager. The public key is then made available to consumers by SAS Logon Manager at its jwks_uri endpoint. However, the public key part is not wrapped inside an X509 certificate object. Microsoft Entra ID will only accept the public key when it is wrapped inside an X509 certificate. The changes introduced with SAS Viya 2024.03 allow us to replace the existing public/private key pair with a private key and associated X509 certificate containing the public key.   One major advantage of using a X509 certificate to hold the public key is that this has a built-in expiry, ensuring that you regularly rotate the credential used by SAS Logon Manager to authenticate to Microsoft Entra ID. Microsoft recommends using a X509 certificate signed by a public Certificate Authority for applications deployed to production. However, you can use self-signed X509 certificates, but Microsoft recommends these are only used for testing. Microsoft even provides documentation for creating a self-signed public certificate to authenticate your application which uses PowerShell to create the private key and self-signed certificate. Alternatively, you could use OpenSSL to do the same thing. For example, the following commands will create a private key and self-signed certificate:   mkdir -p ~/OIDC_Certs openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \ -subj "/ST=SelfSigned/CN=SASLogonSigningKey" \ -keyout ~/OIDC_Certs/SASLogonSigning.key \ -out ~/OIDC_Certs/SASLogonSigning.cert openssl rsa -in ~/OIDC_Certs/SASLogonSigning.key -out ~/OIDC_Certs/SASLogonSigningRSA.key   The resulting private key (~/OIDC_Certs/SASLogonSigningRSA.key) and X509 Certificate (~/OIDC_Certs/SASLogonSigning.cert) need to be provided to SAS Logon Manager. This is provided in the sas.logon.jwt configuration, you could use SAS Environment Manager or the SAS Viya CLI to add this configuration. For example, the following commands will create a JSON configuration file with the required contents and apply this with the SAS Viya CLI:   # Clean up files for use in JSON configuration sed -E ':a;N;$!ba;s/\r{0,1}\n/\\n/g' ~/OIDC_Certs/SASLogonSigningRSA.key > ~/OIDC_Certs/JSON.key sed -E ':a;N;$!ba;s/\r{0,1}\n/\\n/g' ~/OIDC_Certs/SASLogonSigning.cert > ~/OIDC_Certs/JSON.crt # Find the correct URL for SAS Logon Manager NS=name-of-namespace ;\ logon_host=`kubectl -n ${NS} get ing sas-logon-app -o=jsonpath='{.spec.tls[0].hosts[0]}'` ;\ # Create JSON Configuration mkdir -p ~/JSON tee ~/JSON/OIDCSigning.json > /dev/null << EOF { "name": "addOIDCSigning", "items": [ { "version": 1, "metadata": { "allowUserProperties": true, "isDefault": false, "mediaType": "application/vnd.sas.configuration.config.sas.logon.jwt+json;version=7" }, "signingKey": "$(<~/OIDC_Certs/JSON.key)", "signingCert": "$(<~/OIDC_Certs/JSON.crt)", "issuer.uri": "https://${logon_host}/SASLogon" } ] } EOF # Use SAS Viya CLI to apply configuration /opt/sas/viya/home/bin/sas-viya auth login;\ /opt/sas/viya/home/bin/sas-viya configuration configurations create \ --file ~/project/deploy/gelenv/site-config/JSON/OIDCSigning.json; \ /opt/sas/viya/home/bin/sas-viya auth logout   SAS Logon Manager will now use this private key to sign all JSON Web Tokens that are generated. This means the JSON Web Token (JWT) used to authenticate to Microsoft Entra ID as well as all JWTs used within the SAS Viya environment. For the other SAS Viya web applications and services to be able to use these JWTs they must be able to validate the signature. The SAS Viya web applications and services will retrieve the public key they use to validate the signature automatically on start-up. As such, since you have just changed the public/private key pair you must now restart the SAS Viya environment. You can use the sas-stop-all and sas-start-all CronJobs in order to restart all services.   Remember you will need to repeat these steps in the future when you need to rotate the private key and X509 certificate, when the certificate expires.   Once SAS Logon Manager is configured and all services have restarted you can add the certificate to your Microsoft Entra ID App Registration. This is covered in the SAS documentation and Microsoft documentation. You will need to complete the following steps:   Log in to the Azure portal. On the Home page, click Microsoft Entra ID from the list of Azure services. In the Entra ID interface, click App registrations in the left pane. In the list of Owned applications, select your SAS Viya application. In the left pane, click Certificates & secrets. Click the Certificates tab. Click Upload certificate to configure a new certificate. In the Upload certificate window, click the Browse button to locate the CER, PEM, or CRT file on your hard drive. Note: Microsoft requires a Base64-encoded X509 certificate based on private/public keys. Specify a Description to identify the certificate. Click Add.   The Thumbprint, start date, expiration date, and Certificate ID will be generated and the resulting screen in the Azure portal should 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.   Validating New Signing Private/Public Key   Once your SAS Viya environment is up and running you can validate that the new private/public key pair are being used to sign the JSON Web Tokens used inside the environment. First, we’ll examine the JSON Web Key Set (JWKS) endpoint for SAS Logon Manager to ensure the new public key information is present. We can just use CURL to return the contents of the JWKS endpoint:   curl -s https://${logon_host}/SASLogon/token_keys |jq -r   We expect to see something like the following:   { "keys": [ { "kty": "RSA", "x5t#S256": "mo9hdOWsjOUdDJab1lddtOcX_P8e4ZHXXeKckLgtAS4", "e": "AQAB", "use": "sig", "x5t": "JkZEK5rFR2YMem2aXgFvwiA23dk", "kid": "legacy-token-key", "x5c": [ "MIIFNzCCAx +gAwIBAgIJAMIS0J74K19eMA0GCSqGSIb3DQEBCw...aeS28iTpRhJfPaQ==" ], "alg": "RS256", "value": "-----BEGIN PUBLIC KEY-----\nMIICIjANBg...AwEAAQ==\n-----END PUBLIC KEY-----", "n": "r0t4gcdw2...MmzvLp6xgQ7TiwAcKSc " } ] }   The important parts of this output are:   x5c which is the X509 public key certificate x5t which is the base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate x5t#S256 which is the base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate   If these fields are included in the output, then our new public key wrapped in a X509 certificate is being used.   Second, we can inspect a token generated by SAS Logon Manager. The easiest way to validate this is to complete the following:   Log into SAS Studio and launch a SAS Compute Server Run the following code to display the current SAS_SERVICES_TOKEN: %put %sysget(SAS_SERVICES_TOKEN);   In the SAS log the current value of the SAS_SERVICES_TOKEN will be displayed and can be copied Use https://jwt.io to inspect the contents of the SAS_SERVICES_TOKEN In the Verify Signature section paste the X509 Certificate and corresponding private key contents You should see the following to show the signature has been successfully validated:   Conclusion   The introduction of support for using private_key_jwt as the client authentication mechanism for OpenID Connect configuration strengthens the security of the OIDC configuration. It also allows for support of the Open Banking APIs under the Financial Grade API (FAPI). With SAS Viya 2024.01 Stable release support for private_key_jwt was introduced with OKTA; the 2024.03 release has added support with Microsoft Entra ID. The support for Microsoft Entra ID depends upon the ability to specify a X509 certificate to contain the public key used by SAS Logon Manager.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

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:   Choose Microsoft Entra ID from the list of Azure services. Navigate to App Registrations and select the App registration that you are using for SAS Viya. Select API permissions, and then click the + button to add a permission. Search for Azure Key Vault. 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:   Only a secret object is supported. 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. The value will be the password of the credential set. The content type must be password. A tag must be added, where: The Tag Name must be userId. 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:   For keyVault, specify the URL to the Azure Key Vault. 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. ... View more

By default, SAS Logon Manager uses a registered client_id and client_secret to authenticate itself to your OKTA organization. SAS Logon Manager must authenticate to exchange the Authorization Code for an ID Token when using OpenID Connect authentication with OKTA. OKTA refers to this as client_secret_basic in their documentation. With SAS Viya 2024.01 SAS Viya now also supports the use of private_key_jwt for the authentication of SAS Logon Manager to OKTA. In this post we’ll look at why you might want to use private_key_jwt and how you can configure this.   Why use private_key_jwt   The OKTA developer documentation states:   private_key_jwt: Use this when you want maximum security. This method is more complex and requires a server, so it can't be used with public clients.   Private Key JWT is a method of client authentication where the client creates and signs a JWT using its own private key. This method is described in a combination of RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile for Client Authentication), and referenced by OpenID Connect and FAPI 2.0 Security Profile.   Using private_key_jwt means that no secret is shared between SAS Logon Manager and OKTA. The private_key_jwt mechanism is based on asymmetric cryptography rather than symmetric cryptography which offers stronger algorithms. Also, the use of private_key_jwt is a requirement for the Open Banking APIs under the Financial Grade API (FAPI).   So, we can see you might want to move to using private_key_jwt instead of client_secret; either because of regulatory requirements, or generally because you want to improve the security of the OIDC implementation you are using.   Configuring private_key_jwt   The SAS documentation covers the steps to configure JWT Client Authentication with OKTA. You will need to complete steps in both SAS Viya and your OKTA tenant.   SAS Viya 2024.01 introduces an update to the sas.logon.oauth.providers configuration. This update is the addition of the property jwtclientAuthentication. The jwtclientAuthentication property has the description: "Use OIDC private key JSON web tokens (JWTs) for client authentication. The public key must be registered with the provider. Only effective if relyingPartySecret is not set." This is a Boolean property so can either be turned on or turned off, the default value is false or turned off.   Therefore, if we want to use private_key_jwt with OKTA we must change both jwtclientAuthentication and relyingPartySecret. The property jwtclientAuthentication must be turned on or set to true. At the same time the value of relyingPartySecret must be removed or set to the empty string. Then we need to consider how to register the public key with OKTA.   SAS Logon Manager automatically generates a public/private key pair that is used to sign the JSON Web Tokens that are provided to the SAS Viya web applications and other clients of SAS Logon Manager. The public key is then made available to consumers by SAS Logon Manager at its jwks_uri endpoint. You can find the URI by examining the OpenID Connect information published by SAS Logon Manager at the URL: https:///SASLogon/.well-known/openid-configuration. The jwks_uri should have the form: https:///SASLogon/token_keys. If you open this URI in a browser, you should see something like the following:   { "keys": [ { "kty": "RSA", "e": "AQAB", "use": "sig", "kid": "legacy-token-key", "alg": "RS256", "value": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMI...\n-----END PUBLIC KEY-----", "n": "u3SsR7nTv...TTw" } ] }   By default, SAS Logon Manager will provide the single public key associated with the private key that it is using to sign JSON Web Tokens. In the JSON output from the jwks_uri everything between the second set of curly braces is the public key definition. In our example above that is from line 3 to line 11.   Once SAS Logon Manager is configured and you have retrieved the public key information you can configure OKTA. As per the SAS documentation you need to:   Log in to the Okta Administration Console and click Applications. Select the SAS Viya OIDC application. Disable client_secret_basic. In the Client Credentials section, select Public key / Private key for the Client authentication method. In the Public Keys section, select Save keys in Okta. In the Public Keys section, click Add key. The Add a public key window is displayed. Paste the public key into the field provided, and click Done. Click Save.   Remember, the public key is the entire information inside the keys object in the JSON output from the SAS Logon Manager jwks_uri. For our example this is:   { "kty": "RSA", "e": "AQAB", "use": "sig", "kid": "legacy-token-key", "alg": "RS256", "value": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMI...\n-----END PUBLIC KEY-----", "n": "u3SsR7nTv...TTw" }   You’ll be able to see that OKTA has processes the contents correctly since it will be able to pick-up the Key ID "legacy-token-key" and this will be displayed as the KID attribute in the OKTA Administration Console. Also, the created date should reflect the date when you saved the configuration. This should 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.   Conclusion   The introduction of support for using private_key_jwt as the client authentication mechanism for OpenID Connect configuration strengthens the security of the OIDC configuration. It also allows for support of the Open Banking APIs under the Financial Grade API (FAPI). With SAS Viya 2024.01 Stable release support for private_key_jwt is introduced with OKTA; the 2024.03 release will introduce support with Microsoft Entra ID.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

  SAS is working in partnership with Microsoft to improve the customer experience around different areas of the configuration of SAS Viya. In December 2023 a notable result of this was the publishing of a Microsoft Entra Gallery application for the configuration of SAML authentication with SAS Viya. In this post we’ll look at the new Microsoft Entra Gallery application and see how it can be used.   Using the Azure Portal   The configuration of SAS Viya to use Microsoft Entra ID as the SAML Identity Provider is covered in the SAS Viya Platform Administration guide. Microsoft has some high-level documentation, but far more detail is provided in the SAS documentation. Prior to December 2023 you would need to add a non-gallery application when configuring Microsoft Entra ID as the SAML Identity Provider. Now when you add the Enterprise Application you can search for SAS Viya in the gallery. This will return 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.     When you select this the following options for creating an instance of the Microsoft Entra Gallery application will be shown:       You just need to provide a name for your instance of the Microsoft Entra Gallery application and then you can create it.   Once the application instance is created. Under the Enterprise Application, select Set up Single Sign-On with SAML to proceed with providing the details of your SAS Viya environment. In the Basic SAML Configuration section shown here:     You need to provide:   Identifier (Entity ID) – notice that using the Microsoft Entra Gallery application means that the SAS Viya default value is already populated, but this can be changed to something meaningful for your environment. Reply URL (Assertion Consumer Service URL) – this is the URL to your SAS Viya environment and the Patterns provides an example of what that should look like. It includes the Entity ID at the end of the URL.   You can provide:   Relay State – this will be the relative URL to any SAS application, for example /SASDrive/, and will be used in the Identity-Provider Initiated SAML Authentication Flow. Logout URL – this will enable you to have single logoff.   You can then continue with the rest of the configuration as per the SAS documentation.   Using the Azure CLI   The same steps we have discussed doing in the Azure Portal can also be done using the Azure CLI. To be able to add an instance of an application from the Microsoft Entra application gallery into your directory you need to know the globally unique applicationTemplate-id . You can find the applicationTemplate-id using the Microsoft Graph explorer and searching for SAS Viya. For example, the  URL:       https://graph.microsoft.com/v1.0/applicationTemplates?$filter=contains%28displayName%2C%27SAS%20Viya%27%2   will return details of the SAS Viya Microsoft Entra Gallery application template.   Then as per the Microsoft documentation we can instantiate an instance. The following, Linux-based, example code will create the Enterprise Application in our tenant:   myAppReg=$(az rest --method post --url https://graph.microsoft.com/v1.0/applicationTemplates/$myAppTemplateId/instantiate \ --body "{\"displayName\": \"${myDisplayName}\"}") ;\ myAppId=$(echo ${myAppReg}|jq -r '."application"."appId"') ;\ myId=$(echo ${myAppReg}|jq -r '."application"."id"') ;\ mySPId=$(echo ${myAppReg}|jq -r '."servicePrincipal"."id"') ;\ while [ "$(az ad sp list --display-name ${myDisplayName} --query '[].id' -o tsv|wc -l)" -lt "1" ]; do echo "Waiting for Service Principal to be created...";done ;\ az rest --method patch --url https://graph.microsoft.com/v1.0/servicePrincipals/${mySPId} --body "{\"preferredSingleSignOnMode\": \"saml\"}"   Within this example code, we need to provide the $myAppTemplateId which we found earlier from Microsoft Graph Explorer. Also, we provide ${myDisplayName} as the custom name of the instance of the Microsoft Entra Gallery application.   The last part of this code will also enable SAML as the mechanism for Single Sign-on. This is the action we performed in the Azure Portal by selecting Set up Single Sign-On with SAML.   However, when using the Azure CLI, it does not setup a token signing certificate automatically. Instead, we can use the following code to do that:   myExp=$(date -d "+3 years" +%FT%TZ) myCert=$(az rest --method post --uri https://graph.microsoft.com/v1.0/servicePrincipals/${mySPId}/addTokenSigningCertificate \ --body "{\"displayName\":\"CN=SASViya\",\"endDateTime\":\"${myExp}\"}") ;\ myThumbPrint=$(echo ${myCert}|jq -r '."thumbprint"') ;\ az rest --method patch --uri https://graph.microsoft.com/v1.0/servicePrincipals/${mySPId} \ --body "{\"preferredTokenSigningKeyThumbprint\": \"${myThumbPrint}\"}"   Finally, we can use the following code to set the SAS Viya specific values in the Basic SAML Configuration:   az rest --method patch --uri https://graph.microsoft.com/v1.0/applications/${myId} \ --body "{\"web\": {\"redirectUris\": [\"https://${logon_host}/SASLogon/saml/SSO/alias/${myEntityID}\"],\ \"logoutUrl\": \"https://${logon_host}/SASLogon/saml/SingleLogout/alias/${myEntityID}\"},\ \"identifierUris\": [\"https://${myEntityID}\"]}"   Where ${logon_host} is the hostname of our SAS Viya instance and ${myEntityID} is the Entity ID used in the SAS Viya configuration. Optionally, use the following Azure CLI command to remove the requirement for users/groups to be assigned to the Enterprise Application before they can use it:   az rest --method patch --uri https://graph.microsoft.com/v1.0/servicePrincipals/${mySPId} \ --body "{\"appRoleAssignmentRequired\": false}"   The Future   The current SAS Viya SSO Microsoft Entra Gallery application allows you to configure SAML, but it does not support SCIM provisioning. Work is underway with Microsoft to add support for SCIM provisioning to this Microsoft Entra Gallery application. This means you could use this new single Microsoft Entra Gallery application to configure both SAML and SCIM provisioning. Or you could use the new Microsoft Entra Gallery application to configure just SCIM provisioning and separately configure OpenID Connect authentication using Microsoft Entra ID.   What About OIDC   To configure SAS Viya with OpenID Connect authentication using Microsoft Entra ID you do not add an Enterprise Application, instead you use the regular App Registrations. This means that you do not need a Microsoft Entra Gallery application for the configuration of OpenID Connect. Remember, OpenID Connect with Microsoft Entra ID also provides out-bound Single Sign-On to other Microsoft Entra ID secured resources, which is not available when using SAML with Microsoft Entra ID.   Conclusion   The SAS documentation provides you with clear instructions on how to configure SAS Viya for SAML with Microsoft Entra ID. However, in this blog we’ve just taken a closer look at the Microsoft Entra Gallery Application and seen how using it can make it easier for you to configure SAML authentication.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

SAS Viya 2023.08 Stable release introduced an alternative to configuring System Services Security Daemon (SSSD) with Kerberos authentication to Hadoop. Kerberos authentication to Hadoop depends on Java to make the Kerberos authentication connection. The Java libraries validate the ownership of the Kerberos ticket cache, which means that the operating system of the pod needs to recognize the UID of the end-user attempting the connection. Prior to the SAS Viya 2023.08 release, this meant you had to configure SSSD for the SAS Servers and SAS Cloud Analytic Services pods. Now with SAS Viya 2023.08 and later it is possible to instead use a Name Server Switch (NSS) Wrapper to provide the user information. In this post we will examine how this can be configured and how it operates. Concerns with SSSD   Leveraging System Services Security Daemon (SSSD) to provide user information lookup to SAS Servers and SAS Cloud Analytic Services requires running SSSD in a privilege elevated container. Running in an elevated container is against a number of recommendations for securing Kubernetes environments, such as the Cybersecurity and Infrastructure Security Agency’s Kubernetes Hardening Guidance. In addition, providing a SSSD configuration or allowing the SAS pods to generate the SSSD configuration further distributes credentials which are valid outside the Kubernetes environment. The SSSD configuration containing credentials to bind to the LDAP provider will end-up in a Kubernetes secret.   These items make configuring SSSD less than ideal. Instead, using a NSS Wrapper does not require a privilege elevated container, nor does it require any external credentials.   Configuring NSS Wrapper   The configuration of NSS Wrapper is very straightforward since you are essentially only turning on the feature. As described in the documentation, you just need to add a reference to the nss_wrapper in the transformers block of the kustomization.yaml. The reference to the nss_wrapper must come before the sas-bases/overlays/required/transformers.yaml reference. It would look like the following:   transformers: ... - sas-bases/overlays/kerberos/nss_wrapper/add-nss-wrapper-transformer.yaml - sas-bases/overlays/required/transformers.yaml   You then need to rebuild your site.yaml and reapply the updated site.yaml.   How NSS Wrapper Operates   The NSS Wrapper operates by using the internal SAS Logon Manager token to provide the userid. It then creates a temporary passwd type entry for the userid, uid, and gid with the following format:   <userid>:x:<uid>:<gid>:<userid>:/:/bin/false   Remember: the uid and gid values are already fetched from the Identities microservice when launching the process.   It sets two environment variables: NSS_WRAPPER_PASSWD pointing to the temporary file, and NSS_WRAPPER_GROUP pointing to /etc/group. It then leverages an environment variable LD_PRELOAD, which points to the libnss_wrapper.so shared library. More details on the libnss_wrapper.so shared library can be found here: https://cwrap.org/nss_wrapper.html. With nss_wrapper it is possible to define your own passwd and group files to be used, which means that NSS will correctly identify the user when called by the Java Hadoop client. This means the SAS containers do not need any extra privileges, to directly interact with the /etc/passwd file inside the container. Also, there is no need to configure SSSD to sit behind NSS and run SSSD in a privilege escalated container.   Validating NSS Wrapper   The functioning of the nss_wrapper is driven by the presence of an environment variable, hence why configuring the nss_wrapper is so easy. The environment variable is injected into the following containers when we add the reference to the nss_wrapper in the transformers block of the kustomization.yaml:   SAS Compute SAS Launcher SAS/Connect SAS Batch SAS Cloud Analytic Services   This means the first and easiest way to check the nss_wrapper has been configured is to look for the environment variable. With access to kubectl we can use the following command to check for the environment variable in the SAS Cloud Analytic Services controller pod:   kubectl -n ${NS} exec -it sas-cas-server-default-controller -c sas-cas-server -- env |grep SAS_POD_USES_NSS_WRAPPER   You should see something like the following:   SAS_POD_USES_NSS_WRAPPER=true   This shows that the environment variable has been set.   Then if you want to check the processing of the nss_wrapper we can complete the following, once we have launched a SAS Compute Server pod, perhaps by logging into SAS Studio.   Use the following command to look at the details of the SAS Compute Server pod that has been launched by SAS Studio:   myPod=`kubectl -n ${NS} get pods -l launcher.sas.com/username=gatedemo001 -o name|cut -c 5-`; \ kubectl -n ${NS} describe pod ${myPod}|grep -E 'owner|username'   You should see something like the following:   sas.com/owner: 463452355 launcher.sas.com/username=gatedemo001 sas.com/ownerGroup: 463452355   Use the following commands to validate the processing of the NSS Wrapper:   kubectl -n ${NS} exec -it ${myPod} -c sas-programming-environment -- id; \ kubectl -n ${NS} exec -it ${myPod} -c sas-programming-environment -- /bin/bash -c 'cat /tmp/tmp*'; \ kubectl -n ${NS} exec -it ${myPod} -c sas-programming-environment -- /bin/bash -c 'export NSS_WRAPPER_PASSWD=$(find /tmp -name tmp.*) && export NSS_WRAPPER_GROUP="/etc/group" && export LD_PRELOAD=/usr/lib64/libnss_wrapper.so && id'   You should see something like the following:   uid=463452355 gid=463452355 groups=463452355,1870626142 gatedemo001:x:463452355:463452355:gatedemo001:/:/bin/false uid=463452355(gatedemo001) gid=463452355 groups=463452355,1870626142   The first id command shows that the operating system inside the pod does not recognize the user. The second command reads the content of the temporary file created for the NSS Wrapper using information from the users internal SAS Logon Manager token and information from the SAS Identities microservice. The third command then leverages the NSS Wrapper before running the id command, this illustrates that now the user is recognized.   Conclusion   With this change in the SAS Viya Stable 2023.08 release, it is now easier and more secure to complete the additional configuration required for using Kerberos to authenticate to Hadoop. The configuration of SAS Viya no-longer requires additional SSSD configuration and running privilege escalated pods.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

The SAS Viya 2023.07 release introduces a minor change to the processing of OpenID Connect (OIDC) logout operations. Logging out from the OIDC Provider when logging out from SAS Viya or any Relying Party is not part of the Core specification of OpenID Connect. However, it is defined in a complimentary specification OpenID Connect RP-Initiated Logout 1.0 which is implemented by some OIDC Providers. For example, Azure Active Directory does implement this additional specification. With the SAS Viya Stable release 2023.07, SAS Viya has also introduced support for this feature. In this article we will examine how this is implemented with SAS Logon Manager.   SAS Logon Manager Implementation   With the SAS Viya Stable release 2023.07 an additional property has been added to the sas.logon.oauth.providers configuration. The additional property logoutUrl specifies the URL to which SAS Viya should perform a redirect to request that the End-User be logged out at the provider. SAS Logon Manager will use the value in the logoutUrl property if it is defined. In SAS Environment Manager the new logoutUrl property of the sas.logon.oauth.providers configuration looks like the following:   Select any image to see a larger version. Mobile users: If you do not see this image, scroll to the bottom of the page and select the "Full" version of this post.   However, if SAS Logon Manager has been provided with the discoveryUrl property it is also able to automatically find the logoutUrl value from the OIDC configuration obtained from the OIDC Provider. As per the specification SAS Logon Manager looks for the end_session_endpoint attribute in the ODIC Provider Discovery Metadata. If this exists, then you do not need to set a value for the logoutUrl property of sas.logon.oauth.providers. Remember the discoveryUrl property is not required for the OIDC configuration of SAS Logon Manager but can be used to simplify the configuration by enabling SAS Logon Manager to look up attributes from the OIDC Provider.   For example, if you are using Azure Active Directory as your ODIC Provider, we can view a sample ODIC Provider Discovery Metadata at: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. This presents the following sample metadata about the OIDC Provider:   { "token_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/token", "token_endpoint_auth_methods_supported": [ "client_secret_post", "private_key_jwt", "client_secret_basic" ], "jwks_uri": "https://login.microsoftonline.com/common/discovery/v2.0/keys", ... ... "end_session_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/logout", ... ... }   We have abbreviated the output to highlight the inclusion of the end_session_endpoint attribute. Therefore, when configuring Azure Active Directory as the OIDC Provider if you define the discoveryUrl property of sas.logon.oauth.providers to point to your Azure Active Directory tenant specific URL: https://login.microsoftonline.com/{tenantid}/v2.0/.well-known/openid-configuration; then you will benefit from the new logout behaviour leveraging your Azure Active Directory tenant specific end_session_endpoint: https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/logout. SAS Logon Manager will redirect to Azure Active Directory for logout, and user will be prompted to logout of Azure Active Directory as shown here:     More details on how Azure Active Directory implements the logout functionality can be found here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#single-sign-out.   Equally, if you are using OKTA as your OIDC Provider for SAS Logon Manager and use the discoveryUrl setting you can automatically use the new logout behaviour. OKTA also provides an end_session_endpoint attribute as part of the OIDC Provider Discovery Metadata, as documented here: https://developer.okta.com/docs/reference/api/oidc/#well-known-openid-configuration. The process used when redirecting the user’s browser to the end_session_endpoint for OKTA is documented here: https://developer.okta.com/docs/reference/api/oidc/#logout.   However, not all OIDC Providers will implement the complimentary specification OpenID Connect RP-Initiated Logout 1.0. For example, PingFederate Server does not implement the end_session_endpoint as part of the ODIC Provider Discovery Metadata. Reviewing the documentation for PingFederate shows that instead it implements its own form of single logout.   Preventing Logout from OIDC Provider   If your chosen OIDC Provider does implement the complimentary specification OpenID Connect RP-Initiated Logout 1.0 but you do not want to have SAS Logon Manager trigger a logout from the OIDC Provider you can prevent this. In this case you would ensure both the logoutUrl and discoveryUrl are not set or left blank for the sas.logon.oauth.providers configuration. You then need to ensure that you correctly set the properties issuer, tokenKey, or tokenKeyUrl for the sas.logon.oauth.providers configuration, since these properties can no-longer be obtained from the ODIC Provider Discovery Metadata. Then because SAS Logon Manager is not provided with the logoutUrl and is unable to lookup up the end_session_endpoint the logout from the OIDC Provider will not occur. When user’s logout from SAS Viya their sessions will be maintained with the OIDC Provider, and they can seamlessly log back into SAS Viya without any prompting from the OIDC Provider.   Comparison with Previous Releases   In previous releases of SAS Viya, it was still possible to trigger logout from the OIDC Provider when logging out from SAS Viya. But this relied upon the custom sign-out and custom time-out content. Customizing the sign-out and session time-out content is covered in the SAS Viya Platform Administration Guide. A custom page could be loaded containing the required JavaScript to trigger the logout from the OIDC Provider. Or the end-session endpoint on the ODIC Provider could be loaded itself within the iframe if content security settings for both SAS Logon Manager and the ODIC Provider allow this content to be displayed in an iframe. For example, with Azure Active Directory as the OIDC Provider we can configure the custom sign-out to directly call Azure Active Directory. This results in an Azure Active Directory page being displayed in the iframe as shown here:     Conclusion   As we have illustrated above the new logout behaviour for SAS Logon Manager with a supporting OIDC Provider is much easier to implement than in previous releases. In many cases with a supporting ODIC Provider, it will be automatically configured for you without any additional steps. Equally, if you do not wish to implement the logout from the OIDC Provider when logging out from SAS Viya this is easy to achieve as well.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

SAS Viya Stable release 2023.07 makes a significant change to how the authentication of scheduled jobs and job flows operates when they are configured to run as a specific user. This change requires anyone updating their SAS Viya environment to the 2023.07 or later release to make updates to any existing scheduled jobs and flows that make use of the Run As feature. In this blog we will present the changes that are introduced in SAS Viya 2023.07 and discuss what you need to do when updating to this release or a later one.   Since the SAS Viya 2023.11 release the security posture of SAS Viya has been improved with respect to how Access Tokens are leveraged internally. These Access Tokens are now more closely coupled with the specific application or service that obtains them. As such, from this release it is no-longer possible to use a scheduled job to refresh the Group-Managed Service Account credential.   The New Model   We will start by presenting the new model for how scheduling using the Run As feature is undertaken in SAS Viya 2023.07. A scheduling job can now be defined by a user who does not need to be a member of SAS Administrators to run as another user. However, the jobs and flows can only be run as a group-managed service account, rather than any user who has logged into the SAS Viya environment. A group-managed service account does not have any special privileges or unique features other than it enables a group of users to share responsibility for jobs and job flows. The users who share the responsibility for executing, scheduling, and monitoring jobs and job flows are associated with the group-managed service account by being given access to the Token Authentication Domain created by the group-managed service account.   The following diagram illustrates the parts that make up the new model:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   A member of the SAS Administrators group needs to setup the following:   Adds the group-managed service account, that must exist in the external Identity Provider, to the automatically created Service Account Users for Schedule custom group. Creates a new custom group and adds the end-users who share the responsibility for executing, scheduling, and monitoring jobs and job flows to the group.   A user with access to the credentials for the group-managed service account needs to do the following to prepare the group-managed service account for use:   Creates a new Token Authentication Domain. This Token Authentication Domain will be used to store the credentials for the group-managed service account. This needs to be created by the group-managed service account to ensure that account can update the credential in future. With SAS Viya 2023.07 the SAS Viya CLI should be used to create the Token Authentication Domain. From SAS Viya 2023.08 and later either the SAS Viya CLI or SAS Environment Manager can be used to create the Token Authentication Domain. Store a credential for the group-managed service account in the new Token Authentication Domain and allow access to this credential by the custom group containing the users who will schedule jobs and flows as the group-managed service account. To work with the Jobs and Flows feature, the Restrict applications check box must be selected when adding the credential. This task must be completed in SAS Environment Manager as the group-managed service account.   This last step completed as the group-managed service account, is essentially authorizing the members of the custom group to run jobs and flows as the group-managed service account.   With this complete the members of the custom group can now schedule jobs and flows using the group-managed service account. Details of these steps are covered in the SAS Viya Platform Administration documentation.   Authorization Rules Underpinning the New Model   The Service Account Users for Schedule custom group is created automatically and includes a series of pre-defined authorization rules. Just as with the custom group itself, these authorization rules are automatically defined in the SAS Viya 2023.07 environment. The following four authorization rules are automatically created:     The rules for the Object URIs "/credentials/domains/*/*/*" and "/SASEnvironmentManager/domains" are straight-forward grants of the given permissions. The first allowing the group-managed service account to read, create, update, and delete credentials. Then the second allowing the group-managed service account to access the domains section from within SAS Environment Manager.   The other two authorization rules have conditional grants applied. The first of these for the Object URI "/credentials/domains/*" allow the group-managed service account to create, update, and delete the Token Authentication domains that they have created. Where the condition is:   (currentUser() == #domain?.createdBy) OR (#domain != null AND #domain?.creationTimeStamp == null)   Which means that the permissions of delete, and update are only applied to domains where the user has created the domain, or where the domain does not exist yet. Then for the Object URI "/credentials/domains/*/credentials" the rule will allow the group-managed service account to list the credentials in the domain they have created. Where the condition is:   currentUser() == #domain?.createdBy   It is these four authorization rules applied to the Service Account Users for Schedule custom group that enable the group-managed service account to store a credential and make this credential available to others.   In addition, the Credentials microservice only allows access to the stored secret for the assigned Identity, in this case the Refresh Token. As we described above the assigned Identity in the case of the group-managed service account is the custom group the SAS Administrator has created. This custom group contains the end-users who share the responsibility for executing, scheduling, and monitoring jobs and job flows. So only members of this custom group will be able to access the stored Refresh Token.   Other Permissions   So far, we have only discussed the authorization required for the jobs and job flows to be scheduled as the group-managed service account. In addition to this, the group-managed service account will also require the authorizations and permissions to complete the tasks in the scheduled job or job flow. If the job or job flow accesses other SAS Viya services, the group-managed service account will require the authorization to interact with these services. For example, if the job will write content to the Folders microservice the group-managed service account will require authorization to the folder location. Equally, if the job or job flow will access data in a caslib, the group-managed service account will require the authorization to access the given caslib.   These authorizations and permissions for the group-managed service account may also extend beyond the SAS Viya environment to the underlying data sources whether those are file system directories or databases. For credentials needed to access the databases, these can be stored in an Authentication Domain and only the group-managed service account will require access to them. This means that you do not need to make those database credentials available to the users scheduling the job or job flow as the group-managed service account.   Example   Next, we will look at an example to hopefully make these concepts easier to apply to your own environment. Let’s say that our SAS Viya environment is shared between the Sales and HR departments. Delilah is a data administrator in the HR department and needs to be able to schedule regular jobs to process HR data. The other members of the HR department need to be able to monitor the jobs Delilah has scheduled. While Douglas is a data administrator in the Sales department, and he needs to be able to schedule jobs to process the Sales data. Again, the other members of the Sales department also need to monitor the jobs that Douglas has scheduled.   In our example organization we then create two users who will be running the scheduled jobs and flows for the two departments. We will call these users scheduler-sales and scheduler-hr. These two users must exist in our external Identity Provider, whether that is an LDAP Provider or SCIM Provider and these two users must be able to log into SAS Viya. It does not matter how the users log in; authentication could use any supported mechanism such as LDAP, OpenID Connect, or SAML.   George, a member of SAS Administrators logs into SAS Environment Manager and opts in to the SAS Administrator role. George, as a SAS Administrator, then completes the following: Adds the scheduler-sales user and scheduler-hr user to the Service Account Users for Schedule custom group. Creates a new custom group called Scheduling HR and adds Delilah and other members of the HR department as members. Creates a new custom group called Scheduling Sales and adds Douglas and other members of the Sales department as members. Delilah, knowing the credentials for the scheduler-hr account, now completes the following as the scheduler-hr user: Creates a new Token Authentication Domain called Scheduling_HR_TokenAuth If using SAS Viya 2023.07 this is performed using the SAS Viya CLI If using SAS Viya 2023.08 and later this can be performed either in SAS Environment Manager or using the SAS Viya CLI Uses SAS Environment Manager to store a new credential on the Scheduling_HR_TokenAuth domain and assigns this credential to the custom group Scheduling HR. To work with the Jobs and Flows feature, the Restrict applications check box must be selected when adding the credential. Douglas, knowing the credentials for the scheduler-sales account, now completes the following as the scheduler-sales user: Creates a new Token Authentication Domain called Scheduling_SALES_TokenAuth If using SAS Viya 2023.07 this is performed using the SAS Viya CLI If using SAS Viya 2023.08 and later this can be performed either in SAS Environment Manager or using the SAS Viya CLI Uses SAS Environment Manager to store a new credential on the Scheduling_SALES_TokenAuth domain and assigns this credential to the custom group Scheduling Sales. To work with the Jobs and Flows feature, the Restrict applications check box must be selected when adding the credential.   With this complete Delilah and Douglas can log into SAS Environment Manager as themselves and now schedule jobs and job flows as their respective group-managed service accounts. In addition, the other members of their departments will also be able to monitor the jobs the two of them have scheduled within SAS Environment Manager. However, remember the scheduler-sales and scheduler-hr users will not be able to access other SAS Viya services and data sources until they are granted the authorizations and permissions to do so.   What Happens when Upgrading to SAS Viya 2023.07 and later   When a SAS Viya platform deployment is upgraded to release 2023.07 or later, the prior Run As function is removed and the group-managed service account function becomes available. See the SAS Viya Platform Administration documentation for further details. Essentially, when your SAS Viya environment is updated to release 2023.07 or later you have the following choices:   Update the existing jobs to use the group-managed service account feature. Leave existing scheduled jobs as is.   To update the jobs, you will first need to unscheduled the existing job, then you need to configure a group-managed service account, and then the job can be rescheduled. You could complete all steps with a single account if they are both a member of SAS Administrators and a member of the custom group associated with the group-managed service account Token Authentication domain. Otherwise, a member of SAS Administrators could unscheduled the job and a different user, from our example above either Delilah or Douglas, could then reschedule the job.   If you do not want to update the scheduled job requests that use the prior Run As functionality, you have these choices:   Leave the existing scheduled job as is. Then have a member of SAS Administrators or the creator monitor the status of the scheduled job. The scheduled jobs and flows will continue to run under the original Run As user. If the schedule needs to be updated, you will need to configure a group-managed service account. Alternatively, rather than updating the scheduled job you could simply recreate the scheduled job using a group-managed service account. A member of SAS Administrators would be able to unscheduled the existing job and delete the job definition, after it has been recreated.   Refresh Token Lifetime   The Refresh Token stored by the group-managed service account will by default expire after 90 days. The Refresh Token is embedded in the schedule information and an automated process updates the embedded Refresh Token every seven days. Embedded Refresh Tokens are only replaced if they are within 45 days of their expiry. However, this process does not replace the Refresh Token stored with the Credentials microservice. You could address the expiry of the Refresh Token stored with the Credentials microservice in the following ways:   You could manually authenticate to SAS Environment Manager as the group-managed service account and edit the stored credential to replace it. You could schedule a job to run every 30 days to replace the Refresh Token stored with the Credentials microservice. You could extend the default lifetime of Refresh Tokens within the SAS Viya environment. The properties policy.refreshTokenValiditySeconds and policy.global.refreshTokenValiditySeconds under sas.logon.jwt define these lifetimes. This process is covered in the SAS Viya Platform Administration documentation.   Since the SAS Viya 2023.11 release the security posture of SAS Viya has been improved with respect to how Access Tokens are leveraged internally. These Access Tokens are now more closely coupled with the specific application or service that obtains them. As such, from this release it is no-longer possible to use a scheduled job to refresh the Group-Managed Service Account credential. The example below will only work for SAS Viya releases prior to 2023.11.   We will explore this second option here . For the group-managed service account to be able to replace the Refresh Token with the Credentials microservice inside a scheduled job it will need to be added to the custom group assigned to the stored credential. Since the Credentials microservice will only allow access to the secret (i.e. the Refresh Token) to the Identity assigned to it. You would then create a scheduled job with the following SAS code:   options set=myToken="%sysget(SAS_CLIENT_TOKEN)"; %let ViyaIngress=%sysfunc(getoption(SERVICESBASEURL)); filename resp temp; PROC HTTP url="&ViyaIngress./credentials/domains/{REPLACE_WITH_TOKEN_AUTH_DOMAIN}/secrets" method='GET' OAUTH_BEARER="%sysget(SAS_CLIENT_TOKEN)" out=resp query = ("lookupInGroup"="true" "client_id"="sas.jobExecution"); run; /* data _null_; infile resp; input; put _infile_; run; */ filename resp clear;   If you get an error running the code, you can uncomment the data step at the end of the code. This will print the entire response to the log of the scheduled job, and you can investigate the error further.   You can validate that the credential has been replaced by checking the modified date for the credential, which can be viewed by either the group-managed service account or members of SAS Administrators in SAS Environment Manager.     Other Considerations   Finally, a couple of other items to consider with the new model for the Run As feature. First, being a member of the SAS Administrators group no-longer provides the ability to use the Run As feature. A member of the SAS Administrators group is still able to view the execution history, but without being a member of one of the custom groups giving access to the group-managed service account the Run As feature cannot be used.   Second, if a user is a member of multiple custom groups providing access to different group-managed service accounts they will be able to execute, schedule, and monitor jobs and job flows for any of the group-managed service accounts. So, looking again at our example if we add the user Alex to both Scheduling HR and Scheduling Sales groups. Then Alex in SAS Environment Manager will be presented with both group-managed service accounts in the Monitoring screen. Alex will be able to select either of the group-managed service accounts in the View as property as shown here:     When Alex selects one of the group-managed service accounts, he will then be able to see the execution history for that account. Equally, Alex will be able to select either of the group-managed service accounts when using the Run As feature. However, Alex will not be able to see the job created by either Delilah or Douglas, because Alex is not a SAS Administrator, and he did not create those jobs.   If it is necessary to edit the schedule or unscheduled the jobs created by Delilah or Douglas, then either Alex must be added to SAS Administrators. Or a custom authorization rule will be required to give Alex access to the jobs created by Delilah or Douglas. In general terms you can only maintain jobs and job flows if you are a SAS Administrator, creator, or a custom authorization rule has been defined. Where maintain means; edit the schedule, unschedule, delete the job, copy the job, edit the job flow, view the job flow, and delete the job flow.   Conclusion   As we have seen the introduction of group-managed service accounts makes the Run As feature with SAS Viya 2023.07 and later more secure and much easier to securely open to a wider group of users. The technical parts might initially seem a bit confusing, but the general premise of logging into SAS Viya as the account that will run the scheduled jobs and authorizing that other specific users can use that account to run the scheduled jobs and flows makes a great deal of sense. There can be some initial effort to reschedule existing jobs when updating to SAS Viya 2023.07 and later, but the improved functionality makes this worthwhile.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

In the last post we discussed defining a custom application within SAS Viya and using the client_credentials grant type to authenticate. One of the use cases we presented in that post was connecting from SAS 9.4 to SAS Viya. I want to explore this use case in more detail in this post. As such, we will define a new custom application with SAS Logon Manager in SAS Viya and use the client_credentials grant type to obtain an Access Token. We will then use this Access Token to connect from SAS 9.4 to SAS Viya. This use case is a good fit for SAS 9.4 batch sessions that need to interact with SAS Viya when the end-user for the SAS 9.4 batch session does not exist in the Identity provider of our SAS Viya environment. Which could easily be the case when our SAS 9.4 environment is running on-premises and our SAS Viya environment is running in the cloud with more modern cloud-native Authentication and Identity providers such as OpenID Connect and SCIM.   Defining the Custom Application   To be able to register the custom application with SAS Logon Manager you need to first obtain an Access Token as a member of the SAS Administrators group. You can do this by calling the SAS Logon Manager API. Or you can obtain an Access Token using the SAS Viya CLI.   Once you have this Access Token you can register the custom application using the following call to the SAS Logon Manager API:   curl -k -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN" \ -d '{ "client_id": "cust1.app", "client_secret": "myclientsecret", "scope": ["uaa.none"], "authorities": ["CustomApps"], "authorized_grant_types": ["client_credentials"], "access_token_validity": 900 }'   Note: You should specify a complex random string as the client_secret, a simple value is shown here to make the examples easy to read.   You should see something like the following for a successful response, we have split this output onto multiple lines to make it easier to read:   {"scope":["uaa.none"], "client_id":"cust1.app", "resource_ids":["none"], "authorized_grant_types":["client_credentials"], "autoapprove":[], "access_token_validity":900, "authorities":["CustomApps"], "lastModified":1673609094057, "required_user_groups":[]}   Notice that the authorized_grant_types only include client_credentials; this means that this client will never be able to obtain an Access Token for an end-user. Since this custom application will never obtain credentials for an end-user we have also set the scope to uaa.none. In addition, for our example the access_token_validity has been set to 900, which is 10 minutes, so we will need to reauthenticate every 10 minutes. You can define the access_token_validity to whatever value makes sense for your custom application, the value is the number of seconds that the Access Token will be valid for.   When using the client_credentials grant the authorities will represent the custom group, so our custom application will be in the CustomApps custom group.   You can then refer to the previous post if you need to update or delete the custom application.   Obtaining the Access Token   You could obtain the Access Token for the custom application by directly calling the SAS Logon Manager API outside of your SAS 9.4 environment and then provide this as a file to be used by the SAS 9.4 code. For example, you could obtain the Access Token using CURL with the following:   APP_TOKEN=`curl -skX POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -u 'cust1.app:myclientsecret' \ -d 'grant_type=client_credentials' |jq -r '."access_token"'`; \ echo "Custom Application Access Token is: ${APP_TOKEN}"   You should see something like the following:   Custom Application Access Token is: eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0L1NBU0xvZ29uL3Rva2VuX2tleXMiLCJraWQiOiJsZWdhY3ktdG9rZW4ta2V5IiwidHlwIjoiSldUIn0. eyJqdGkiOiI1MWMyYWEzYTMyY2E0MTI1OGM1OTUxZGM4NmEwYzk2OSIsInN1YiI6ImN1c3QxLmFwcCIsImF1dGhvcml0aWVzIjpbIkN1c3RvbUFwcHMiXSwic2NvcGUiOlsiQ3VzdG9tQXBwcyJdLCJjbGllbnRfaWQiOiJj dXN0MS5hcHAiLCJjaWQiOiJjdXN0MS5hcHAiLCJhenAiOiJjdXN0MS5hcHAiLCJncmFudF90eXBlIjoiY2xpZW50X2NyZWRlbnRpYWxzIiwicmV2X3NpZyI6IjY3N2U2YWI0IiwiaWF0IjoxNjc0NTc4NjUwLCJleHAiOjE2 NzQ2NjUwNTAsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3QvU0FTTG9nb24vb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJhdWQiOlsiY3VzdDEuKiIsImN1c3QxLmFwcCJdfQ.ULMvGUBnQh_c3SnZCds0ePdq9le8KOcxtUZ2l S398Fkqmu7cusU46IBFenqsSNYr1OlA5Z1eZT0qaSQQLiWeYVphyXq8EQv0YwLLW0_CaQN-rlhZvf-Thg0H-AmPpL-OFU08GQ8m8g6UboO4KZPR-e17P2qKBo18Rc8QvE2B1hcf-tbod0AN5Q62MkqLBTTajmnxNep4qJ1YP 0b6RhnnoriZsxN_PMm1Wytolq4UU69t0Drmn9s4brrPECG00FNaKV3TWkuwvqzJXB352doZ2-s8NVARELmqyZb5WdzYPL_5GkHsDAlZ76Dt3JBGlvnGWtZEdO9O_2ocH7GispCwTA   Alternatively, you could obtain the Access Token inside the SAS code that will be making connections to your SAS Viya environment. This requires that you have network connectivity to the Ingress Controller for your SAS Viya environment. For example, you could create a new group in the SAS 9.4 Metadata, for example "Viya Service Users", and assign the client_id and client_secret as credentials in a new authentication domain. The SAS 9.4 Authentication Domain would be configured for Outbound only.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Then any of your SAS 9.4 users who will need to obtain an Access Token for the custom application would be added to this new group, for example "Viya Service Users".   You can then create a SAS Macro which will obtain the Access Token using the credentials from the SAS 9.4 Authentication Domain. You could place something like the following code into a file called get_custom_token.sas:   %macro get_custom_token(webauthdomain=); %global custom_token; %let ViyaIngress=%sysfunc(getoption(SERVICESBASEURL)); filename resp temp; PROC HTTP url="&ViyaIngress./SASLogon/oauth/token" in="grant_type=client_credentials" ct="application/x-www-form-urlencoded" method='POST' WEBAUTHDOMAIN="&webauthdomain" AUTH_BASIC out=resp; run; %put &=SYS_PROCHTTP_STATUS_CODE; libname auth json fileref=resp; data _null_; set auth.root; call symputx('custom_token',access_token); run; filename resp clear; %put &=custom_token; %mend;   For more information on PROC HTTP see the documentation. The PROC HTTP statement is performing a HTTP POST to SAS Logon Manager in SAS Viya using the credentials from the authentication domain in SAS 9.4. This returns the Access Token for the custom application in the JSON response which is then processed to extract the Access Token and make it available as a global variable. If the macro was placed in a directory such as /opt/sas/macros, you can make this available by using the following either in you SAS Code:   options insert=(sasautos=('/opt/sas/macros'));   Or in the sasv9_usermods.cfg:   -insert sasautos '/opt/sas/macros'   For more details on the INSERT System Option see the documentation.   Notice, that to make the code in the macro as portable as possible we have used the SERVICEBASEURL System Option. The SERVICEBASEURL System Option specifies the root URL for calls to SAS Viya Services. The SERVICEBASEURL is only valid in the SAS 9.4 configuration file, SAS invocation, or SASV9_OPTIONS environment variable (UNIX only). You cannot specify the SERVICEBASEURL System Option inside a running SAS 9.4 session. Also, the SERVICEBASEURL option can be restricted by a site administrator. For more information, see Restricted Options.   With the macro defined, the SAS 9.4 configuration file updated to include the SERVICEBASEURL and addition to the sasautos, and the group defined in the SAS 9.4 Metadata,for example "Viya Service Users"; we can then call the macro with the following:   %get_custom_token(webauthdomain=ViyaCustomClient);   So long as we have network connectivity between SAS 9.4 and the Ingress Controller for the SAS Viya environment, we should see the Access Token displayed in the SAS 9.4 log. If we want to remove showing the Access Token in the log, we will just remove the final %put statement in the macro code shown above. If there is an issue with the network connectivity the macro will run until the connection times out and the message "ERROR: Unable to connect to Web server" will be returned.   Accessing SAS Viya Services   Now that the Access Token is available to the SAS 9.4 session, this session can interact with the SAS Viya services as the custom application. For example, PROC HTTP can be used to call the SAS Viya REST APIs. Specifically, using the OAUTH_BEARER option sends the Access Token along with the HTTP call. To demonstrate this, the following code calls the Folders service and obtains the top-level links:   %let ViyaIngress=%sysfunc(getoption(SERVICESBASEURL)); filename resp temp; PROC HTTP url="&ViyaIngress./folders/folders/" method='GET' OAUTH_BEARER="&custom_token." out=resp; run; data _null_; infile resp; input; put _infile_; run; filename resp clear;   This is just a very simple example of what can be done by calling the SAS Viya services.   If you have assigned a credential in the SAS Viya DefaultAuth Authentication Domain, then the custom application will be able to launch a SAS Compute Server instance in SAS Viya. This requirement to provide a credential for launching the SAS Compute Server was discussed in the previous post. The following example code uses PROC HTTP to do the following:   Find the Compute Context ID for the SAS Studio compute context. Uses the Compute Context ID to launch a SAS Compute Server session. Submits some sample code to the SAS Compute Server session. Returns the listing for the SAS Compute Server job once it completes. Terminates the SAS Compute Server session.   %let ViyaIngress=%sysfunc(getoption(SERVICESBASEURL)); filename resp temp; PROC HTTP url="&ViyaIngress./compute/contexts?filter=eq(createdBy,'sas.studio')" ct="application/x-www-form-urlencoded" method='GET' OAUTH_BEARER="&custom_token." out=resp; run; libname output json fileref=resp; data _null_; set output.items; call symput('my_contextID',id); run; filename resp clear; libname output clear; filename resp temp; PROC HTTP url="&ViyaIngress./compute/contexts/&my_contextID/sessions" ct="application/vnd.sas.compute.session.request+json" method='POST' OAUTH_BEARER="&custom_token." in='{"version": 1,"name": "MySession","description": "This is my session for doing some simple work.","attributes": {},"environment": {"options": ["memsize=4g","fullstimer"]}}' out=resp; run; libname output json fileref=resp; data _null_; set output.root; call symput('my_ComputeSessionID',id); run; filename resp clear; libname output clear; filename resp temp; PROC HTTP url="&ViyaIngress./compute/sessions/&my_ComputeSessionID/jobs" ct="application/vnd.sas.compute.job.request+json" method='POST' OAUTH_BEARER="&custom_token." in='{"version": 2,"name": "MyOptions","description": "Getting the options for my session.", "code": ["proc print data=sashelp.class;","run;","%put &SYSUSERID;","cas mysession;", "proc cas; action listnodes result=res;print res;run;","data _null_;call sleep(10,1); run;", "cas mysession terminate;"],"attributes": {"resetLogLineNumbers": false}}' out=resp; run; libname output json fileref=resp; data _null_; set output.root; call symput('my_jobID',id); run; filename resp clear; libname output clear; filename resp temp; PROC HTTP url="&ViyaIngress./compute/sessions/&my_ComputeSessionID/jobs/&my_jobID/state?wait=60" ct="application/vnd.sas.compute.job.request+json" method='GET' OAUTH_BEARER="&custom_token." out=resp; headers "If-None-Match"="completed"; run; data _null_; infile resp; input; put _infile_; run; filename resp clear; filename resp temp; PROC HTTP url="&ViyaIngress./compute/sessions/&my_ComputeSessionID/jobs/&my_jobID/listing" ct="application/vnd.sas.compute.job.request+json" method='GET' OAUTH_BEARER="&custom_token." out=resp; run; libname output json fileref=resp; proc print data=output.items; var line; run; filename resp clear; libname output clear; filename resp temp; PROC HTTP url="&ViyaIngress./compute/sessions/&my_ComputeSessionID" ct="application/vnd.sas.compute.job.request+json" method='DELETE' OAUTH_BEARER="&custom_token." out=resp; run; filename resp clear;   This demonstrates what can be easily achieved once the Access Token is available to the SAS 9.4 session. This code sample was produced based on the examples provided at https://developer.sas.com.   Accessing SAS Cloud Analytic Services   As well as interacting with the SAS Viya services the SAS 9.4 session can use the Access Token to directly interact with SAS Cloud Analytic Services. So long as the SAS 9.4 environment is running maintenance release 5 or higher the CAS client is built into SAS 9.4. Leveraging the Access Token with the CAS client requires the following: SAS Cloud Analytic Services in SAS Viya must be configured to allow external access SAS 9.4 must have the SERVICEBASEURL system option defined which must be defined outside the session SAS 9.4 must have the SAS_VIYA_TOKEN environment variable defined which can be defined inside the session   The SAS_VIYA_TOKEN environment variable can be defined either during SAS invocation, or during the session with an OPTIONS statement. For example, using the following allows us to set the value of SAS_VIYA_TOKEN to the Access Token obtained using the macro code given above:   options set=SAS_VIYA_TOKEN="&custom_token";   The SERVICEBASEURL system option is required since the CAS client in SAS 9.4 will pre-validate the Access Token before attempting to use it. To pre-validate the Access Token the CAS client will obtain the public key from SAS Logon Manager in SAS Viya. The public key is used to validate the signature on the Access Token. If network connectivity is not correctly configured to allow SAS 9.4 to access the SERVICEBASEURL the CAS client will error and the connection to SAS Cloud Analytic Services will not be attempted. In such case, the only error will be presented in the SAS 9.4 session. There will be no error in the SAS Cloud Analytic Services logs since the connection is never attempted.   Putting all these parts together means that we can launch a CAS session using the custom application from a SAS 9.4 session with the following code:   %get_custom_token(webauthdomain=ViyaCustomClient); options set=CASCLIENTDEBUG=1; options set=CAS_AUTH_METHOD=oauth; options set=SAS_VIYA_TOKEN="&custom_token"; cas mysession host="SAS_VIYA_LOADBALANCER_HOSTNAME" port=5570 ;   Which will result in the following information in the SAS 9.4 log, since the CASCLIENTDEBUG is set to 1:   NOTE: The session MYSESSION connected successfully to Cloud Analytic Services SAS_VIYA_LOADBALANCER_HOSTNAME using port 5570. The UUID is 6939b748-9ec3-3d42-9c83-5c6ebfabc45e. The user is cust1.app and the active caslib is CASUSER(cust1.app). NOTE: The SAS option SESSREF was updated with the value MYSESSION. NOTE: The SAS macro _SESSREF_ was updated with the value MYSESSION. NOTE: The session is using 2 workers. NOTE: Forcing oauth authentication. NOTE: Client is using the oauth identity provider NOTE: Sent challenge length 968 NOTE: Received response length 57 NOTE: User cust1.app connected to CAS using OAuth 2.   This shows that we have successfully launched a SAS Cloud Analytic Services session as the custom application from the SAS 9.4 session.   Conclusion   In this post we have delved into more details on the specific use case of connecting to SAS Viya from SAS 9.4 using an Access Token for our custom client. This scenario is a good fit for SAS 9.4 batch sessions that need to interact with SAS Viya when the end-user for the SAS 9.4 batch session does not exist in the Identity provider of our SAS Viya environment. Which could easily be the case when our SAS 9.4 environment is running on-premises and our SAS Viya environment is running in the cloud with more modern cloud-native Authentication and Identity providers such as OpenID Connect and SCIM.   In the post we have presented a methodology for obtaining the Access Token without needing to set an extreme lifetime for the Access Token. Using an Authentication Domain in SAS 9.4 to hold the client_id and client_secret means that an Access Token can be obtained only by the designated users and only when necessary. This means that we do not leave an Access Token exposed for more time than it is needed. It also means that it is easier for whoever is administrating the environments to update the client_secret.   If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more

Creating a custom client or application of SAS Logon Manager is normally used to allow end-users to authenticate with the new application and perform actions. This could be a custom script or your own application you are integrating with SAS Viya. In this blog I want to explore what can be done with the custom client application of SAS Logon Manager itself. So, in this case we will be using the client_credentials grant rather than the authorization_code or password grant types. This is not the standard approach. The standard approach would be to ensure all end-users and service accounts are correctly configured in your Identity and Authentication provider. These end-user and service accounts would then be the parties that run code or processes. However, in this case it will be the custom application that runs code or process outside the context of any specific user and often (but not always) outside of any user request.   A Reminder: Grant Types   SAS Logon Manager supports authorization_code, client_credentials, refresh_token, and password as valid grant_types. The grant_type defines the process that will be used to obtain an Access Token from SAS Logon Manager. The authorization_code grant requires the end-user to authenticate in their browser and return the code to the client to then exchange for the Access Token for the end-user. Examples of this flow are the standard login to the SAS Viya web applications and the SAS Viya CLI with the command auth loginCode. The client_credentials grant obtains an Access Token just for the custom application and not for the end-user, it uses the client_secret registered with SAS Logon Manager when the custom application was defined. The refresh_token grant obtains the Access Token by presenting an existing valid Refresh Token. Then the password grant uses the end-user username and password to authenticate to SAS Logon Manager and obtain the Access Token for the end-user. Remember the password grant is only applicable if an LDAP Provider is configured for your SAS Viya environment.   Use Cases   Before we dive into further details it is useful to understand some use cases when operating as the custom application using the client_credentials grant is appropriate or required. The first use case is specific to the internal services within the SAS Viya environment. As the different services and applications that make up the SAS Viya environment bootstrap, they need to create authorization rules, define their configurations etc. Internal SAS Viya services and applications during bootstraping leverage the client_credentials grant to allow them to complete this process. Another use case is application-to-application interfaces such as SCIM. The SCIM client, perhaps Azure Active Directory, needs to authenticate to SAS Viya to provision the users and groups. The SCIM client presents an Access Token to authenticate this connection.   Other use cases are more specific to your own usage of the SAS Viya environment. Perhaps you have an on-prem SAS 9.4 environment that needs to connect to SAS Cloud Analytic Services as part of an ETL process. The ETL process is part of your standard batch processing, and a corresponding end-user does not exist in your cloud-based SAS Viya environment. As such you want to configure a custom application on the SAS Viya side and authenticate as this for the connection to SAS Cloud Analytic Services.   Alternatively, you might have an external application that presents generalized modelling results. You want to be able to regularly connect to SAS Viya run a model in SAS Cloud Analytic Services and return the results to the external application. Since this is a regular process that runs unattended you do not want to run this in the context of a specific end-user. So again, you want to run this as a custom application registered with SAS Logon Manager.   Authentication and Authorization   Using the client_credentials grant results in an Access Token for the custom application and not an end-user. Once an Access Token has been obtained SAS Viya at the most basic level does not distinguish between how the Access Token was obtained. Access Tokens obtained with client_credentials do not contain any user claims, so the client ID in the Access Token will be accepted as the authenticated principal name. This is for all practical purposes treated like a username. This means that any connection providing a valid Access Token will be as an "Authenticated User". Most SAS Viya APIs do not distinguish between user and client Access Tokens. However, some services will inspect the Access Token itself to see if it is an end-user or a custom application that is connecting and presenting the Access Token. These services will inspect the Access Token looking for user specific claims which are not present when the Access Token is obtained using the client_credentials grant.   Authorization requires one of the following: A rule granting access to the endpoint to "Everyone". A rule granting access to the endpoint for all "Authenticated Users", where "users" in this context includes custom applications. A rule granting access to a User principal where the principal name is the client ID. A rule granting access to a Group principal where the custom application is registered with the Group in its list of authorities.   Within SAS Environment Manager only the Rules page will allow you to type the client ID to define authorization rules that will apply to your custom application. In other authorization screens, such as CAS authorization, or Folder’s authorization, you are only able to select Users, Groups, and Custom Groups as provided by the Identities microservice. Therefore, it is not possible to assign direct permissions to your ClientID to say a folder or a caslib. Instead, you need to create a Custom Group for your custom applications and assign authorization information to the Custom Group. For the examples in this blog, we will create a Custom Group with the name and ID of CustomApps. Then we can apply authorization information to the CustomApps group, for example allowing access to the Public folder:     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.    Adding a Custom Application to a Custom Group   Adding a custom group to a custom application is very straightforward. When the custom application is registered, the authorities parameter defines a list of the groups that will be present in the Access Token obtained when using the client_credentials grant. So, all you need to do is include the group ID for your custom group in the authorities parameter when you register your custom application.   Registering an Example Custom Client   Now we can create our custom client application to SAS Logon Manager. There are two ways to register the custom application, you can either use the SAS Viya CLI or you can manually register the custom application by calling the SAS Logon Manager APIs. Here we will demonstrate manually registering the custom application. To register the custom application, you need to obtain an Access Token from SAS Logon Manager as a member of the SAS Administrators group. For example, the following could be used to obtain a token for the sasadm user, who is a member of the SAS Administrators group:   export BEARER_TOKEN=`curl -sk -X POST \ "${INGRESS_URL}/SASLogon/oauth/token" \ -u "sas.cli:" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d 'grant_type=password&username=sasadm&password={{myPassword}}' | awk -F: '{print $2}'|awk -F\" '{print $2}'`   Where you replace {{myPassword}} with the password for the sasadm user. The same could be used for any other member of SAS Administrators if you have an LDAP Provider defined. Otherwise, if your environment is configured for SCIM you could use the SAS Viya CLI to obtain the initial Access Token using the auth loginCode command. You could then extract the Access Token from the credentials.json file.   This token will then enable you to register your custom application:   curl -k -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN" \ -d '{ "client_id": "cust1.app", "client_secret": "myclientsecret", "scope": ["uaa.none"], "authorities": ["CustomApps"], "authorized_grant_types": ["client_credentials"], "access_token_validity": 900 }'   Note: You should specify a complex random string as the client_secret, a simple value is shown here to make the examples easy to read.   You should see something like the following for a successful response, we have split this output onto multiple lines to make it easier to read:   {"scope":["uaa.none"], "client_id":"cust1.app", "resource_ids":["none"], "authorized_grant_types":["client_credentials"], "autoapprove":[], "access_token_validity":900, "authorities":["CustomApps"], "lastModified":1673609094057, "required_user_groups":[]}   Notice that the authorized_grant_types only include client_credentials; this means that this client will never be able to obtain an Access Token for an end-user. Since this custom application will never obtain credentials for an end-user we have also set the scope to uaa.none. In addition, for our example the access_token_validity has been set to 900, which is 10 minutes, so we will need to reauthenticate every 10 minutes. You can define the access_token_validity to whatever value makes sense for your custom application, the value is the number of seconds that the Access Token will be valid for.   When using the client_credentials grant the authorities will represent the custom group, so our custom application will be in the CustomApps custom group.   Updating an Example Custom Client   If you need to change the details of the custom client, perhaps to change the client secret or to change the access_token_validity you can again use the SAS Logon Manager API. As with registering you will need to have an Access Token as a member of SAS Administrators. For example, to update the client secret of our already registered custom application we would use the following command:   curl -k -X PUT "${INGRESS_URL}/SASLogon/oauth/clients/cust1.app" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN" \ -d '{ "client_id": "cust1.app", "client_secret": "myclientsecret1234", "scope": ["uaa.none"], "authorities": ["CustomApps"], "authorized_grant_types": ["client_credentials"], "access_token_validity": 900 }'   You should see something like the following for a successful response, we have split this output onto multiple lines to make it easier to read:   {"scope":["uaa.none"], "client_id":"cust2.app", "resource_ids":["none"], "authorized_grant_types":["client_credentials"], "autoapprove":[], "access_token_validity":900, "authorities":["CustomApps"], "lastModified":1673610132049, "required_user_groups":[]}   Deleting/Unregistering an Example Custom Client   Finally, if you want to remove the registration for your custom application you would use the SAS Logon Manager API again. As with registering you will need to have an Access Token as a member of SAS Administrators. For example, to delete our custom application we would use the following command:   curl -k -X DELETE "${INGRESS_URL}/SASLogon/oauth/clients/cust1.app" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN"   You should see something like the following for a successful response, we have split this output onto multiple lines to make it easier to read:   {"scope":["uaa.none"], "client_id":"cust2.app", "resource_ids":["none"], "authorized_grant_types":["client_credentials"], "autoapprove":[], "access_token_validity":900, "authorities":["CustomApps"], "lastModified":1673610132049, "required_user_groups":[]}   Then use the following command to check there is no output:   curl -k "${INGRESS_URL}/SASLogon/oauth/clients/cust1.app" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN"   Custom Applications and Credentials Microservice   The Credentials microservice inspects the Access Token when deciding if the secret that is stored can be accessed. When the Access Token has the grant_type of client_credentials the Credentials microservice identifies the caller as a client and not an end-user, since there are no user scopes within the Access Token. The credentials microservice uses three types of identity: Identity Type = User Identity Type = Group Identity Type = Client   Within SAS Environment Manager credentials can be managed for Users and Group. However, credentials for Clients cannot be managed in SAS Environment Manager. Therefore, it makes sense to register the custom application as a member of a custom group so that credentials can be easily managed for that custom application. These credentials could be a user and password in a Password Authentication Domain, a token credential in a Token Authentication Domain, or an encryption key in an Encryption Domain.   If we store credentials in either a Password Authentication Domain or a Token Authentication Domain, these can be used by the Launcher microservice when launching a SAS Compute Server pod. So, the SAS Compute Server pod will run with this credential. Remember, by default the Launcher microservice will look in the DefaultAuth Password Authentication Domain. But this can be changed by editing the sas.compute.domain.default property. If we don’t store a credential, then the Launcher microservice will prevent the SAS Compute Server pod from being launched.   You can then validate that the ClientID has access to the stored credential by performing a GET request on /credentials/domains/{domainID}/secrets and presenting the Access Token for the custom application as the Bearer Token. If this returns the credentials, then it is setup correctly.   Client Credentials and SAS Cloud Analytic Services   SAS Cloud Analytic Services inspects the Access Token when launching the CAS session. Since the Access Token contains grant_type=client_credentials SAS Cloud Analytic Services recognises that this is a client application and with TRACE logging will display the messages:   DEBUG 2022-12-02 12:02:04.736 +0000 [cas-shared-default] - REST authentication request DEBUG 2022-12-02 12:02:04.736 +0000 [cas-shared-default] - oauthAuthenticate(): Validating token. DEBUG 2022-12-02 12:02:04.737 +0000 [cas-shared-default] - Service request: cust1.app TRACE 2022-12-02 12:02:04.737 +0000 [cas-shared-default] - Oauth token zid: uaa TRACE 2022-12-02 12:02:04.737 +0000 [cas-shared-default] - Identity is service account   As such, the CAS session will always run as the CAS service account. The session can never be host-launched and credentials in the authentication domain given by the sas.compute.domain.default property cannot be used to launch the CAS session. Once running, the CAS session can be leverage both authentication and encryption domains to access data.   Client Credentials and Launcher Service   The Launcher service will launch SAS Compute pods for the custom client. The Launcher service recognises that the Identities microservice will not generate a UID and GID for the grant_type=client_credentials. As such by default the Launcher will look for the reserved sasapp in the authorities, which means that the client is part of the SAS Viya environment. If it is part of the SAS Viya environment the SAS Compute Server pod runs with the default user, which is sas. Otherwise, for custom applications that do not have the reserved sasapp in the authorities, the Launcher service attempts to look-up credentials in the authentication domain given by the sas.compute.domain.default property for launching the SAS Compute Server pod. If there is no stored credential launching the SAS Compute Server pod will fail.   Therefore, if you associate a credential with the Custom Group your custom application is a member of, the Launcher service will use those to launch the SAS Compute Server pod. This can be validated by examining the debug logging for the Launcher service, which for example will show:   DEBUG 2022-12-01 16:03:28.519 +0000 [launcher] - Getting credential supplier: credentialType=USER_LAUNCH [0:USER_LAUNCH] DEBUG 2022-12-01 16:03:28.519 +0000 [launcher] - Checking if host credential is required: user=cust1.app operatingSystem=linux [0:cust1.app 1:linux] DEBUG 2022-12-01 16:03:28.519 +0000 [launcher] - Host credential not required: user=cust1.app operatingSystem=linux reason=["Operating system is linux.", "sas.compute.kerberos.enabled property is set to false."] [0:cust1.app 1:linux 2:["Operating system is linux.", "sas.compute.kerberos.enabled property is set to false."]] DEBUG 2022-12-01 16:03:28.519 +0000 [launcher] - Found authentication domain: user=cust1.app authenticationDomain=DefaultAuth [0:cust1.app 1:DefaultAuth] DEBUG 2022-12-01 16:03:28.519 +0000 [launcher] - Searching for OAuth2 credential: user=cust1.app authenticationDomain=DefaultAuth [0:cust1.app 1:DefaultAuth] DEBUG 2022-12-01 16:03:28.559 +0000 [launcher] - Found stored credential: user=cust1.app authenticationDomain=DefaultAuth [0:cust1.app 1:DefaultAuth] DEBUG 2022-12-01 16:03:28.559 +0000 [launcher] - Using password credential: user=cust1.app operatingSystem=linux credentialUserId=sastest1 [0:cust1.app 1:linux 2:sastest1] DEBUG 2022-12-01 16:03:28.559 +0000 [launcher] - Assigned value clientToken from a UserPassCredential WARN 2022-12-01 16:03:29.015 +0000 [launcher] - #{...} syntax is not required for this run-time expression and is deprecated in favor of a simple expression string WARN 2022-12-01 16:03:29.095 +0000 [launcher] - #{...} syntax is not required for this run-time expression and is deprecated in favor of a simple expression string DEBUG 2022-12-01 16:03:29.128 +0000 [launcher] - Is Workload orchestrator enabled?: false [0:false] DEBUG 2022-12-01 16:03:29.129 +0000 [launcher] - User sastest1 currently owns 0 processes in a non-terminal state [0:sastest1 1:0] DEBUG 2022-12-01 16:03:29.129 +0000 [launcher] - User sastest1 is a non-super user and has a limit of 10: enabled=true [0:sastest1 1:10 2:true] DEBUG 2022-12-01 16:03:29.137 +0000 [launcher] - Using podTemplate sas-compute-job-config in namespace gelenv [0:sas-compute-job-config 1:gelenv] DEBUG 2022-12-01 16:03:29.138 +0000 [launcher] - Requested command in the launch request unwrapped: /opt/sas/viya/home/bin/compsrv_start.sh [0:/opt/sas/viya/home/bin/compsrv_start.sh] DEBUG 2022-12-01 16:03:29.138 +0000 [launcher] - The allow list with the replaceable parameters replaced: [/opt/sas/viya/home/bin/compsrv_start.sh] [0:[/opt/sas/viya/home/bin/compsrv_start.sh]]   This shows the cust1.app custom client connecting and then fetching the credentials for the sastest1 user from the Credentials microservice.   Example Custom Client: Using Job Execution Service   Now that we have the following: A Custom Group defined An authorization rule allowing the Custom Group access to the Public folder A custom client defined with the scope linking the Custom Group   We can attempt to create a folder inside the Public folder, create a job definition inside the new folder, submit the job definition to the Job Execution service, check the job execution status, and fetch the resulting job execution files. To perform this test, I used Postman and the sample provided by Joe Furbee available here: https://github.com/sassoftware/rest-api-use-cases/tree/main/postman/job-execution. This is an end-to-end example for Job Execution and interacts with the following endpoints: /folders/folders /jobDefinitions/definitions /jobExecution/jobs /jobDefinitions/definitions/{{job_ID}} /jobExecution/jobs/{{execution_ID}}/state /jobExecution/jobs/{{execution_ID}} /{{files_location}}/content   After authenticating with the client_ID and client_secret I was able to run Joe’s example without any further changes. The custom client, because it had access to the Public folder, was able to create and submit the job to SAS Viya.   Example Custom Client: Accessing CAS   Next, I wanted to see if the custom client would be able to interact with SAS Cloud Analytic Services using the REST API. For this use-case I wanted to generate a CAS session, load a table from the Samples global CASLIB and then fetch the first 10 rows from that table. The authorization for the Samples CASLIB was not changed from the default which is:       Again, I used Postman to interact with the CAS REST API, using the following endpoints: /cas-shared-default-http/cas/sessions – to start a session /cas-shared-default-http/cas/sessions/{{cas_session}}/actions/table.loadTable – to issue the loadTable action /cas-shared-default-http/cas/sessions/{{cas_session}}/actions/table.fetch – to fetch the first 10 rows /cas-shared-default-http/cas/sessions/{{cas_session}} – to terminate the session   Information from the documentation was used to construct the CAS REST API calls.   After authenticating with the client_ID and client_secret I was able run this flow successfully and return 10 rows of data from SAS Cloud Analytic Services to the REST API client.   Example Custom Client: Running SAS Code   Finally, I wanted to test running a SAS Compute Server pod and submitting code to it via the SAS Compute REST API. The documentation for the SAS Compute REST API was used to build out this test using Postman. This test leveraged the following endpoints:   /compute/contexts – to find the ID for the SAS Studio Compute Context /compute/contexts/{{contextId}}/sessions – to launch a SAS Compute Server session /compute/sessions/{{computeId}}/jobs – to submit a job to the SAS Compute Server session /compute/sessions/{{computeId}}/jobs/{{jobId}}/state – to check the status of the submitted job /compute/sessions/{{computeId}}/jobs/{{jobId}}/listing – to fetch the listing from the completed job /compute/sessions/{{computeId}}/jobs/{{jobId}}/log – to fetch the log from the completed job /compute/sessions/{{computeId}} – to terminate the SAS Compute Server session   After authenticating with the client_ID and client_secret I was able to complete this test. Running through this example a SAS Compute Server pod was launched, since credentials were stored for the custom application, these were used to launch the pod. Then some simple code to do a PROC PRINT, launch a CAS Session, report on the CAS nodes, and terminate the CAS session was run within the SAS Compute Server session. All this code completed successfully and then the listing and log output was fetched back to Postman.   Conclusion   In this blog, we have explored a possible option for some use-cases when it is impossible to configure service accounts in your Identity and Authentication providers. This can assist in uses-cases where some Viya related jobs/tasks are required to be automated or where a real user credential cannot be used. The expected scenario is that processes are run within your SAS Viya environment as real users; these users could be your actual end-users, or they could be service accounts correctly configured in your Identity and Authentication providers. It is only this scenario that is fully tested with all the SAS Viya applications. What we have explored here is a possible option for some use-cases when it is impossible to configure service accounts in your Identity and Authentication providers.     If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.     Find more articles from SAS Global Enablement and Learning here. ... View more