SAS Viya 3.4 Multi-Tenant Authentication Options

[#1]

The SAS Viya 3.4 (May 2019 Upgrade) introduced support for configuring different SAML or OpenID Connect providers for each tenant. This means that SAS Viya 3.4 (May 2019 Upgrade) enables you to have either SAML or OpenID Connect configured for both the provider and all tenants or use a different configuration for the provider and each tenant. 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 the image to see a larger version.
Mobile users: To view the image, 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:

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

The aim for this scenario is to use LDAP authentication for the provider and DEV, use OpenID Connect for TEST, and then use SAML for PROD. To make configuring OpenID Connect and SAML easier the third-party provider for these authentication protocols is RedHat’s Keycloak project. Keycloak is configured with all the available Active Directory users, so anyone in AD can authenticate to Keycloak.

Realism of Scenario

Since, we’ve outlined the scenario we will attempt to configure – just how realistic is such a scenario? First for a use-case of dev, test, and prod it probably does not make a great deal of sense to switch between both SAML and OpenID Connect. Probably a more realistic scenario for dev, test, and prod is to use LDAP (the default) and one federated authentication provider. So, LDAP with either SAML or OpenID Connect.

However, perhaps for an organization hosting the different tenants for separate organizations it does make sense to have different federated authentication providers for each tenant. This combined with the tenant specific LDAP providers/settings for the Identities microservice allows for complete separation of authentication to each tenant, using a more cloud native authentication scheme for access to the SAS Viya web applications.

The scenario we have chosen will enable us to examine how the authentication mechanisms are configured.

Configuration of SAML

We will start by looking at SAML. As I’ve described in a previous article and as is covered in the documentation, there are two parts to the SAML configuration within SAS Viya. First you configure the Service Provider within SAS Viya and then you configure the link to the external Identity Provider.

With a Multi-tenant environment these two parts of the configuration take place in the provider, for the Service Provider, and in an individual tenant for the link to the external Identity Provider. This is unless you are configuring the same external Identity Provider for all tenants; in which case this is configured once in the provider. This means that sas.logon.saml is created in the multi-tenant provider SAS Environment Manager, while sas.logon.saml.providers.external_saml is created in the tenant SAS Environment Manager. When you configure sas.logon.saml, SAS Logon Manager will automatically prepend the tenant in front of the two key identifying properties; entityBaseURL and entityID.

The settings for sas.logon.saml within the multi-tenant provider are:

1. The entityBaseURL = https://sasviya01.gellab.net/SASLogon, the URL for SAS Logon Manager, remember SAS Logon Manager will automatically prepend the tenant
2. The entityID = SASViyaSAML, a unique string to identify the SAML Service Provider to the Identity Provider, remember SAS Logon Manager will automatically prepend the tenant
3. The serviceProviderCertificate, a TLS signed certificate used to validate the signatures of SAML requests and responses
4. The serviceProviderKey, an RSA private key paired with the serviceProviderCertificate used to generate the signatures of SAML requests and responses
5. The serviceProviderKeyPassword, an option passphrase for the serviceProviderKey if required
6. The signatureAlgorithm, defaults to SHA256, defines the algorithm used to generate the SAML signature
7. The option signMetaData, on/off switch to enable the Service Provider to sign its metadata
8. The option signRequest, on/off switch to enable the Service Provider to sign the SAML requests
9. The two socket timeouts
10. The option wantAssertionSigned, on/off switch to enable the Service Provider to request the SAML Assertions are signed by the Identity Provider

With the SAML Service Provider configured, the link to the external Identity Provider can be configured in the specific tenant. In our scenario the sas.logon.saml.providers.external_saml settings will be created in the Prod tenant. The settings for sas.logon.saml.providers.external_saml that are important are:

1. The emailDomain = gellab.net, this is a comma-delimited list of email domains that are valid with this Identity Provider
2. The idpMetadata, this can either be a link to the metadata supplied by the Identity Provider, in our case https://gellabdc1.gellab.net/auth/realms/GELRealm/protocol/saml/descriptor. Or this could be the actual XML content for the Identity Provider
3. The linkText option contains the text to display on the sign-in page
4. The option metadataTrustCheck, on/off switch to control if the Identity Provider certificate must be trusted
5. The option nameID, a SAML name format for the requested ID which must match the Identity Provider
6. The option showSamlLoginLink, on/off switch to control if the link is shown on the sign-in page
7. The option skipSslValidation, on/off switch to control is the Identity Provider certificate must be validated

With these settings defined for the multi-tenant provider and the tenant, SAS Logon Manager can be restarted. Once SAS Logon Manager has been restarted it will generate the SAML Service Provider metadata at: https://sasviya01.gellab.net/SASLogon/saml/metadata. This XML metadata can then be used later to configure the Identity Provider.

Once SAS Viya 3.4 has been configured for SAML, the SAML Identity Provider can be configured. For our case since we are using RedHat Keycloak we can import the XML metadata generated by SAS Logon Manager to configure the Service Provider within the Identity Provider. For other SAML Identity Providers this setup maybe manual, but the XML should provide all the required settings.

However, since the Service Provider was configured for the multi-tenant provider, but we want to use SAML from one of the tenants, some settings will need to be updated. The following properties will need to be updated:

1. The entityID = prod.SASViyaSAML, this is the string entered into the Service Provider configuration with the tenant name added to the front separated with a dot
2. The SingleLogoutService Location URLs, these need to have the URL updated to include the tenant name and the entityID updated so in our case these become: https://prod.sasviya01.gellab.net/SASLogon/saml/SingleLogout/alias/prod.SASViyaSAML
3. The AssertionConsumerService HTTP-POST Location URL, needs to be updated to include the tenant name and the entityID, so in our case this becomes: https://prod.sasviya01.gellab.net/SASLogon/saml/SSO/alias/prod.SASViyaSAML
4. The AssertionConsumerService URI Location URL, needs to be updated to include the tenant name and the entityID, so in our case this becomes: https://prod.sasviya01.gellab.net/SASLogon/oauth/token/alias/prod.SASViyaSAML

With this in place SAML authentication can then be carried out for the PROD tenant. End-users just have to select the link on the SAS Logon Manager sign-in form to be redirected to the Identity Provider. If you don’t want to have the end-user select the link you can set idpDiscovery.enabled to true under sas.logon.zone within the PROD tenant. Then, as described in my previous article, end-users will be prompted for their email address. If the email domain matches a value set for sas.logon.saml.providers.external_saml they will be redirected to the Identity Provider.

Configuration of OpenID Connection

For the TEST tenant we will configure OpenID Connect with the third-party RedHat Keycloak authentication provider. Unlike SAML there is only a single group of settings within SAS Viya 3.4. Therefore, nothing needs to be configured within the multi-tenant provider, everything will be configured within the TEST tenant.

With OpenID Connect, the flow of configuration is reversed. Where for SAML SAS Viya was configured first. In the case of OpenID Connect the third-party provider is configured first. Then SAS Viya is configured afterwards. The three important settings are:

1. Client ID, which is the unique identifier for the SAS Viya environment within the OpenID Connect provider also sometimes called the relyingPartyID. For example: Test.SASViyaOIDC
2. The redirect URIs, which are the valid URIs a browser can redirect to after login or logout, in our case: https://test.sasviya01.gellab.net/SASLogon/login/callback/external_oauth
3. The client secret or relyingPartySecret which is a shared secret between the OpenID Connect provider and the SAS Viya environment

In addition, depending on the OpenID Connect provider, it might be required to define the type of authentication flow and type of client. The OpenID Connect authentication flow we want to use is the "Authorization Code Flow". While, since the SAS Viya environment is able to protect its client secret, the type of client is "confidential".

In SAS Viya 3.4 (May 2019 Upgrade) the OpenID Connect settings are defined under sas.logon.oauth.providers.external_oauth in SAS Environment Manager. The configuration for an external OpenID Connect provider is covered in the documentation. The important settings are:

1. The attributeMappings.user_name = preferred_username, which defines the attribute returned by the OpenID Connect provider that should be mapped to the username attribute in SAS Viya
2. The authUrl, which points to the authorization endpoint for the external OpenID Connect provider which in our case is: https://gellabdc1.gellab.net/auth/realms/GELRealm/protocol/openid-connect/auth
3. The emailDomain = gellab.net, this is a comma-delimited list of email domains that are valid with this OpenID Connect provider
4. The issuer = https://gellabdc1.gellab.net/auth/realms/GELRealm, which is the principal for the OpenID Connect provider
5. The linkText option contains the text to display on the sign-in page
6. The relyingPartyId = Test.SASViyaOIDC, a unique string that identifies the SAS Viya environment in the OpenID Connect provider
7. The relyingPartySecret, which is a shared secret between the SAS Viya environment and the OpenID Connect provider
8. The tokenKey or tokenKeyURL, which is the public key used to sign tokens either directly entered into SAS Environment Manager or provided at the given URL, in our case this is tokenKeyURL= https://gellabdc1.gellab.net/auth/realms/GELRealm/protocol/openid-connect/certs
9. The tokenUrl, which is the endpoint on the OpenID Connect provider where tokens are issues, in our case: https://gellabdc1.gellab.net/auth/realms/GELRealm/protocol/openid-connect/token

Remember the attributeMappings.user_name setting will be unique to your chosen OpenID Connect provider; this will provide the attribute that the provider makes available in the claims about the authenticated user and must be something that SAS Logon Manager can map to the matching identity for the user.

Once the settings have been defined in the TEST tenant the operating system process for SAS Logon Manager must be restarted. Then OpenID Connect authentication can then be carried out for the TEST tenant. End-users just have to select the link on the SAS Logon Manager sign-in form to be redirected to the OpenID Connect provider. If you don’t want to have the end-user select the link you can set idpDiscovery.enabled to true under sas.logon.zone within the TEST tenant. Then, as described in my previous article, end-users will be prompted for their email address. If the email domain matches a value set for sas.logon.oauth.providers.external_oauth they will be redirected to the Identity Provider.

Considerations for Kerberos

So far, we have only considered SAML and OpenID Connect. With SAS Viya 3.4 (May 2019 Upgrade) these are the only supported authentication mechanisms other than LDAP. This means that with SAS Viya 3.4 (May 2019 Upgrade) Kerberos is not supported in a multi-tenant environment. However, it is expected that Kerberos will be supported in a multi-tenant environment with SAS Viya 3.4 (July 2019 Update). Therefore, expect to see further information on configuring Kerberos with a multi-tenant environment in future materials.

Conclusion

Having completed all the above steps, our multi-tenant environment will be configured for the three different authentication mechanisms. We will have:

1. Provider = https://sasviya01.gellab.net/SASEnvironmentManager = LDAP form
2. Dev Tenant = https://dev.sasviya01.gellab.net/SASEnvironmentManager = LDAP form
3. Test Tenant = https://test.sasviya01.gellab.net/SASEnvironmentManager = OpenID Connect
4. Prod Tenant = https://prod.sasviya01.gellab.net/SASEnvironmentManager = SAML

Once SAS Viya 3.4 (July 2019 Update) is available, we would also be able to configure Kerberos for one or more of the tenants as well.