In this post we will discuss some different scenarios for using Kerberos authentication with SAS Viya 2021.2.5 (and later). Kerberos end-to-end authentication and Kerberos constrained delegation were introduced with SAS Viya 2020.1.4 in March 2021. In the SAS Viya 2021.2.5 release some further enhancements have been made to Kerberos authentication. As such, we will discuss some of the different ways Kerberos authentication could be leveraged with SAS Viya.
Kerberos Modes
Before we consider the different scenarios, we should familiarize ourselves with the different ways Kerberos authentication can be configured with SAS Viya. We will phrase these as different modes of leveraging Kerberos authentication.
The first mode is Kerberos for SAS Logon Manager. In this mode the only component configured for Kerberos authentication is SAS Logon Manager. This allows the end-user’s browser to authenticate the end-user to just SAS Logon Manager by presenting a Kerberos Service Ticket. The Service Ticket is for the HTTP Kerberos principal. The Service Ticket just proves the end-user is genuinely who that person claims to be. It does not provide any information to identify the end-user; SAS Logon Manager request that identity information from the Identities microservice.
The next mode is Kerberos Delegation. This mode builds upon Kerberos for SAS Logon Manager and adds Kerberos configuration for the SAS Compute Server and SAS Cloud Analytic Services (CAS). In this mode the HTTP Kerberos principal is configured for delegation. This could be Kerberos Constrained Delegation, Kerberos Resource-based Constrained Delegation, or Kerberos Unconstrained Delegation. This results in Kerberos credentials for the end-user being made available to the SAS or CAS session, which can then be used to access data sources.
In addition to Kerberos Delegation, the CAS Controller, and the SAS/CONNECT Spawner can be configured to accept direct Kerberos connections. This enables client applications making direct connections to either CAS or SAS/CONNECT to leverage Kerberos to authenticate the end-user. SAS Cloud Analytic Services will also leverage the HTTP Kerberos principal. While the SAS/CONNECT Spawner will leverage a SAS Kerberos principal. The SAS/CONNECT Spawner can either locally launch the SAS/CONNECT Server inside the same pod as the spawner, or the SAS/CONNECT Server can be launched in its own pod, termed pod-launched. Only pod-launched SAS/CONNECT Servers will leverage the SAS Kerberos Proxy.
The final mode is Kerberos Hybrid Authentication. In this mode we do not need to rely on Kerberos for SAS Logon Manager. Instead, Kerberos credentials for the end-user can be made available to the SAS or CAS session leveraging the SAS Kerberos Proxy. The SAS Kerberos Proxy can use Kerberos Constrained Delegation or Kerberos Resource-based Constrained Delegation to obtain credentials for the end-user leveraging Kerberos Protocol Transition. Alternatively, the SAS Kerberos Proxy can use a provided username and password to obtain Kerberos credentials for the end-user. Which effectively splits this mode into Kerberos Hybrid Authentication with Protocol Transition or Kerberos Hybrid Authentication with User Credentials.
The Kerberos Hybrid Authentication mode has been enhanced with the SAS Viya 2021.2.5 release; allowing for greater control of when Kerberos Constrained Delegation is used and allowing group credentials to be used.
So, to summarize we have the choice of:
- Kerberos for SAS Logon Manager
- Kerberos Delegation
- With Direct Kerberos connections to CAS and SAS/CONNECT
- Without Direct Kerberos connections to CAS and SAS/CONNECT
- Kerberos Hybrid Authentication with Protocol Transition
- With Direct Kerberos connections to CAS and SAS/CONNECT (when pod-launched)
- Without Direct Kerberos connections to CAS and SAS/CONNECT
- Kerberos Hybrid Authentication with User Credentials
- With Direct Kerberos connections to CAS and SAS/CONNECT (when pod-launched)
- Without Direct Kerberos connections to CAS and SAS/CONNECT
With this understanding of the different Kerberos modes, we can examine some different scenarios and see which mode would be our best choice.
Scenario 1: Single Sign-On from Domain Client Desktops
In this scenario our end-users will be accessing the SAS Viya environment from client machines that are joined to our domain. We want to provide single sign-on into SAS Viya so that end-users do not need to type a username and password. In fact, in some cases our end-users might not even be aware of their username and password; for example, if they authenticate to their client machine with biometrics or a smart card.
The data our end-users will be accessing is provided by data sources that do not leverage Kerberos authentication. This could be databases using database usernames and passwords, or it could be on file systems presented to the SAS Viya environment.
For this scenario we could leverage the Kerberos for SAS Logon Manager mode. This would meet our requirements since Kerberos credentials are not required to access the data. We only need to configure SAS Logon Manager for Kerberos.
However, we should not think that Kerberos is the only mechanism to provide single sign-on. Equally, we could use OpenID Connect or SAML with SAS Logon Manager to provide single sign-on. If the OpenID Connect or SAML IdP is already integrated with our domain these authentication options can even provide single sign-on for our biometric or smart card users.
Scenario 2: Single Sign-On and Domain End-User Kerberos Access to Data
This next scenario builds on the last scenario but adds the requirement to use Kerberos to access the data sources. This might be a database such as Microsoft SQL Server using Kerberos authentication or a NFS version 4.1 filesystem using Kerberos authentication. This means we require Kerberos credentials for our end-users within the SAS or CAS sessions to be able to access data.
We can use Kerberos Delegation to meet the requirements of this scenario. SAS Logon Manager, SAS Compute Server, and SAS Cloud Analytic Services are all configured for Kerberos authentication. We then have the choice of the type of delegation that is enabled on the HTTP Kerberos principal.
Our end-users will use Kerberos to authenticate to the SAS Viya environment and those Kerberos credentials will flow through the environment and be available to the SAS and CAS sessions to access their data. As with the last scenario, Kerberos into SAS Logon Manager is not our only choice for single sign-on. We present it as the first choice since our end-users are accessing the environment from client machines that are joined to our domain. But we could consider this scenario to be the same as the next scenario and ignore the fact that our end-users are on our domain.
Scenario 3: Single Sign-On and Non-Domain End-User Kerberos Access to Data
With this scenario we again want to have single sign-on into the SAS Viya environment and we need to leverage Kerberos to access the data sources. But here we are not assuming that the end-user’s client machines are joined to our domain. So, we either cannot or do not want to use Kerberos to authenticate to SAS Logon Manager. However, the access to data does require Kerberos credentials.
Now we can use either Kerberos Hybrid Authentication with Protocol Transition or Kerberos Hybrid Authentication with User Credentials to meet our requirements. SAS Logon Manager will be configured with either OpenID Connect or SAML to provide single sign-on into SAS Viya. The SAS Compute Server and SAS Cloud Analytic Services will be configured for Kerberos to provide the Kerberos credentials to the SAS or CAS sessions so that our end-users can access data.
Our choice here is how the SAS Kerberos Proxy should obtain those Kerberos credentials for the end-users. To use Kerberos Hybrid Authentication with Protocol Transition we need to ensure the username returned from the OpenID Connect or SAML authentication matches the username in our Kerberos Key Distribution Center (KDC). The principal used by the SAS Kerberos Proxy must be configured for Kerberos Constrained Delegation, and this will be used to obtain the Kerberos credentials for the end-user.
Alternatively, if the OpenID Connect or SAML authentication returns a username that does not match the KDC; perhaps because it is returning an email address or objectID we would use Kerberos Hybrid Authentication with User Credentials. In this case each of our end-users would store a username and password valid with the KDC in the KerberosAuth authentication domain. The SAS Kerberos Proxy will fetch the username and password from the KerberosAuth authentication domain and initialize a Kerberos credential for our end-users.
Scenario 4: Single Sign-On and Shared Kerberos Access to Data
The final scenario we will consider built upon the last scenario. So, we want to have single sign-on into SAS Viya, the data source requires Kerberos authentication, but in this case, we can use a shared credential to access the data source. Perhaps the data source requiring Kerberos authentication is a database such as Microsoft SQL Server, but we do not require individual access to the data source.
For this scenario we would use Kerberos Hybrid Authentication with User Credentials to meet our requirements. SAS Logon Manager will be configured with either OpenID Connect or SAML to provide single sign-on into SAS Viya. The SAS Compute Server and SAS Cloud Analytic Services will be configured for Kerberos to provide the Kerberos credentials to the SAS or CAS sessions so that our end-users can access data.
The SAS Kerberos Proxy will still return credentials from the KerberosAuth authentication domain, but now it will look for a group credential rather than an individual credential. A SAS Administrator can assign a username and password in the KerberosAuth authentication domain to different groups of our end-users. This could be a single group containing all our end-users or several groups splitting our end-users based around some business logic. For example, we might have one group for Risk Analysts using one username and password and another group for managers using a different username and password.
Conclusion
We have shown there are different ways in which Kerberos can be configured for our SAS Viya environment. We have addressed these different modes at a high-level, and in future materials will examine the Kerberos Hybrid Authentication modes in more detail. We have also presented some scenarios where the different modes would best meet our requirements.
Find more articles from SAS Global Enablement and Learning here.
