The concept of group-managed service accounts was introduced with the release of SAS Viya 2023.07 and the changes to Run As authentication. We discussed the new model in a previous post. With the release of SAS Viya 2024.05 the credentials for the group-managed service accounts can now be managed with the SAS Viya CLI.   Performing Actions in SAS Environment Manager   Prior to the SAS Viya 2024.05 release you needed to use SAS Environment Manager to store the credentials for the group-managed service account. This is detailed in the SAS documentation.   As a reminder there are steps that must be completed as a member of the SAS Administrators group, and other steps that must be completed as the group-managed service account itself. These steps are summarized in the picture below.     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. 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. Until the SAS Viya 2024.05 release, this task had to 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.   Performing Actions in SAS Viya CLI   With the release of SAS Viya 2024.05 all these steps can now be completed using the SAS Viya CLI. Which is covered in the SAS documentation.   A member of the SAS Administrators role can add the group-managed service account to the automatically created Service Account Users for Schedule custom group, with a command like the following:   /opt/sas/viya/home/bin/sas-viya identities add-member --group-id ScheduleServiceAccountUsers -user-member-id GMSA1   Where GMSA1 is the userID of the group-managed service account.   The users which will schedule jobs and jobs flows as the group-managed service account need to be given access to the stored credential for the group-managed service account. This is best performed by giving access to the credential to a custom group. As such, a member of SAS Administrators will need to create custom groups and place users into these custom groups. This can be performed with commands like the following:   /opt/sas/viya/home/bin/sas-viya identities create-group --id SchedulingUsers_HR --name "Scheduling Users HR" --description "Group for Scheduling Users in HR" /opt/sas/viya/home/bin/sas-viya identities add-member --group-id SchedulingUsers_HR -user-member-id Delilah   This will create the custom group Scheduling Users HR and, in our example, add the user Delilah to that group.   Now that the group-managed services account has been added to the Service Account Users for Schedule custom group, and any further custom groups have been created, the credentials for the group-managed service account can be stored. First, we need to create the Token Authentication Domain and then we need to store a credential for the group-managed service account in the previously created Token Authentication Domain.   For this we need to authenticate the SAS Viya CLI as the group-managed service account. This could be with a username and password, or by logging in through the browser by using the loginCode option.   You can then use the SAS Viya CLI to create the new Token Authentication domain with a command like the following:   /opt/sas/viya/home/bin/sas-viya credentials domains create --domain-id Scheduling_HR_TokenAuth --type oauth2.0   Remember it must be defined with the type of oauth2.0.   Finally, the credential can be stored for the group-managed service account and access given to the custom group containing users which will schedule jobs and jobs flows as the group-managed service account. This can be done with a command like the following:   /opt/sas/viya/home/bin/sas-viya credentials groups create --domain-id Scheduling_HR_TokenAuth --identity-id SchedulingUsers_HR\ --allowed-client sas.scheduler --allowed-client sas.jobExecution --allowed-client sas.jobFlowScheduling   Where:   The domain-id defines the Token Authentication domain, The identity-id defined the custom group which will have access to the credential, The allowed-client option specifies the application (client) IDs that are required for Jobs and Flows. You must include sas.scheduler, sas.jobExecution, and sas.jobFlowScheduling.   Specifying the allowed-client option is essentially the same as selecting the Restrict applications check box in SAS Environment Manager.   Conclusion   The release of SAS Viya 2024.05 brings improvements to the SAS Viya CLI that allows for all steps you need to complete to correctly configure group-managed service accounts to be performed with the SAS Viya CLI. So now, you are able to either use the SAS Viya CLI or SAS Environment Manager to complete this configuration.     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 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