In this post I want to examine the use case of needing to authenticate a service account into a SAS Viya environment. Specifically, we’ll examine how an external process like a CI/CD pipeline might authenticate a non-personal service account to the SAS Viya environment to be able to run code in that environment.   Use Case We’ve previously discussed the concept of authenticating using a custom application. However, as we identified in that post, we still need to provide a credential set to be able to launch a SAS Compute Server instance. So, what are our options if we want to build a pipeline that will at some point run SAS code where we eliminate or minimize user interaction.   The specific use case that prompted me to write this post is where a CI/CD pipeline will deploy SAS Viya, configure SCIM as the identity provider, configure OIDC authentication, and then run SAS code. This pipeline should be able to complete all steps automatically without any user interaction.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   We know that if our SAS Viya environment is configured with SCIM and OIDC the standard approach to authenticate a user will be within the browser. Even when using the SAS Viya CLI we would need to use the auth loginCode option to allow us to interactively authenticate in the browser.   Our first option to deal with the CI/CD pipeline builds upon this concept. We’d split the single pipeline into two phases. In the first phase the SAS Viya environment is deployed, and then SCIM and OIDC are configured. In the second phase any SAS code is run. In between the two phases we complete some manual interactive authentication. This authentication step results in making a Refresh Token available to use for the second phase of the CI/CD pipeline.     Our second option does not require us to split the CI/CD pipeline into two parts. Instead, the second option requires that we can authenticate to the third-party OIDC provider automatically using the service account. This might be by extracting the password for the service account from a vault and using that to authenticate to the OIDC provider. We’ll then use the Access Token from the third-party OIDC provider to authenticate to SAS Logon Manager in SAS Viya.     In the rest of this post, we’ll use Microsoft Entra ID as the SCIM client and OIDC provider. However, the same concepts will apply to other providers as well.   Option 1: Leveraging the Refresh Token Once the SAS Viya environment is deployed, we can interactively authenticate to SAS Logon Manager and store the returned Refresh Token. Then we can use the Refresh Token to obtain a new Access Token. However, at this point the Refresh Token that is returned with the Access Token is the same as the one we used to gain the Access Token. As such, we then need to use the Access Token with the JWT Bearer Token grant to obtain a new Access Token and Refresh Token. This new Refresh Token will be valid for the standard refresh lifetime of 14 days. This process can then be repeated multiple times, so long as the Refresh Token has not expired or been revoked.   We need to use the JWT Bearer Token grant, and for this we will need to know both the client_id and client_secret. Therefore, we will need to create a custom application registered with SAS Logon Manager. To register the custom application with SAS Logon Manager we can either complete the steps with the SAS Viya CLI or using the REST API.   For example, to create a custom application with the REST API we could use the following series of CURL commands. First, we obtain a client registration token:   BEARER_TOKEN=$(curl -skX POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=sas.cli&grant_type=password&username=sasboot&password=${myPass}" |jq -r ."access_token")   Here we are using the sasboot user since our assumption is that our environment is configured with SCIM as the identity provider, and we cannot authenticate as a member of SAS Administrators using the password grant type. Also we will have set an initial password for the sasboot user with the sitedefault.yaml.   Next, we register the custom application using the BEARER_TOKEN we just obtained:   curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN" \ -d '{ "client_id": "customapp.jwt", "client_secret": "clientsecret", "scope": ["openid","uaa.user"], "autoapprove": ["openid","uaa.user"], "authorities": ["uaa.none"], "authorized_grant_types": ["urn:ietf:params:oauth:grant-type:jwt-bearer","refresh_token"], "refresh_token_validity": 7776000 }'   You would use a much more complex client_secret than the example here of clientsecret. Notice that this custom application only supports the JWT Bearer Token grant type and refresh tokens. As such it will only accept existing Access Tokens and Refresh Tokens for authentication and nothing else.   We can then use the SAS Viya CLI, to authenticate interactively in the browser for the user we will want to run code in our CI/CD pipeline. Which means using:   /opt/sas/viya/home/bin/sas-viya auth loginCode   Then fetch the current Refresh Token from the local cache used by the SAS Viya CLI with the following:   MY_REFRESH=$(cat .sas/credentials.json |jq -r '.Default."refresh-token"')   This Refresh Token can then be used with the SAS Logon Manager REST API to obtain a new Access Token:   MY_Request=$(curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H 'Accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "client_id=sas.cli" \ --data-urlencode "grant_type=refresh_token" \ --data-urlencode "response_type=token" \ --data-urlencode "scope=openid" \ --data-urlencode "refresh_token=${MY_REFRESH}") MY_ACCESS_TOKEN1=$(echo $MY_Request|jq -r '."access_token"') MY_REFRESH_Expiry=$(echo $MY_Request|jq -r '."refresh_expires_in"')   If you look at the expiry of the Refresh Token returned in this request, you’ll notice that it does not change from the original Refresh Token obtained with the SAS Viya CLI. So, here we use the custom application we registered to obtain another new Access Token and Refresh Token using the JWT Bearer Token grant.   curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H 'Accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "client_id=customapp.jwt" \ --data-urlencode "client_secret=clientsecret" \ --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \ --data-urlencode "response_type=token" \ --data-urlencode "scope=openid" \ --data-urlencode "assertion=${MY_ACCESS_TOKEN1}" \ |jq -r   From this request you’ll notice the refresh_expires_in value has re-set to the system default, normally 14 days, or the value used when we registered the client.   Moving forward with this new Refresh Token it can be used to request a new Access Token as we did above. However, the Refresh Token is tied to the client_id we used on the token request. This is why we also registered the refresh_token grant type against our custom application. Therefore, on future request using the new Refresh Token we’d change the MY_Request code above to use client_id=customapp.jwt and it's associated client_secret.   That Refresh Token could then be stashed in a vault that is accessible to our CI/CD pipeline. Then as long as the REST API calls to re-new the Refresh Token are run every two weeks; we can continue to leverage the Refresh Token to gain access to the SAS Viya environment.   Option 2: Leveraging External OIDC Authentication As discussed above our second option of leveraging external OIDC authentication means that we don’t need to split the CI/CD pipeline into two parts. The pipeline job can move seamlessly from deployment to configuration and onto running SAS code. However, it is dependent on being able to authenticate to the third-party OIDC provider automatically using the service account.   Again, this option will be dependent on leveraging the JWT Bearer Token grant. But this time we will be presenting an Access Token obtained from the third-party OIDC provider. So again, we need to register a custom application with SAS Logon Manager. To register the custom application with SAS Logon Manager we can either complete the steps with the SAS Viya CLI or using the REST API.   For example, to create a custom application with the REST API we could use the following series of CURL commands. First, we obtain a client registration token:   BEARER_TOKEN=$(curl -skX POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=sas.cli&grant_type=password&username=sasboot&password=${myPass}" |jq -r ."access_token")   Here we are using the sasboot user since our assumption is that our environment is configured with SCIM as the identity provider, and we cannot authenticate as a member of SAS Administrators using the password grant type.   Next, we register the custom application using the BEARER_TOKEN we just obtained:   curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER_TOKEN" \ -d '{ "client_id": "customapp.extjwt", "client_secret": "clientsecret", "scope": ["openid","uaa.user"], "authorities": ["uaa.none"], "authorized_grant_types": ["urn:ietf:params:oauth:grant-type:jwt-bearer"], "refresh_token_validity": 7776000 }'   You would use a much more complex client_secret than the example here of clientsecret. Notice that this custom application only supports the JWT Bearer Token grant type. As such it will only accept existing Access Tokens for authentication and nothing else. Each time we want to use this custom application we will separately authenticate to the third-party OIDC provider.   The part to authenticate our service account against the third-party OIDC provider will be specific to the provider. Here we will consider Microsoft Entra ID. Microsoft provides the Azure CLI which allows us to authenticate to Microsoft Entra ID. However, the basic authentication using the Azure CLI will only generate us a version 1 Access Token and we need to have a version 2 Access Token to use that to authenticate to SAS Viya.   To be able to request a version 2 Access Token with the Azure CLI we need to request a token using the command az account get-access-token and specify a scope. This means that we need to have an Application Registration in Microsoft Entra ID where we can change attributes as necessary. We should use the Application Registration that exists for the OIDC integration with Microsoft Entra ID, as this will ensure the audience (aud) will be set to the correct application.   In the Azure Portal, as a user with the ability to make changes to the Application Registration we need to complete the following steps:   Expose a scope in the web API registration – covered in the Microsoft documentation From the App registration page in the Azure Portal expand Manage and select Expose an API Select Add for the Application ID URI, you can accept the default value or specify your own unique URI and select Save Select Add a scope, specify something like CLI_login as name, CLI Login as Admin consent display name and description, then select Add scope Select Add a client application, enter 04b07795-8ddb-461a-bbee-02f9e1bf7b46 as Client ID, select CLI_login as authorized scopes and select Add application – this is the client ID for the Azure CLI   Ensure any required claims are included in the Access Token From the App registration page in the Azure Portal expand Manage and select Token configuration Select Add optional claim Select Access as Token type Select the additional claims, ensure you have selected the claim you are using as the userID in SAS Viya Select Add   Update the manifest and set accessTokenAcceptedVersion to 2 From the App registration page in the Azure Portal expand Manage and select Manifest Scroll down to the “api” section and update the value of requestedAccessTokenVersion from null to 2 Select Save   With these steps complete we can then obtain an Access Token from Microsoft Entra ID with the following Azure CLI commands:   az login --user serviceaccount@company.com --password ${myPass} AZ_TOKEN=$(az account get-access-token --scope api://<UNIQUE_URI>/CLI_login |jq -r ."accessToken")   That Microsoft Entra ID Access Token can then be used with the SAS Logon Manager API to obtain the SAS Viya Access Token.   curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/token" \ -H 'Accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "client_id=customapp.extjwt" \ --data-urlencode "client_secret=clientsecret" \ --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \ --data-urlencode "response_type=token+id_token" \ --data-urlencode "scope=openid" \ --data-urlencode "assertion=${AZ_TOKEN}" \ |jq -r   The returned SAS Viya Access Token can then be used by the CI/CD pipeline to run SAS Code. Notice with this option we are not relying on Refresh Tokens; the only long-term item would be the credentials for the service account with Microsoft Entra ID. Each time the pipeline runs those credentials are pulled into the pipeline and the two Access Tokens generated.   Conclusion Here we have examined two approaches for authenticating to SAS Viya as a service account, when it’s not appropriate to use a custom application to run the code. We’ve illustrated how we can leverage the JWT Bearer Token grant and a custom application registration to either renew an Access Token and Refresh Token. Or move from an external Access Token to a SAS Viya Access Token using the JWT Bearer Token grant.     Find more articles from SAS Global Enablement and Learning here. ... View more

The SAS Viya 2025.03 release introduces a change to the SAS/CONNECT client included in SAS Viya. This change allows the SAS/CONNECT client to leverage Authentication Domains maintained by the Credentials microservice in SAS Viya. When you are leveraging Spawner signons. In this post we will examine what the change is, why the change is important, and discuss some use cases where you might want to leverage Authentication Domains.   What is the change? The change is in the SAS/CONNECT client included in the SAS Programming Runtime environment. This means that the update to the SAS/CONNECT client is available to interactive SAS sessions, such as those used by SAS Studio or SAS Batch Server sessions and SAS/CONNECT Server sessions.   In SAS 9.4 SAS/CONNECT clients, you were able to use Authentication Domains defined in the SAS 9.4 Metadata Server to store the credentials used to sign on to the remote SAS/CONNECT Server. With the SAS Viya 2025.03 release, you can also use Authentication Domains with the SAS/CONNECT client in SAS Viya, when doing a Spawner signon.   Obviously, in SAS Viya, the technology for creating and managing the Authentication Domains is different from SAS 9.4. With SAS Viya you can use either SAS Environment Manager or the SAS Viya CLI as a member of SAS Administrators to create Authentication Domains. The Authentication Domains can either be Password Domains or Token Domains.   The Password Domains store a username and password credential set that is made available to either an individual user or groups of users. Whereas the Token Domain stores a SAS Logon Manager refresh token for a specified SAS Viya user, and that refresh token is made available to either an individual user or group of users.   Clearly, the credential in a Token Authentication domain will be valid only with the current SAS Viya environment, where the refresh token is generated and stored. You cannot store a refresh token for your Production SAS Viya environment in your Development SAS Viya environment.   The existing authentication methods are still valid for the SAS/CONNECT client in SAS Viya. So, you can still leverage the existing OAuth Token, a username and password entered in code, an AUTHINFO file, or Kerberos authentication. This is covered in the SAS documentation and also discussed by my colleague Edoardo Riva in a previous post.   Why is this important?   Adding support for Authentication Domains with the SAS/CONNECT client in SAS Viya simplifies the migration of your existing SAS 9.4 code into your SAS Viya environment. If the SAS/CONNECT Servers, your code references are the same and can be reached from your SAS Viya environment; you can just run the same code as-is in your SAS Viya environment. You do not need to go back through your existing code and make changes switching to an alternative form of authentication.   Use Case for Password Authentication Domains   The main use case for leveraging Authentication Domains with the SAS/CONNECT client in SAS Viya, is the easy migration of code from your existing SAS 9.4 environments. If you have already been using Authentication Domains with the SAS/CONNECT client in SAS 9.4 and returning usernames and passwords from Authentication Domains in the SAS 9.4 Metadata Server, you can simply run this code as before on SAS Viya.   You will need to create the corresponding Authentication Domain on SAS Viya. This step will need to be completed by a member of the SAS Administrators group. Next, you will need to store the credential sets (usernames and passwords) that your end users require. If you are sharing a credential set amongst a group of users, you will need to store the credential set as a member of SAS Administrators group, and make that credential set available to the required group of users. Otherwise, individual end users can maintain their own credential sets in the Authentication Domain after the domain is created.   For example, you might have something 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.   A member of SAS Administrators would store Credential Set 1 and make that available to the SAS Viya custom group "Group A". Then a member of SAS Administrators would store Credential Set 2 and make that available to the LDAP group "Group B". Finally, an end user Bob would store Credential Set 3 for themselves, without revealing the credentials to a member of SAS Administrators.   The code for the SAS/CONNECT client connection would look like the following:   %let rhost=my-connect-spawner.mydomain.com 7551; signon rhost authdomain="ConnectAuth";   When this code is run:   If the end user is a member of "Group A" they authenticate with Credential Set 1, If the end user is a member of "Group B" they authenticate with Credential Set 2, If the end user is Bob, they authenticate with Credential Set 3. It is important to ensure that an end user is not in both "Group A" and "Group B". Depending on your specific LDAP group structure you might find it easier to associate credential sets with SAS Viya custom groups rather than LDAP groups to meet this requirement.   Also, although we have said LDAP groups in the discussion above, those could be groups provided through SCIM, if you are using SCIM instead of LDAP.   Use Case for Token Authentication Domains   The use case for a Token Domain is slightly different. The credential set in a Token Domain is a refresh token for a specific user within the same SAS Viya environment. That refresh token is valid with SAS Logon Manager in that SAS Viya environment and not valid anywhere else.   Using a Token Domain only makes sense when you want a group of users within the SAS Viya environment to authenticate to the SAS/CONNECT Spawner in the same SAS Viya environment with a shared account. If you wanted the end users to authenticate as themselves to the SAS/CONNECT Spawner in the same SAS Viya environment, you would just use OAuth Token authentication.   If you do want to have a group of users, use a shared account for authenticating to the SAS/CONNECT Spawner inside the same SAS Viya environment, using the Token Domain makes more sense than using a Password Domain. The credential set in the Token Domain is refreshed each time it is used, whereas the credential set in the Password Domain would need to be updated each time the password changes for the shared account.   Setting up the credential set in the Token Domain does require a bit more configuration by a member of SAS Administrators. As well as creating the Authentication Domain, they will need to setup additional rules that allow the shared account to store the refresh token. This is covered in the documentation under Group Managed Service Accounts Used with Compute and CAS.   For example, if the shared account is called SASServiceUser1 and our Token Domain is called ConnectTokenDomain the rules would be:   /SASEnvironmentManager/domains PrincipalType: User Principal: SASServiceUser1 Permission: Read /credentials/domains/ConnectTokenDomain/groups/* PrincipalType: User Principal: SASServiceUser1 Permission: Create,Read,Update,Delete /credentials/domains/ConnectTokenDomain/users/* PrincipalType: User Principal: SASServiceUser1 Permission: Create,Read,Update,Delete /credentials/domains/ConnectTokenDomain/credentials PrincipalType: User Principal: SASServiceUser1 Permission: Read   Once the member of SAS Administrators has completed these steps anyone with access to the credentials for the SASServicesUser1 can log in with that user and store the refresh token. When the refresh token is stored that is linked to a custom group, external LDAP or SCIM group, or a user. Then members of the custom group, external LDAP or SCIM group, or an individual user will be able to access that stored refresh token. As such they will be able to run code like the following:   %let rhost=sas-connect-spawner 17551; signon rhost authdomain="ConnectTokenDomain";   Which will authenticate them to the SAS/CONNECT Spawner inside the SAS Viya environment as the SASServicesUser1.   Conclusion   The update to the SAS/CONNECT client in the SAS Viya 2025.03 release is targeted at making your migration of code from SAS 9.4 to SAS Viya easier. By adding support of Authentication Domains to the SAS/CONNECT client in SAS Viya you should be able to run your SAS 9.4 code as-is without changes in SAS Viya. This is based on the assumption that you have correctly defined the Authentication Domains in SAS Viya first.     Find more articles from SAS Global Enablement and Learning here. ... View more

LDAP searches for group membership information can be resource intensive. This can be made worse when multiple users log in simultaneously. With the SAS Viya 2024.11 Stable Release an alternative has been introduced when you use either OpenID Connect or SAML along with LDAP for the Identities microservice. This alternative allows group membership information to be included in the authentication claims from the Identity Provider, such as Microsoft Entra ID, and processed by SAS Logon Manager during log in.   Why is this important?   Issues with the LDAP searches for group membership information can result in slow log ins for your users. This might not be noticeable when testing with a limited number of users, but as the number of concurrent users increases the extra processing during log in might become unacceptable.   Providing your users with a smooth, simple, and straightforward log in experience will help to increase the adoption of your SAS Viya environment.   Who does this impact?   Obviously, issues with the LDAP searches for group membership information will only impact environments where LDAP is used with the Identities microservice to provide user information. If you are using SCIM provisioning this will not impact your environment.   The new feature introduced with the SAS Viya 2024.11 Stable release only provides an alternative if you are using either OpenID Connect or SAML for authentication to SAS Logon Manager. It does not impact environments using LDAP or Kerberos for authentication to SAS Logon Manager.   For environments using LDAP or Kerberos for authentication to SAS Logon Manager, you might consider altering the group membership search attributes instead. You could review what group membership information is required in the SAS Viya environment. Then adjust the search terms to limit the LDAP group information made available to SAS Viya.   How does it work?   The new feature introduced with the SAS Viya 2024.11 Stable release, relies on the third-party OpenID Connect or SAML Identity Provider including information about group membership in the authentication claims. Then SAS Logon Manager can be configured to interpret the groups claim that your Identity Provider sends. Which means that SAS Logon Manager does not need to fetch the LDAP group information from the Identities microservice.   The Identities microservice will still regularly populate its cache with LDAP group information. The cached information will then still be available to other parts of the SAS Viya environment. For example, to populate screens within SAS Environment Manager.   The new feature just means that the Identities microservice is not generating a possibly large number of LDAP queries for group membership information each time a user logs into SAS Viya.   How do I configure this?   There are two parts to the configuration; you must configure the OpenID Connect or SAML Identity Provider to include the group information, then you configure SAS Viya to use this information. SAS documentation covers the second part; the SAS Viya configuration which involves setting attributeMappings.external_groups and groupMappingMode. These are described in the following sections of the SAS documentation:   Provide the SAS Viya Platform with Information about the OIDC IdP Configure OIDC Provider Properties for Microsoft Entra ID Configure OIDC Provider Properties for Okta Configure the SAS Viya Platform as a SAML Service Provider Configure SAML Provider Properties for Microsoft Entra ID   The configuration property attributeMappings.external_groups is available under either sas.logon.oauth.providers or sas.logon.saml.providers. It has no default value and is an optional setting. This specifies the attribute claim to use for group membership information. The configuration property groupMappingMode is also optional but has a default value of AS_SCOPES and should only be changed if directed by SAS Technical Support to change it. It is also available under either sas.logon.oauth.providers or sas.logon.saml.providers.   Example Configuration with Microsoft Entra ID using OpenID Connect   Finally, we’ll walk through the complete configuration when using OpenID Connect authentication with Microsoft Entra ID. Our SAS Viya environment is configured with an LDAP provider for the Identities microservice, in this case leveraging Microsoft Entra ID Domain Services.   First, we need to configure the App Registration in Microsoft Entra ID to include the group information in the ID Token provided to SAS Logon Manager. Here we will discuss making the changes to the App Registration using the Azure Portal, you will need to log into the Azure Portal with a user who has sufficient rights to edit details of the App Registration.   On the App Registration page complete the following to include the group information in the ID Token:   Expand Manage Select Token configuration Select Add groups claim The following types of groups can be included in the ID Token: Security groups Directory roles All groups (includes 3 group types: security groups, directory roles, and distribution lists) Groups assigned to the application (recommended for large enterprise companies to avoid exceeding the limit on the number of groups a token can emit) For the ID, Access, and SAML Tokens you can customize the token properties by type. You should select the option that matches what you have configured in the LDAP configuration for the Identities microservice, most probably sAMAccountName.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   At this point we should discuss that how you create groups in Microsoft Entra ID impacts the availability of these different fields for the group information. As covered in the Microsoft documentation, sAMAccountName and on-premises GroupSID attributes are available only on group objects synced from Active Directory. Specifically, you must be running Microsoft Entra Connect version 1.2.70 or later. Earlier versions of Microsoft Entra Connect than 1.2.70 will synchronize the group objects from Active Directory, but they won't include the required group name attributes.   In addition, there is another option if you have assigned a group to the application. Remember you need to have a Premium subscription for Microsoft Entra ID to be able to assign a group to an application. With a group assigned to the application you can also use the cloud-only group display names as the text to include in the token.   You can only add cloud-group names of assigned groups to an application. The restriction to groups assigned to the application is because a group name is not unique, and display names can only be emitted for groups explicitly assigned to the application to reduce the security risks. Otherwise, any user could create a group with duplicate name and gain access in the application side.   Currently, in the Azure Portal to assign the cloud-only group display names you need to edit the manifest for the application.   In the portal, select Identity > Applications > App registrations > Select Application > Manifest Enable group membership claims by changing groupMembershipClaims to ApplicationGroup Set optional claims for group name configuration in the optionalClaims section of the manifest:      Select Save for the manifest   Another consideration with assigning groups to the application is that the groups you assign will need to match the groups you are providing to SAS Viya through the LDAP configuration for the Identities microservice. Depending on the number of groups in your environment this could prove to be challenging.   Rather that diving straight into configuring SAS Viya to use the additional claim we should validate the contents of the token first. We can follow the steps in this post: https://s4erka.wordpress.com/2021/03/26/azure-ad-application-to-test-oauth2-0/ to validate the contents of the token. We need to complete the following steps:   Register https://jwt.ms as a Redirect URI for our test application Allow ID tokens for Implicit and hybrid flows   These can both be set on the Authentication page of our test application in the Azure Portal.   Then we can construct a URL to access our test application based on the following template (should be one line, broke into lines here to readability):   https://login.microsoftonline.com/{{TENANT_ID}}/oauth2/v2.0/authorize ?client_id={{APP_ID}}&nonce=defaultNonce &redirect_uri=https%3A%2F%2Fjwt.ms &scope=openid+profile+User.read+offline_access &response_type=id_token   For example:   https://login.microsoftonline.com/######-53d9-44b7-8e88-#########/oauth2/v2.0/authorize?client_id=########-25db-4891-9a1d-10f2fe######&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid+profile+User.read+offline_access&response_type=id_token   Browsing to this URL and authenticating as one of our users in Microsoft Entra ID will redirect us to JWT.ms with our token:     We can see that in the ID Token generated by Microsoft Entra ID we now have the group membership information in the groups claim. At this point you can remove the steps to allow testing with https://jwt.ms and move onto configuring SAS Viya.   To configure SAS Viya to use the group claim information we need to update the OpenID Connect configuration as per the SAS documentation. From looking at the Microsoft Entra ID token we know the claim is "groups", so we just need to set attributeMappings.external_groups to that same string "groups". In SAS Environment Manager this would look like the following:     Finally, the easiest way to validate the SAS Viya configuration is to authenticate with the SAS Viya CLI and then inspect the Access Token generated by SAS Logon Manager. If we use "auth loginCode" with the SAS Viya CLI we can log in with OpenID Connect. Then when we inspect the Access Token in .sas/credentials.json we will see the group membership information in the authorities claim:     Conveniently for my test environment, these groups are different from the LDAP groups. So, if I look at the gatedemo001 user in SAS Environment Manager where only the LDAP groups are displayed I see:     Clearly, for my test environment SAS Logon Manager must be getting the group membership information from the Microsoft Entra ID token since the Identities microservice with its LDAP configuration does not know about the groups listed in the SAS Logon Manager generated Access Token.   In your SAS Viya environment, you are unlikely to have such a simple way to prove the groups are provided by the OIDC token. You could, however, review the Identities microservice logging information as a user authenticates. You will then see that there are no LDAP queries to fetch the group membership information.   Conclusion   As we have discussed the new feature introduced with the SAS Viya 2024.11 Stable release provides the opportunity to improve the performance of login operations for environments configured with an LDAP provider for Identities and either OpenID Connect or SAML for SAS Logon Manager. Removing the requirement for additional LDAP searches for the group membership information can have a significant impact on the log in times for high concurrency environments. Stuart Rogers     Find more articles from SAS Global Enablement and Learning here. ... View more

In the last post we discussed the concept of using multiple SCIM providers with a single SAS Viya environment. In this post I want to dive into more details on using Keycloak as a SCIM provider with SAS Viya.   SAS Viya Configuration   The SAS Viya configuration is independent of the chosen SCIM provider. The SAS Viya configuration is covered in the documentation. I would recommend if configuring multiple SCIM providers with SAS Viya that separate SAS Logon Manager client registrations are made. Allowing you to have separately managed long-term access tokens for each of the SCIM providers you are configuring.   Keycloak Requirements   Keycloak is an Open-Source Identity and Access Management solution. Keycloak is a Cloud Native Computing Foundation incubation project. Keycloak can be installed locally on a Linux or Windows server, it could be run in a container, or even deployed to Kubernetes. There are even several different offerings available in the various cloud marketplaces, such as Azure Marketplace.   Keycloak has built-in support for OpenID Connect and SAML authentication protocols. Keycloak also has built-in support to connect to existing LDAP or Active Directory servers. You can also implement your own provider if you have users in other stores, such as a relational database. However, Keycloak does not have built-in support for SCIM version 2.0. There is an open issue requesting this support but this does not seem to be on the current road map. Instead, an add-on product SCIM for Keycloak - https://scim-for-keycloak.de/ has been developed by Pascal Knüppel.   SCIM for Keycloak   SCIM for Keycloak is an extension plugin that provides SCIM server functionality for Keycloak. That means you will be able to synchronize users and groups from products like Microsoft Entra ID, Sailspoint, Atlassian and others with Keycloak. It also includes a SCIM Client. The SCIM Client functionality synchronizes your users/groups with other identity providers supporting the SCIM protocol.   SCIM for Keycloak is not open source. There is a free edition and an enterprise edition. The free edition only supports less than 1000 users, less than 100 groups, and has a license key renewal every 14 days. The enterprise edition supports unlimited users and groups, no license key is required, updates are included for 1 year, and includes a copy of the source-code with limit access rights. More details on the licensing of SCIM for Keycloak can be found here.    SCIM for Keycloak with SAS Viya   For this post, I will assume that you already have your users and groups within your Keycloak instance. This could be from linking to your Active Directory or LDAP server, or it could even be by using the SCIM for Keycloak SCIM server functionality. Here we will just focus on the SCIM client functionality of SCIM for Keycloak. This will enable you to provision users and groups from Keycloak to SAS Viya.   SCIM for Keycloak has less restrictions on the network connectivity to SAS Viya than the cloud-based SCIM clients such as Microsoft Entra ID. Since you will be deciding where to run Keycloak you will have greater control over the network route taken between Keycloak and your SAS Viya environment. Also, within the SCIM for Keycloak SCIM client configuration it is possible to upload a TLS certificate to establish the HTTPS connection to SAS Viya. This means that SAS Viya does not need to use a commercial TLS certificate signed by a publicly recognised Certificate Authority.   Once you have configured SAS Viya for SCIM provisioning following the documentation, it is relatively straightforward to configure Keycloak. You just need to complete the following:   From the Keycloak home page select SCIM Administration Console      Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Select Start Login Log in with a Keycloak adminstrator Select Remote SCIM Provider   Select the plus sign against Actions Enter SAS Viya as Name   Enter the URL to your SAS Viya environment with identities/scim/v2 appended as Base URL, for example https://sasviya.com/identities/scim/v2   Select Long Life Bearer Token Authentication as Authentication Type   Enter the long-lived access token you generated as part of the SAS Viya configuration as Bearer Token Select Add Select Save Configuration Select Load Provider Configuration Select Yes, this will connect to SAS Viya and load the configuration from the Identities microservice. Additional tabs will become available at the top of the page, and you will be taken to the Schemas tab. Select the Realm Assignments tab Select Assign to Realm against the Keycloak Realm you have configured containing your users and groups   Select Synchronization tab On the User Synchronization sub-tab scroll down and select Count local and remote resources, you should see the number of users defined in Keycloak as the local users and any users in SAS Viya as remote users Select Synchronize above resource range, you should see the message Synchronization has finished, all users were processed. The results of the synchronization can be seen in the tables below Scroll down and review the messages generated by user synchronization. You should see details of the users who were synchronized to SAS Viya. Scroll up and select the Group Synchronization sub-tab Scroll down and select Count local and remote resources, you should see the number of groups defined in Keycloak as the local groups and any groups in SAS Viya as remote groups Select Synchronize above resource range, you should see the message Synchronization has finished, all users were processed. The results of the synchronization can be seen in the tables below Scroll down and review the messages generated by group synchronization. You should see details of the groups that were synchronized to SAS Viya. Scroll back up and change the drop down box to Update Group Members and change the starting range to 1 Scoll down and select Synchronize above resource range, you should see the message Synchronization has finished, all users were processed. The results of the synchronization can be seen in the tables below At the top of the window select admin and select Sign Out Unlike SCIM provision from Microsoft Entra ID where each provisioning job is submitted to a Microsoft controlled schedule in the background the Keycloak provision is instant.   It is worth noting that in my setup, I'm using manually created internal users to Keycloak. In most real-word scenarios, users are brought in automatically from an external provider into Keycloak. As such in my setup, group membership information was not initially provisioned into SAS Viya. There was a very simple and quick solution to get the group membership information. All I needed to do was go into the regular Keycloak admin console and simply remove the members from the group and then re-add them. This immediately caused SCIM for Keycloak to send the patch update to SAS Viya and my group membership information was then available.   Conclusion   Here we have shown how Keycloak can be used as a SCIM provider with your SAS Viya environment. While the functionality is not built-in to the standard Keycloak release it is possible to licence SCIM for Keycloak to add the SCIM functionality to Keycloak. SCIM for Keycloak then provides both a SCIM Server and SCIM Client implementation. The SCIM client implementation is what we use to provision users and groups from Keycloak into SAS Viya.     Find more articles from SAS Global Enablement and Learning here.   ... View more

As a reminder SAS Viya supports providing the identity information for end users through either LDAP or SCIM. Specifically, for SCIM (System for Cross-domain Identity Management) SAS Viya is a version 2.0 server. As such, identity information can be loaded by a SCIM version 2.0 client such as Microsoft Entra ID or OKTA. It is also worth noting that LDAP and SCIM in the same SAS Viya environment is not supported. In this post I want to discuss the idea of using multiple different SCIM version 2.0 clients to push identity information to a single SAS Viya environment.   What is Supported   As we have stated SAS Viya is a SCIM version 2.0 server, since the versions of SCIM are not backwards compatible only a SCIM version 2.0 client is able to push identity information. In the official SAS Documentation we provide examples of using Microsoft Entra ID and OKTA. These are not the only supported SCIM version 2.0 clients, just these are the two SAS has documented as examples. Any SCIM version 2.0 client that implements the protocol sufficiently will work with SAS Viya. However, SAS cannot provide support for these third parties. Assistance with the configuration of the third party should be provided by that third party.   Since using either SCIM or LDAP is supported in a SAS Viya environment, enabling SCIM means disabling LDAP. While LDAP provides both identity and authentication services, SCIM only provides the identities. So, enabling SCIM also means you will need to select an authentication protocol to use along with SCIM. The authentication protocol will be either SAML or OpenID Connect. As with SCIM SAS Viya supports defining multiple SAML or OpenID Connect authentication providers. You can also mix SAML and OpenID Connect.   For SAS Viya environments with multiple SAML and/or OpenID Connect providers, the configuration setting sas.logon.zone.idpDiscovery.enabled simplifies the login process for end users. Setting sas.logon.zone.idpDiscovery.enabled to true then prompts users for their email address when they log in. SAS Logon Manager compares the text string after the "@" with the values configured for emailDomain in any OIDC or SAML providers in the environment. If a string match is found, SAS Logon Manager redirects the browser to the corresponding third-party IdP. Otherwise, SAS Logon Manager displays the standard login form.   Why would I do that?   So, we are all now aware that we can configure multiple SCIM version 2.0 clients to push identity information to SAS Viya. Also, we can configure multiple SAML and/or OpenID Connect providers to allow those SCIM users to authenticate to SAS Viya. But why would we want to do that?   One use case that might prompt us to have multiple providers linked to a single SAS Viya environment is where we have separate groups of users. We might have users who are part of our organisation in one provider and other external users in one or more other providers. The users that are part of our organisation might be in Microsoft Entra ID while the external users are in OKTA. We would then configure Microsoft Entra ID for SCIM and OpenID Connect as well as configuring OKTA for SCIM and SAML or OpenID Connect. With this setup both groups of users would be able to access the SAS Viya environment.   Another use case would be where there is a reluctance to add functional or service accounts to the corporate Identity Provider when they are just used within SAS Viya. For example, if the Group Managed Service Accounts will only access resources within SAS Viya, corporate IT might not want to add them to the Microsoft Entra ID tenant used across the organization. In such a case we could deploy Keycloak and manage those functional accounts purely within Keycloak. We can then use the SCIM for Keycloak (https://scim-for-keycloak.de/) product to provide the SCIM client implementation in Keycloak. Here, the business users would authenticate with OpenID Connect from Microsoft Entra ID, and the functional users would authenticate with SAML or OpenID Connect from Keycloak.   Caution   As with a SAS Viya environment configured with only one SCIM provider, or with an LDAP provider, we must ensure that any email addresses defined for users are unique. We cannot have a user with the same email address as another user or one user with the same email address in different SCIM providers attached to the Viya environment.   Conclusion   In this short post we have just introduced the idea that you can configure multiple providers for your SAS Viya environment. These can be multiple SCIM version 2.0 clients or multiple SAML and/or OpenID Connect authentication providers. This gives you the flexibility to have different groups of users access your single SAS Viya environment. In future post we’ll look in more detail on how you might configure Keycloak as a SCIM version 2.0 client. You can refer to the SAS documentation for details of using Microsoft Entra ID and OKTA as a SCIM version 2.0 client.     Find more articles from SAS Global Enablement and Learning here. ... View more

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