SAS Viya 3.4 Authentication Overview

[#1]

In this article, I would like to provide an overview of the authentication options available with SAS Viya 3.4. We will review options available to log into the environment with SAS Logon Manager, known as in-bound authentication. Then we will examine the options available to authenticate out to SAS Cloud Analytic Services or the SAS Compute Server from the visual interfaces, known as out-bound authentication. Finally, we will consider the programming clients connecting to SAS Cloud Analytic Services.

So just from the introduction above some of you might be confused using in-bound and out-bound. In-bound is probably the easiest to understand; this is the authentication process to get into the SAS Viya environment. While using out-bound for the authentication to SAS Cloud Analytic Servers and SAS Compute Server is possibly more contentious.

I take "out-bound" to be any downstream authentication process that occurs after the initial authentication. With such a definition the authentication to SAS Cloud Analytic Services and SAS Compute Server are clearly "out-bound". Equally, then any authentication from the sessions launched by these components to third-party data sources will equally be considered "out-bound".

Types of Deployment

Before we dive into looking at the options for authentication we need to define some terms to help us describe the type of SAS Viya 3.4 environment. The first of these is the type of deployment. With SAS Viya 3.4 we can have two different types of deployment:

1. Full Deployment
2. Programming Only

As the name suggests the full deployment is a deployment of all the different components that make up the ordered SAS Viya 3.4 environment. This includes SAS Cloud Analytic Services, the microservices, stateful services, and SAS Programming Runtime Environment parts used by SAS Studio 4.4.

The programming only deployment more closely resembles the deployment we saw with the first SAS Viya release; so, this includes SAS Cloud Analytic Services and all the parts for SAS Studio 4.4 to function. A programming only deployment does not include the microservices and stateful services. The only interaction with SAS Cloud Analytics is via SAS Studio 4.4 and the code end-users run within this.

Types of Interfaces

Following on from the type of deployment, we can classify the end-user interfaces to access the SAS Viya 3.4 environment. The interface could be a visual interface or a programming interface. For a visual interface, we group all the SAS Viya 3.4 web applications including SAS Studio 5.1 but excluding SAS Studio 4.4. While for a programming interface we mean SAS Studio 4.4. Equally within programming interface, when we say a programming interface accesses SAS Cloud Analytic Services we could also mean the Python, Lua, or Java interfaces.

Equally since the release of the fifth maintenance release of SAS 9.4 we can interact directly with SAS Cloud Analytic Services. Previously, this interaction was based around the use of SAS/CONNECT and remote submitting code to the SAS Viya programming interface. While with SAS 9.4 M5 we can now directly connect to SAS Cloud Analytic Services from SAS Foundation. So, a third type of interface for us to consider is the SAS 9.4 M5 client.

In-bound Authentication to SAS Logon Manager

Let’s start with a picture that should be familiar from previous releases (SAS Viya 3.3 and SAS Viya 3.2😞

Click images to see a larger version of each

The first thing to point out and something to keep remembering all of the time is the following:

The identities microservice always must connect to an LDAP provider to obtain user and group information.

This LDAP provider could be Microsoft Active Directory or any other LDAP provider such as OpenLDAP.

So, what are our options for authenticating the users accessing SAS Logon Manager? We have six options with the SAS Viya 3.4:

1. LDAP Provider (the default option)
2. Kerberos or Integrated Windows Authentication
3. OAuth/OpenID Connect
4. SAML
5. Multi-factor Authentication (Introduced with SAS Viya 3.3)
6. SAS 9.4 Single Sign-on/out

Option 1 is the default authentication mechanism enabled out-of-the-box for SAS Viya 3.4 is the LDAP Provider. The same connection details used by the identities microservice are used by SAS Logon Manager to authenticate the credentials the end-user enters in the logon form. From a security perspective, we need to be concerned about what network connections these end-user credentials will be sent over. First, we have the network connection between the browser and the HTTP proxy, which is secured by default with HTTPS in SAS Viya 3.4. Then we have the network connection between SAS Logon and the LDAP Provider, here we can support TLS to encapsulate the LDAP connection using either LDAPS or startTLS.

Option 2 as shown in the diagram is to configure SAS Logon Manager for Kerberos authentication. This provides the end-user with Single Sign-On from their desktop where the browser is running. This is sometimes referred to as Integrated Windows Authentication (IWA). This will enable the end-user to access the SAS Viya 3.4 visual interfaces without being prompted to enter any credentials. However, it is important to remember that the identities microservice will still be connecting to the LDAP provider. The Kerberos authentication option completely replaces the option to use the default LDAP provider for the SAS Logon Manager. Introduced with SAS Viya 3.3 is the option to delegate the credentials to SAS Logon Manager to make them available to out-bound processes, more on this option below.

Option 3 enables the SAS Logon Manager to be integrated with an alternative OAuth/OpenID Connect provider. This provider could be something internal to the customer’s wider environment or could be external to the customer such as Google Sign-in of Facebook Login. When the OAuth/OpenID Connect option is configured this does not completely replace the default LDAP provider. Instead when the end-user accesses the SAS Logon Manager they are presented with a link to authenticate using OAuth/OpenID Connect and the standard login form using the LDAP provider. The end-user can then select which to use. This option can provide single sign-on from the OAuth/OpenID Connect provider; so, for example sign into your Google account and access the SAS Viya 3.4 visual interfaces without further prompting for credentials. Custom code can be added to the SAS Logon Manager login form that automatically links to the external OAuth/OpenID Connect provider making the single sign-on more seamless, since there is no need to select the link.

Option 4 supports configuring the SAS Logon Manager to be integrated with an external SAML Identity Provider. This SAML Identity Provider could be internal or external to the customer’s wider environment. If it is internal it could be something like Oracle Access Manager or Active Directory Federation Services, whilst if its external it could be something like salesforce.com. Again, like option 3 the use of SAML does not completely replace the default LDAP provider. End-users accessing the SAS Logon Manager will be able to choose SAML authentication or the default LDAP provider. Also, this option provides single sign-on with the third-party SAML provider. Custom code can be added to the SAS Logon Manager login form that automatically links to the external SAML provider making the single sign-on more seamless, since there is no need to select the link.

Option 5 supports the use of Multi-factor authentication with SAS Logon Manager. This was introduced with SAS Viya 3.3 and requires the configuration of a third-party Pluggable Authentication Module (PAM). This PAM module is the part of the system that integrates with the multi-factor authentication provider such as Symantec’s VIP. The PAM module authenticates the end-user by causing the third-party to push an out-of-band validation request to the end-user. Normally, this would be a push message to a smart phone application, approving the request forms the additional factor in the authentication of the end-user. When an end-user enters their username and password in the SAS Logon Manager form they are checked against the PAM provider. This means this option replaces the LDAP provider, just as with Kerberos.

Option 6 supports the use of an existing SAS 9.4 environment for the authentication of the end-users. This supports the use of any maintenance release of SAS 9.4, and does not have to be the latest SAS 9.4 release. The configuration, causes the authentication of the end-user to be perform by the SAS Logon Manager running on SAS 9.4. The SAS Viya 3.4 Logon Manager redirects to SAS 9.4 and then after the end-user is authenticated processes the SAS 9.4 authentication ticket to generate a SAS Viya internal OAuth token. As well as supporting single sign-on, where end-users only must log into SAS 9.4 to access both SAS 9.4 and SAS Viya, the configuration supports single sign-out. Single sign-out means that logging out from either SAS 9.4 or SAS Viya will log out the end-user from the other SAS environment.

Given the six different options for authentication to SAS Logon Manager in SAS Viya 3.4, next we will examine what occurs after the authentication. The diagram below uses a process flow style to attempt to illustrate what happens.

First if we consider the case where we have configured Kerberos authentication for SAS Logon Manager, option 2 above. We show the validation of the service ticket using the configured Kerberos keytab file. Then we consider if Kerberos delegation has been configured. If delegation is configured, then the credentials microservice is leveraged to store the delegated credentials provided to SAS Logon Manager.

Then either with or without delegation SAS Logon Manager constructs the internal OAuth token. This requires the end-users group information, which is provided by the identities microservice. The group information includes both the LDAP and custom groups. In the diagram below we specifically call out the custom group CASHostAccountRequired, as this will be important later. All the groups, LDAP and custom, the end-user is a member of are added as claims to the internal OAuth token.

Essentially, the second half of the diagram, where any authentication option other than Kerberos is used, is the same as the case with Kerberos. The end-user credentials are validated and then the internal OAuth token is generated. Again, with the end-users group information included in the claims in the OAuth token.

Out-bound Authentication to SAS Cloud Analytic Services

In previous releases the authentication to SAS Cloud Analytic Services from the visual interfaces was quite straightforward. Either Kerberos delegation was used or the internal OAuth token was used. With Viya 3.4 we have a few more different ways the authentication could occur.

The diagram below captures the flow deciding what type of authentication should be used. Each of the end-points then corresponds to a different scenario. The scenarios have their own diagrams showing the flow of authentication information for that specific scenario.

The first decision point is the membership of the custom CASHostAccountRequired group. Without membership in this group the end-user is authenticated with their internal OAuth token and the SAS Cloud Analytic Services session will be launched using the service account. Shown as scenarios 1a and 1b below:

Scenario 1a

Scenario 1b

 

Things become more complex when the end-user is a member of CASHostAccountRequired. Being in this custom group means that we want the SAS Cloud Analytic Services session to run as the end-user. The next decision point is if Kerberos has been configured for SAS Cloud Analytic Services. A new configuration setting is used to turn on Kerberos authentication to SAS Cloud Analytic Services.

If the Kerberos-enabled configuration setting is not present or false, then delegated Kerberos authentication will not be attempted and some alternative mechanism must be used to launch the session. Introduced with Viya 3.4 is the ability to store username and passwords with the credentials microservice. If credentials have been made available to the end-user, either individually or through a group membership, these can be used to launch the SAS Cloud Analytic Services session. Such credentials will be used with the PAM configuration for SAS Cloud Analytic Services to authenticate to the operating system. Shown as scenario 1c below:

Scenario 1c

If credentials are not available, then since the operating system is Linux, SAS Cloud Analytic Services is able to just launch the process as the end-user identified by the username in the internal OAuth token. This means that the name from the OAuth token must be valid on the operating system for this to succeed. Shown as scenario 1d below:

Scenario 1d

If the Kerberos-enabled configuration setting is present and set to true, then delegated Kerberos authentication will be attempted. The SAS Cloud Analytic Services client in the web application is responsible for retrieving the delegated Kerberos credentials stored by SAS Logon Manager. Remember the security rules ensure only the end-user who owns the Kerberos credentials can retrieve them.

On the bottom part of the diagram above we illustrate the Kerberos connection. The delegated credentials are used to request a Service Ticket for connecting to SAS Cloud Analytic Services. The CAS Controller is provided with a Kerberos keytab, that is used to validate the presented Service Ticket. If this is successful the CAS session is launched as the end-user and their Kerberos credentials made available to the session, as shown as scenario 1 below:

Scenario 1

However, the Kerberos credentials stored by SAS Logon Manager can expire or otherwise be invalid. If these cannot be used to authenticate the end-user to SAS Cloud Analytic Services an alternative is needed. As before if a username and password have been stored for the end-user these can be used to authenticate, as shown in Scenario 1c.

Then finally, if Kerberos is not successful and no username and password are stored, since the CAS Controller is running on Linux it is able to directly launch the session as the end-user. As before this takes the username from the internal OAuth token. This username must be valid on the operating system. This is shown as Scenario 1d above.

Out-bound Authentication to SAS Compute Server

In previous releases the authentication out-bound from the visual interfaces to the SAS Compute Server, via the SAS Launcher Service, was straightforward. The SAS Launcher Service used the internal OAuth token to connect to the SAS Compute Server; where a direct launch leveraging the username in the OAuth token was used.

With SAS Viya 3.4 the options we have explored for SAS Cloud Analytic Services are also available for the SAS Compute Server. However, there are some slight differences, as shown below:

The SAS Compute Server always attempts to launch a server as the end-user; unlike SAS Cloud Analytic Services. Therefore, there is no equivalent of the CASHostAccountRequired group for the SAS Compute Server. The key consideration with the SAS Compute Server is that the SAS Launcher microservice is performing all of the checks and the actual authentication to the SAS Launcher Server. The SAS Launcher Server after successful authentication starts the SAS Compute Server session.

As with SAS Cloud Analytic Services a single configuration option, sas.compute.kerberos.enabled, is used to enable Kerberos authentication. This option is shared with SAS Cloud Analytic Services, so enabling Kerberos for one enables Kerberos for the other.

Equally, if Kerberos is not configured, a similar route is taken with the SAS Launcher microservice attempting to retrieve a username and password from the credentials microservice. If a username and password is stored for the end-user this will be leveraged by the SAS Launcher microservice to connect to the SAS Launcher Server. The SAS Launcher Server uses the sasauth-spre PAM configuration to validate the credentials and launcher the SAS Compute Server. As shown in scenario 2 below:

Scenario 2

If a stored username and password are not available, the SAS Launcher microservice uses the internal OAuth token to connect to the SAS Launcher Server. The SAS Launcher Server then direct launches the SAS Compute Server session for the end-user using the username from the internal OAuth token. So, the username from the internal OAuth token must be valid on the operating system. This is shown as scenario 3 below:

Scenario 3

If Kerberos is configured through sas.compute.kerberos.enabled, the SAS Launcher microservice retrieves the delegated Kerberos credentials for the end-user from the credentials microservice. These are used to authenticate from the SAS Launcher microservice to the SAS Launcher Server. The SAS Launcher Server is provided with a Kerberos keytab to validate the Service Ticket. If the end-user is authenticated using Kerberos the SAS Compute Server session is launched and their Kerberos credentials delegated onto the SAS Compute Server session. As shown in Scenario 1 above.

If the delegated Kerberos credentials have expired or are not available, the SAS Launcher microservice will attempt to retrieve a stored username and password available to the end-user. If this stored username and password is available, as before they are used to connect to the SAS Launcher Server which in turn starts the SAS Compute Server session. The username and password are validated using PAM, and if PAM has been configured for Kerberos this will generate a Kerberos credential for the SAS Compute Server session. This is shown as Scenario 1a above.

If, however, the stored username and password are not available, and no delegated Kerberos credential is available the SAS Launcher microservice will fail to launch a SAS Compute Server session. The logic being that the Administrator configured Kerberos, which we cannot use, and there are no other credentials available, so the session launch fails, and the client application returns an error to the end-user.

Remember with SAS Viya 3.4 this process using the SAS Launcher microservice and SAS Launcher Server is used for session launch when the end-user accesses SAS Studio 5.

Programming Interfaces Authentication

Now we’ve looked at the visual interfaces for SAS Viya 3.4 what about the programming interfaces or SAS Studio 4.4? Unlike SAS 9.4, SAS Studio 4.4 with SAS Viya 3.4 is not integrated with the SAS Logon Manager. The following diagram illustrates the case with SAS Studio 4.4.

SAS Studio 4.4 in the full deployment is integrated with the HTTP Proxy so with SAS Viya 3.4 end-users do not directly connect to the SAS Studio 4.4 web application. The username and password entered into SAS Studio 4.4 are not passed to the SAS Logon Manager to authenticate. Instead the SAS Object Spawner uses the PAM configuration on the host to validate the username and password. This could be a local account on the host or, depending on the PAM configuration, an account in an LDAP Provider. This authentication is sufficient to start the SAS Workspace Server where the code entered in SAS Studio 4.4 will be run.

When the SAS Workspace Server connects to the SAS Cloud Analytic Services environment it uses the username and password that were used to start the SAS Workspace Server. The CAS Controller uses its own PAM configuration to validate the end-user’s credentials and launch the session process running as the end-user.

Since SAS Cloud Analytic Services is integrated into the visual components, and the username and password are passed from the SAS Workspace Server the CAS Controller uses them to obtain an internal OAuth token from the SAS Logon Manager. This means that the username and password must be valid in the provider configured for the SAS Logon Manager otherwise CAS will not be able to obtain an OAuth token and the session launch will fail.

Therefore, it makes sense in such a deployment for all the three components:

1. PAM for SAS Studio (sasauth-spre*)
2. PAM for CAS (cas)
3. SAS Logon Manager

to all use the same LDAP Provider. If these three components are not sending the username and password entered in SAS Studio 4.4 to the same place, we are likely to see errors when trying to connect.

SAS 9.4 Clients

Prior to Maintenance 5 of SAS 9.4 all SAS 9.4 clients leverage the SAS/CONNECT bridge to interact directly with SAS Cloud Analytic Services. So, SAS/CONNECT is used to initialize a SAS Foundation session within the SAS Viya environment and this SAS Foundation session connects to SAS Cloud Analytic Services. SAS/CONNECT in SAS Viya leverages the operating system to authenticate the end-users. This username and password is then cached and can be used to authenticate to SAS Cloud Analytic Services. Alternatively, an authinfo file can be created in the end-user’s home directory within SAS Viya to provide credentials to authenticate to SAS Cloud Analytic Services.

Since the release of Maintenance 5 for SAS 9.4, the SAS Foundation session in SAS 9.4 M5 directly connects to SAS Cloud Analytic Services. There are several options for how this SAS Foundation session authenticates to SAS Cloud Analytic Services:

1. Use cached credentials from the initialization of the SAS 9.4 M5 session
2. Use stored credentials in the SAS 9.4 M5 Metadata Server
3. Use stored credentials in an authinfo file either in the end-user’s home directory or a specified location
4. Use Kerberos credentials available to the SAS 9.4 M5 session
5. Use a SAS 9.4 M5 One-Time-Password to connect to SAS Cloud Analytic Services

The authentication of the SAS 9.4 M5 session to SAS Cloud Analytic Services is separate to any configuration of SAS Viya Logon Manager. Since the SAS 9.4 M5 session directly connects to SAS Cloud Analytic Services. However, SAS Viya Logon Manager is still involved. SAS Cloud Analytic Services in a full deployment will still connect to SAS Viya Logon Manager to obtain an internal OAuth token during the start-up. This will be with the credentials provided to SAS Cloud Analytic Services by the SAS 9.4 M5 session.

For the first three options listed above, the SAS 9.4 M5 uses a username and password to authenticate to SAS Cloud Analytic Services. Irrespective of the configuration of SAS Logon Manager for browser sessions these username and password credentials are still validated against the LDAP provider. So, care needs to be taken to ensure the username and password are valid within the LDAP provider.

For both Kerberos and One-Time-Passwords the configuration of SAS Viya Logon Manager is important. For Kerberos to work correctly SAS Viya Logon Manager must be configured for Kerberos authentication. While for One-Time-Passwords to be validated SAS Viya Logon Manager must be configured with details of the SAS 9.4 M5 Middle-Tier. Both scenarios have been explored,