SAS Viya 3.4 Multi-Tenant with Kerberos

1 Like

The SAS Viya 3.4 (July 2019 Update), introduced support for configuring Kerberos authentication within a multi-tenant environment. This means that with SAS Viya 3.4 (July 2019 Update) enables you to have Kerberos authentication for all of the tenants and the provider within your SAS Viya 3.4 environment. Combined with the updates introduced in the SAS Viya 3.4 (May 2019 Upgrade), this now means you can combine Kerberos, SAML, and OpenID Connect with your different tenants; so long as you are aware of how fall-back impacts the user experience. Kerberos is all or nothing, since enabling it on the provider protects all the UI endpoints across all tenants. In this article we will explore this in more detail.

For this article we will consider a case where we have different LDAP settings for the provider and each tenant. We will have a provider and three tenants; these tenants will be Dev, Test, and Prod. The same Active Directory will be used for all environments, just with a different objectfilter for each environment. The provider will only have members of the GEL_Provider group, Dev will have members of the GEL_DEV group, Test will have members of the GEL_TEST group, and Prod will have the members of the GEL_PROD group. The groups of users in GEL_DEV and GEL_TEST is distinct, while the GEL_PROD group contains all the members of GEL_DEV and GEL_TEST with additional members. So, the group structure looks 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.

Where the users highlighted in orange are members of the SAS Administrators groups in the provider or respective tenants.

The URLs of the environments will be:

Provider = https://sasviya01.gellab.net
Dev Tenant = https://dev.sasviya01.gellab.net
Test Tenant = https://test.sasviya01.gellab.net
Prod Tenant = https://prod.sasviya01.gellab.net

The aim for this scenario is to build on the previous scenario where we had:

LDAP authentication for the provider and DEV
OpenID Connect for TEST
SAML for PROD

Now we will, with SAS Viya 3.4 (July 2019 Update), add Kerberos authentication to all four environments. We will use Kerberos delegation to authenticate both to SAS Logon Manager and the downstream CAS and SAS Compute Server. This means that Kerberos can be used to launch either a SAS Cloud Analytic Services session or a SAS Compute Server session. Also, since SAS Viya 3.4 (May 2019 Upgrade) introduced Fall-back with Kerberos we can still use LDAP, OpenID Connect, or SAML to authenticate.

Considerations for Kerberos in Multi-Tenant

To be able to use Kerberos throughout the multi-tenant environment we want to be able to delegate and authenticate against SAS Logon Manager, SAS Launcher & Compute Servers, and the SAS Cloud Analytic Services Controller. For Kerberos authentication to operate we need to have a registered Service Principal Name (SPN) for each service that we want to authenticate to and a corresponding Kerberos keytab.

For SAS Logon Manager this SPN will be based on the URL entered in the browser. However, to make matters more complex each browser handles the resolution of the URL to the SPN slightly differently. Some browsers such as IE will just take the entered text, while other browsers such as Firefox will perform both a forward and reverse lookup to generate the SPN. This means that if you have used a CNAME DNS alias for your tenants the SPN returned will actually be for the A record instead. So, for our scenario if dev.sasviya01.gellab.net is a CNAME alias for sasviya01.gellab.net then Firefox will think the SPN is HTTP/sasviya01.gellab.net. Therefore, you should register HTTP SPNs for the provider and all tenants. If you are using Active Directory these should be registered against the same service account.

The SAS Logon Manager configuration for Kerberos authentication is performed at the provider and is then applied to all tenants. As such there is only a single Kerberos keytab required for SAS Logon Manager. This Kerberos keytab should contain all the SPNs for the provider and all the different tenants.

The SAS Cloud Analytic Services Controller for the provider and your tenants could either be located on the same host or on different hosts. If the SAS Cloud Analytic Services Controllers are running on the same host then only a single Service Principal Name (SPN) and corresponding Kerberos keytab will be required. Since, the different CAS instances are identified by their port numbers rather than a DNS alias.

If the SAS Cloud Analytic Services Controllers are running on different hosts then each CAS Controller will require a SPN to be registered and a corresponding Kerberos keytab. Remember the SPN is in the format sascas/<fully.qualified.hostname>. If you are using Active Directory ideally you will have a separate service account for each SAS Cloud Analytic Services Controller host. As the CAS Controllers are running on different hosts the default location, /etc/sascas.keytab, can be used for each of the CAS Controllers. Or alternatively, the environment variable KRB5_KTNAME can be used to point to the location of the keytab for each CAS Controller.

The SAS Launcher & Compute Servers will be running on the hosts defined in your inventory.ini for both the provider and tenants. If a single host is listed, then only a single SPN and corresponding Kerberos key tab is required for the provider and all tenants. If multiple hosts are listed, as with a non multi-tenant environment, multiple SPNs and Kerberos keytabs will be required. Although, all the SPNs could be included in the same Kerberos keytab if the SPNs are registered to the same service account.

Remember the SAS Environment Manager setting of kerberos.enabled=true under sas.compute is shared between SAS Cloud Analytic Services and SAS Launcher Server. So, setting this for one will also set it for the other. When this is set for the SAS Launcher Server you will only be able to launch a SAS Compute Server session with either a Kerberos credential or a stored credential under the DefaultAuth authentication domain. This means for example, that end-users in tenants who do not use Kerberos or do not have a credential stored in DefaultAuth will be unable to use SAS Studio 5.1.

Authentication Domains

SAS Viya 3.4 (July 2019 Update) now creates the Kerberos and DefaultAuth authentication domains within a tenant as part of the onboarding process. These two domains are crucial for the correct operation of Kerberos authentication within the tenant. Remember end-users or administrators can store credentials under DefaultAuth for either individual users or groups. Managing these credentials is covered in the documentation. The DefaultAuth credential will be used to either authenticate to SAS Cloud Analytic Services or the SAS Launcher Server if Kerberos is not used to authenticate to SAS Logon Manager.

Kerberos Configuration for SAS Logon Manager

The majority of the Kerberos configuration for SAS Logon Manager is completed in SAS Environment Manager within the provider. The configuration settings you need to complete are the standard options for to configured Kerberos, which are covered in the documentation. However, if you need to be able to support multiple different principals in the Kerberos keytab you need to set the servicePrincipal to * (star), as shown here:

In addition, with SAS Viya 3.4 (July 2019 Update) you must add an authorization rule into each tenant. Otherwise end-users will receive a 500 Internal Server Error Page when they attempt to use Kerberos to authenticate to SAS Logon Manager. The new authorization rule is for the Object URI of "/credentials/domains/kerberos/users/*" and grants create & delete for the user sas.logon. An example of creating the authorization rule is shown here:

This authorization rule will be created automatically as part of the tenant onboarding process with a future release of SAS Viya.

Kerberos Configuration for SAS Cloud Analytic Services

The Kerberos configuration for SAS Cloud Analytic Services must be completed in both the provider and each tenant. Within the provider the SAS Environment Manager setting under sas.compute of kerberos.enabled must be set to true. This will enable Kerberos authentication from the SAS Viya visual interfaces to SAS Cloud Analytic Services Controller.

Within each tenant the casconfig_usermods.lua must be updated to enable the Kerberos authentication provider, by adding the line

cas.provlist = 'oauth.ext.kerb'

Optionally, the environment variables for the Service Principal Name and Kerberos keytab location can also be set in the casconfig_usermods.lua.

This is essentially, the same steps that are covered in the documentation. Just that with a multi-tenant environment the edits of the casconfig_usermods.lua are made individually for each tenant.

Optionally, within each tenant the CASHostAccountRequired custom group must be created and populated with the end-user’s you want to use Kerberos Delegation to authenticate to CAS. Only members of the CASHostAccountRequired group will launch their CAS session as themselves. Otherwise the CAS session will run as the CAS operating system account for that tenant.

Kerberos Configuration for SAS Launcher & Compute Servers

The configuration of Kerberos for the SAS Launcher Server follows the documentation. Both the SAS Configuration Server key, providing the location of the Kerberos keytab, and the SAS Environment Manager setting, under sas.compute of kerberos.enabled=true, must be set within the multi-tenant provider. These settings will apply to all tenants in your multi-tenant environment.

Conclusion

Having completed all the above steps our multi-tenant environment will be configured for Kerberos authentication with fall-back. We will have:

Provider = https://sasviya01.gellab.net/SASEnvironmentManager = Kerberos with fall-back to LDAP form
Dev Tenant = https://dev.sasviya01.gellab.net/SASEnvironmentManager = Kerberos with fall-back to LDAP form
Test Tenant = https://test.sasviya01.gellab.net/SASEnvironmentManager = Kerberos with fall-back to OpenID Connect or LDAP form
Prod Tenant = https://prod.sasviya01.gellab.net/SASEnvironmentManager = Kerberos with fall-back to SAML or LDAP form