SAS Viya 2020.1.4 (and later) Kerberos Delegation Overview
The STABLE 2020.1.4 release of SAS Viya introduced support for Kerberos delegation, which means this will be available with LTS 2021.1. In this article we will look at an overview of Kerberos delegation. We will look at what is supported, what is required, and some comments on when using Kerberos makes sense. In future articles we will look in depth at the authentication processing, how to configure Kerberos delegation, and some specifics of Kerberos delegation with SAS/ACCESS to Hadoop.
What is supported
From the 2020.1.4 release of SAS Viya both unconstrained and constrained Kerberos delegation are supported. Kerberos delegation means that Kerberos is used to access the environment, used within the environment, and then used to access data sources from the environment. So, we can say that Kerberos authentication is used into, with-in, and out from SAS Viya. It is important to note that not all third-party technology currently supports Kerberos constrained delegation, for example neither Hadoop nor Oracle Database support constrained delegation.
The 2020.1.4 release of SAS Viya brings feature equality, as regards Kerberos authentication, with previous SAS releases. However, the implementation of Kerberos delegation is different with the 2020.1.4 release compared with SAS Viya 3.5. SAS Viya 3.5 at a high level can be shown as:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Note: Initial user authentication to SAS Logon Manager is not shown, the user has already authenticated with SAS Logon Manager.
With SAS Viya 3.5, Kerberos is used to authenticate directly to components within the environment. The Kerberos delegation from SAS Logon Manager is used to directly authenticate using Kerberos for the launch of the SAS Compute Server or to launch a SAS Cloud Analytic Services session. Then Kerberos delegation is again used to access data sources.
Whereas with the 2020.1.4 release of SAS Viya, at a high-level, Kerberos delegation can be shown as follows:
Note: Initial user authentication to SAS Logon Manager is not shown, the user has already authenticated with SAS Logon Manager.
Kerberos is used to authenticate to SAS Logon Manager in the 2020.1.4 release of SAS Viya, but it is not used to directly authenticate for the launch of the SAS Compute Server or to launch a SAS Cloud Analytic Services session. Instead, the Viya ACCESS Token generated by SAS Logon Manager is used to authenticate the end-user for launching either the SAS Compute Server or the CAS session. Then within these components is a separate SAS Kerberos Proxy sidecar container. The SAS Kerberos Proxy is then responsible for making the delegated Kerberos credentials available to the session. Once those delegated Kerberos credentials are available to the session, they can be used to access the data sources.
So, you can see that the model for Kerberos delegation has been re-worked with the 2020.1.4 release of SAS Viya to work effectively in the Kubernetes environment that SAS Viya utilizes. In this way the 2020.1.4 release of SAS Viya does not require the internal services themselves to be Kerberos servers the way they were with SAS Viya 3.5. It is also important to note that the 2020.1.4 release of SAS Viya does additionally support direct Kerberos connections to SAS Cloud Analytic Services. This direct Kerberos connection works more similarly to the SAS Viya 3.5 processing. We will dive into the details of the Kerberos processing in the next article.
What is required
Now that we have discussed at a high-level what is supported and have a general idea of how Kerberos delegation with the 2020.1.4 release of SAS Viya will operate we can consider what is required. First and foremost, we need to discuss Kerberos Principals. Remember, with SAS Viya 3.5 we had three Kerberos principals; HTTP, sascas, and sas-launcher. With the 2020.1.4 release we only require a HTTP principal, and if using Kerberos for SAS/CONNECT a SAS principal. The HTTP principal will be used for SAS Logon Manager, the SAS Kerberos Proxy sidecar, and even the direct connection to SAS Cloud Analytic Services.
For SAS/CONNECT in SAS Viya 2020.1 (and later) there are two types of SIGNON that we refer to as "internal" and "external". More details on these two types of SIGNON for SAS/CONNECT can be found in Edoardo Riva’s Article With regards to Kerberos delegation the "internal", where the SIGNON is submitted from the SAS Compute Server and the SAS/CONNECT server is a direct launched, will use the same ACCESS Token to authenticate and the SAS Kerberos Proxy is leveraged to obtain the Kerberos credentials. So, in the "internal" case the same HTTP principal is used. Only in the "external" case, where the SIGNON is from an external client such as SAS 9.x, do we require the SAS principal. Equally, in the "external" case the Kerberos authentication processing is the same as SAS Viya 3.5.
The HTTP principal will need to be configured for delegation; either configured for unconstrained delegation or configured for constrained delegation. For constrained delegation the HTTP principal must be able to perform S4U2SELF, so for example with Active Directory the account must have "TrustedToAuthForDelegation", and then must have the data source Service Principal Names (SPNs) registered against the account. For "external" SAS/CONNECT the SAS principal will require the same settings.
If you are using Active Directory, rather than MIT, for the Kerberos Key Distribution Center (KDC) then there are additional requirements for the user account objects the HTTP or SAS principal are registered against. Active Directory has the concept of the User Principal Name (UPN) as well as Service Principal Name (SPN). The UPN uniquely identifies a user account and the SPN uniquely identifies an instance of a service running on a host. Active Directory will only allow a Kerberos credential to be initialized for a UPN, you cannot kinit with a SPN. For the HTTP principal the UPN must be the same as the SPN. For the SAS principal used in "external" connections for SAS/CONNECT this can be relaxed and the UPN does not have to be the same as the SPN. However, for the SAS principal we would still recommend that the UPN = SPN.
The format of the principal (in MIT terms) or SPN (in Active Directory terms) is /. For the HTTP principal we then have HTTP/, where the hostname part will be the hostname used to access the SAS Viya environment in the browser. Care must be taken if this value is a CNAME alias rather than an A-RECORD DNS entry. Most browsers will take the URL entered, lookup the associated IP address, and then reverse lookup the IP address to find the hostname. This hostname will be used in the request to obtain a Service Ticket. So, if you are accessing SAS Viya using a CNAME alias the browser will actually ask for a Service Ticket for the corresponding A-RECORD. Which means you need to be careful when registering the principal name.
SAS Viya needs access to the long-term keys for the Kerberos principal. The long-term key is based on the password for the principal and is encrypted with an encryption algorithm; typically, either RC4, AES 128-bit or AES 256-bit encryption. Which means for a single principal you could have three long-term keys leveraging these three encryption types. These long-term keys should match the Service Ticket that is presented by the client. So, if the client will present a Service Ticket using AES 256-bit encryption that is the type of long-term key you will need. The long-term keys are provided to SAS Viya in a Kerberos keytab file.
The Kerberos keytab file can contain both multiple keys for the same principal and multiple principals. If you are using SAS/CONNECT from "external" clients, you can either have two keytab files one for the HTTP principal and one for the SAS principal; or one keytab with containing the long-term keys for both principals. If you do decide to have only a single keytab file, the long-term keys for the SAS principal should be placed before the HTTP principal in the keytab file.
Finally, you will need to provide a Kerberos configuration file. More details on the Kerberos configuration file can be found in the MIT documentation. Essentially, this will provide some settings for the Kerberos library, Realm specific contact information, and mappings between hostnames and Kerberos realms. One important setting for direct connections to SAS Cloud Analytic services is "dns_canonicalize_hostname=false" in the libdefaults section of the Kerberos configuration file. This will ensure the correct hostname is used when SAS Cloud Analytic Services connects to SAS Logon Manager. This setting is also required for "external" SAS/CONNECT clients.
For SAS/ACCESS to Hadoop you will need to consider some additional steps and we will discuss that separately.
When does Kerberos make sense?
In the last part of this overview article I want to discuss when Kerberos makes sense. SAS Viya 2020.1 (and later) is an environment that runs in "the cloud". Kerberos is an authentication protocol that works very well on-premise but does not fit so neatly into a cloud environment. The most important part of Kerberos authentication is the Kerberos Key Distribution Center (KDC). The KDC is the trusted third-party that enables the clients and servers to authenticate using Kerberos. Standard cloud Identity and Access Management solutions do not include a KDC. For example, Azure Active Directory has no ability to do Kerberos, unlike the on-premise Active Directory. To be able to do Kerberos in Azure your two choices are to either pay for the additional Azure Active Directory Domain Services or to "bring your own" KDC and run this in the Infrastructure-as-Service offering. Both choices add significant cost and management overhead. Importantly, Azure Active Directory Domain Services only provides resource-based constrained delegation. Currently the MIT Kerberos libraries available to SAS Viya in the base OS used in the container images does not support resource-based constrained delegation. Additionally, with a cloud based KDC, there are concerns about how a client running outside the cloud infrastructure can securely authenticate to the KDC. Although, future releases of SAS Viya will support running on Kubernetes within the customer data center, where Kerberos might make slightly more sense.
An authentication protocol like OpenID Connect (OIDC) is more suited to a cloud environment. Azure Active Directory offers OIDC at all subscriptions levels. SAS has also extended SAS Viya 2020.1.4 to offer delegation like options when using Azure Active Directory OIDC for single sign-on into the SAS Viya environment. SAS Logon Manager can cache the Azure AD ACCESS token, and then code run in either a SAS Compute Server session or a SAS Cloud Analytic Services session can use the cached ACCESS token. The cached ACCESS token is used seamlessly without end-user interaction to obtain Azure AD credentials to access data sources integrated with Azure AD. For example, the LIBNAME statement for Azure PostgreSQL can seamlessly leverages the cached Azure AD ACCESS token to authenticate the end-user. This provides a scenario pictured here:
Note: Initial user authentication to SAS Logon Manager is not shown, the user has already authenticated with SAS Logon Manager.
This scenario is much more of a cloud-native way to integrate authentication between SAS Viya 2020.1.4 (and later) and your data sources. The SAS Viya environment and data sources do not need to be running in Azure but must just use Azure Active Directory OIDC for authentication.
Conclusion
In this article we have provided an overview of Kerberos delegation with the STABLE 2020.1.4 release of SAS Viya. This feature will be included in the LTS 2021.1 release as well. We have examined the differences between Kerberos delegation with SAS Viya 3.5 and SAS Viya 2020.1.4. We have also reviewed the requirements for Kerberos delegation and discussed that Kerberos is not really a cloud-native authentication protocol. In the future articles we will examine the authentication processing in detail, look at how Kerberos delegation is configured, and discuss the additional requirements for SAS/ACCESS to Hadoop.
Find more articles from SAS Global Enablement and Learning here.
