The SAS Viya 3.5, released in November 2019, provides some further enhancements with regards to authentication. In this article we look at these enhancements from a high level in the form of addressing customer scenarios. We’ll also touch upon some scenarios that are supportable with SAS Viya 3.4. In future posts we’ll take these scenarios and step through the configuration changes you’ll need to make.
At the highest level the changes to authentication with SAS Viya 3.5 are:
We’ll now look at some scenarios which these technology changes enable. In addition, we’ll explore a scenario that is also supported with SAS Viya 3.4.
Microsoft is recommending the use of Windows Defender Credential Guard. The use of Windows Defender Credential Guard breaks applications if they require Kerberos unconstrained delegation. SAS Viya 3.5 supports Kerberos constrained delegation, which means that SAS Viya 3.5 supports Windows Defender Credential Guard. Previous releases of SAS Viya only supported unconstrained delegation and so did not support Windows Defender Credential Guard.
Some customers may not want to provision end-user accounts on the server hosts. This is especially true with cloud deployments, where the end-users of the application should not really be aware of the back-end computing resources and the additional administrative overhead of provisioning users is not required.
SAS Cloud Analytic Services in its default configuration on a Linux full deployment has always fitted this model well. The end-user authenticates to the CAS Controller, but the operating system process runs as the CAS service account. The authorization rules defined in the SAS Viya environment apply to the end-user, but host access is always as the CAS service account.
However, there has been an issue for the end-users wishing to write SAS code to interact with SAS Cloud Analytic Services. With SAS Viya 3.4 both SAS Studio 4.4 and SAS Studio 5.1 ran the SAS session for the end-user as the end-user. So, the end-user accounts had to be provisioned on these hosts. Also, with SAS Studio 4.4 since the end-user authenticated to the CAS Controller with a username and password their CAS session also ran as the end-user.
SAS Viya 3.5 introduces two improvements to resolve this issue. First is a new version of SAS Studio – with SAS Studio 5.2 (Enterprise) available in a full deployment, end-users can access the file system within the application. This means there is no need to use the traditional model SAS Studio 5.2 (Basic) which relies on the SAS Object Spawner and SAS Workspace Server. SAS Studio 5.2 (Basic) is still key in a programming-only deployment when there is no service layer.
The second improvement with SAS Viya 3.5 is the ability to associate a service account with a Compute context. This service account is then used to run the SAS Compute Server session. This means that end-users authenticate with SAS Logon Manager to gain access to SAS Studio 5.2 (Enterprise), but the SAS Compute Server session no-longer runs as the end-user. However, the SAS Compute Server session still has access to the end-user’s internal OAuth credentials generated by SAS Logon Manager. So, connections made from the SAS Compute Server session leveraging the service layer still occur as the end-user. For example, launching a CAS session will occur as the end-user even though the operating system process is running as the service account.
Ideally, just as the enterprise wide RDBMS implementations are "one version of the truth" for data, an enterprise wide network share is "one version of the truth" for end-users’ files. In such an idyllic place every end-user has a network accessible "home" directory that is automatically mounted and made available on every computing resource that they access.
However, many organizations are not in the idyllic place. Especially, with the move towards cloud computing – for fun try an online search for how easy it is to sync Microsoft’s OneDrive with Linux and think about trying to setup that for hundreds or thousands of end-users across a wide variety of different Linux platforms automatically. Many of these organizations will rely on local home directories for their users and rely on the Pluggable Authentication Module (PAM) configuration creating these on-demand the first time a user logs into a system.
Some of the SAS Viya 3.5 components still need access to a home directory for the end-users:
These SAS components do not call far enough into the PAM stack to trigger any automatic creation of home directories. The SAS Object Spawner and SAS Compute Server have provided an option to enable the automatic creation of the home directory with SAS Viya 3.4, which I covered in a previous article. With SAS Viya 3.5 SAS Cloud Analytic Services also now supports the automatic creation of home directories.
Remember, for the automatic creation of home directories the process must "know" where to put the directory. This means that the user attributes returned from the operating system must correctly identify where the home directory should be located. This could be through reading a specific user attribute or something like SSSD fallback_homedir option.
SAS Viya 3.4 (May 2019 Upgrade) provided the option to simplify the sign-in process when using a third-party SAML or OpenID Connect provider. We discussed the sas.logon.zone configuration in a previous article. This removes the need to select the link at the bottom of the login form and end-users just type their email address. If the domain of the email address matches a comma separated list in the SAML or OpenID Connect configuration the end-user is redirected to the third-party provider for authentication.
But what about the case where we don’t want the end-user to have to interact with SAS Logon Manager at all. In this case we can leverage part of the OpenID Connect specification that is implemented by SAS Logon Manager. Using a login_hint parameter, allows an email domain to be passed to SAS Logon Manager authorize request, which is compared against the list of email domains in the SAML or OpenID Connection configuration. If there is a match, the user is automatically redirected to that providers, bypassing the login form altogether.
This login_hint parameter can be added to the SAS Logon Manager request using a simple RewriteRule in the Apache HTTP Server configuration. This RewriteRule can be crafted to either add the login_hint to every authorize request to SAS Logon Manager. Or might only add the login_hint based on properties of the requesting client, such as IP address or browser type. Equally, the RewriteRule might set the login_hint differently depending on where the request is coming from or some other criteria.
Thus, leveraging the login_hint provides true single sign-on for SAML or OpenID Connect providers.
SAS Viya 3.5 builds on all the great work that has gone into the previous releases of SAS Viya. The support for Kerberos Constrained Delegation is the main headline improvement for authentication with SAS Viya 3.5. This along with all the other pieces and improvements made through-out the SAS Viya 3.4 releases, make SAS Viya 3.5 more modern and easily integrated into your infrastructure.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.