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

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