The SAS Viya 3.4 (May 2019 Upgrade), includes updates to SAS Logon Manager. In this blog I want to focus on what I believe is one of the most important updates. The SAS Viya 3.4 (May 2019 Upgrade) introduces fall-back authentication when SAS Logon Manager is configured for Kerberos authentication. This means that other authentication mechanisms can now be used with Kerberos for SAS Logon Manager. This does not mean that Kerberos authentication for SAS Logon Manager is now supported in a multi-tenant environment. This remains unsupported. In this blog we will look at how this operates, some of the implications, and some use-cases for using fall-back.
Fall-back authentication with Kerberos has been available with SAS 9.4 for some time. The update for SAS Logon Manager in the SAS Viya 3.4 (May 2019 Upgrade), is the first time this has been available for SAS Viya. The mechanism to provide fall-back is different in SAS Viya to the mechanism used in SAS 9.4.
With SAS Viya there is no additional configuration to enable fall-back with Kerberos authentication. The configuration of Kerberos authentication for SAS Logon Manager remains the same, as we have covered before. Just to state that again – there is nothing extra you need to do to get fall-back. It comes automatically "out of the box" once you have configured Kerberos authentication. In fact, applying the SAS Viya 3.4 (May 2019 Upgrade) to an existing SAS Viya 3.4 environment configured for Kerberos will automatically get you fall-back as well.
The changes with SAS Viya 3.4 (May 2019 Upgrade) to the Kerberos authentication process are:
- /SASLogon/login no-longer responds with a 401 HTTP response code prompting the browser to negotiate authentication. Instead it responds with a 200 HTTP response code and the login form.
- /SASLogon/ and /SASLogon/oauth/authorize respond with a 401 HTTP response code and an embedded error page. The 401 HTTP response code prompts the browser to negotiate authentication. If authentication cannot be negotiated the browser displays the embedded error page.
- The embedded error page redirects to the original URI with an additional query parameter fallback=true
- The presence of the fallback=true parameter redirects the browser to /SASLogon/login and the login form is displayed
This means that if the end-user’s browser is configured for Kerberos they will authenticate to SAS Logon Manager using Kerberos. However, if the browser is not configured for Kerberos the end-user will see the login form instead.
Implications for Fall-back
The main implication of SAS Viya 3.4 (May 2019 Upgrade) supporting fall-back with Kerberos authentication is that Kerberos authentication for SAS Logon Manager can now be combined with other authentication mechanism. Since the login form is displayed another authentication mechanism supported by SAS Logon Manager can now be combined with Kerberos. In fact, multiple mechanisms can now be combined with Kerberos.
Since the browser will be receiving the standard 401-response prompting the browser to attempt authentication, the end-user experience is different in different browsers. Mozilla Firefox, when not configured for Kerberos authentication, silently displays the embedded error page. So, without any prompting in Firefox the SAS Logon login form is displayed.
However, both Internet Explorer and Google Chrome, when presented with the 401-response and not configured for Kerberos attempt to perform NTLM authentication. This means that Chrome and IE present the end-user with a pop-up prompt for a username & password. If this is cancelled, then the SAS Logon Manager login form is displayed. If credentials are entered in the pop-up an unauthorized error is displayed instead, even if these are valid credentials.
For Google Chrome registry settings can be changed to prevent the attempt at NTLM authentication. Creating the registry string value AuthSchemes under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ with the value "basic,digest,ntlm" will prevent the pop-up. While for Internet Explorer you need to uncheck the option "Enable Integrated Windows Authentication" on the Advanced tab of the Internet Properties. The problem with both of these approaches is that these settings apply to all websites the end-user visits, and not just the SAS Viya environment.
Alternatively, you could unset the WWW-Authenticate header for specific clients by using directives in the Apache HTTP Server configuration. For example, to unset the headers for Google Chrome and Internet Explorer you could use the following:
<Location /SASLogon >
# This is to prevent IE or Chrome from doing Kerberos or displaying a NTLM prompt.
BrowserMatch "Trident/7" noWWWAuth
BrowserMatch "Chrome" noWWWAuth
Header unset "WWW-Authenticate: Negotiate" env=noWWWAuth
</Location>
However, this means that no-one using Internet Explorer or Google Chrome can use Kerberos to authenticate to SAS Logon Manager. Following the same concept, you could limit and not allow Kerberos or the NTLM prompt from a range of IP addresses. For example:
<Location /SASLogon >
# This is to prevent Kerberos or NTLM prompt from IP range.
SetEnvIfExpr "-R '10.96.0.0/16' || -R '10.97.0.0/16'" noWWWAuth
Header unset "WWW-Authenticate: Negotiate" env=noWWWAuth
</Location>
Ensures the WWW-Authenticate header is removed for any client connecting from 10.96.*.* or 10.97.*.* irrespective of the browser. Any user coming from those IP addresses would automatically fall-back to the SAS Logon Manager login form.
Or to switch the last example around only allow the WWW-Authenticate header from a known range of IP addresses. So only clients in the known range will be able to use Kerberos authentication, or will see the pop-up in IE or Chrome. All other clients will fall-back to the SAS Logon Manager login form. For this use:
<Location /SASLogon >
# This is to limit Kerberos to the specified IP ranges.
SetEnvIf Request_URI "\.*" noWWWAuth
SetEnvIfExpr "-R '10.96.0.0/16' || -R '10.97.0.0/16'" !noWWWAuth
Header unset "WWW-Authenticate: Negotiate" env=noWWWAuth
</Location>
The placement of these rules is important. For deployments that are using HTTPS, this should be placed inside the VirtualHost of the SSL configuration. For example, on RedHat Linux this is the /etc/httpd/conf.d/ssl.conf file. For deployments that are using HTTP, this should be placed in a new .conf file. Apache HTTP Server processes the .conf files in alphabetical order and this one needs to occur before the proxy configuration in proxy.conf so it should be named accordingly, for example login_header.conf. Putting the redirect rule in both places is fine too. Restart Apache HTTP Server after making any changes to the configuration.
Use Cases for Fall-back
Now that we have an understanding of how fall-back with Kerberos authentication operates and some of the implications. What are some of the use-cases where fall-back with Kerberos authentication could be useful.
Use Case 1: Access with internal account
In some situations, you still need to access your environment using the sasboot account, to resolve a configuration issue. However, previously once Kerberos authentication was enabled with SAS Logon Manager this was impossible. Now with fall-back this is possible, a different browser not configured to perform Kerberos authentication can be used.
Use Case 2: Fall-back to LDAP
This is the basic use-case for using fall-back with Kerberos authentication. If you have some end-users that are unable to use Kerberos authentication. Perhaps these users are part of an organization that has not yet been fully integrated into your organization yet, following a business acquisition. Perhaps these users are using client machines, perhaps Macs, that are not domain members. Where as before these users would not have been able to access the SAS Viya environment, now they can.
Use Case 3: Kerberos Internal & OpenID Connect or SAML External
What about the same users accessing the environment from different machines or locations? Perhaps you have users that can use Kerberos while they are in the office, but also need to access the environment from outside your network, from their home machines. Or perhaps you can use Kerberos for your developers inside your organization, but the consumers of the data are outside your organization.
Previously, you would not have been able to provide Kerberos authentication for the internal users and everyone would have had to use OpenID Connect or SAML. But now with fall-back from Kerberos, your internal users can use Kerberos and the external users can use the federated authentication provider.
Use Case 4: Kerberos Internal & MFA External
Finally, what about a split group of users, internal on your network and external users. Perhaps the same end-users from different locations, or two entirely different groups of users. How do you provide the strongest form of authentication for these two different groups? Now that we have fall-back from Kerberos, you can use Kerberos for the internal users and Multi-Factor Authentication (MFA) through PAM for the external users.
Conclusion
The SAS Viya 3.4 (May 2019 Upgrade) provides us with fall-back from Kerberos authentication from SAS Logon Manager in SAS Viya. This requires no additional configuration and is now the default configuration. Fall-back provides a wide range of options enabling you to mix Kerberos authentication with any of the other supported authentication mechanism.
