SAS Viya 3.2 Authentication Options
In this post I want to take an overview of the authentication options available with SAS Viya 3.2. SAS Viya 3.2 is the first main release with the new microservices architecture and presents more options for authentication than previous releases. In this post we will not delve into the details of configuring each of the options, these details will form the basis for future posts.
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.2 environment. The first of these is the type of deployment. With SAS Viya 3.2 we can have three different types of deployment:
- Full Deployment
- Programming Only
- Visual Only
As the name suggests the full deployment is a deployment of all the different components that make up the ordered SAS Viya 3.2 environment. This includes SAS Cloud Analytic Services, the microservices, stateful services, and SAS Foundation parts used by SAS Studio.
Whilst the programming only deployment more closely resembles the deployment we saw with SAS Viya 3.1; so this includes SAS Cloud Analytic Services and all the parts for SAS Studio 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 and the code end-users run within this.
Finally, the visual only deployment excludes the parts for SAS Studio. With the visual only deployment the only interaction with SAS Cloud Analytic Services is via the SAS Viya 3.2 web applications such as SAS Visual Analytics.
Types of Interfaces
Following on from the type of deployment is a way to classify the interface the end-user accesses to use the SAS Viya 3.2 environment. The interface could be a visual interface or a programming interface. For a visual interface we group all of the SAS Viya 3.2 web application excluding SAS Studio. While for a programming interface we mean SAS Studio. 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.
Visual Interfaces Authentication
So the big change for SAS Viya 3.2 is the introduction of the visual interfaces and their integration with both the stateful services and microservices. The way the end-user authenticates to the visual interfaces is via the SAS Logon Manager. The SAS Logon Manager is accessed via the HTTP Proxy. The following picture summarizes the options for authenticated to the SAS Logon Manager in SAS Viya 3.2.
The first thing to point out and something to keep remembering all of the time is the following:
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 four options with the SAS Viya 3.2 release:
- LDAP Provider (the default option)
- Kerberos or Integrated Windows Authentication
- OAuth/OpenID Connect
- SAML
Option 1, the LDAP Provider is the default authentication mechanism enabled out-of-the-box for SAS Viya 3.2. 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 we can secure with HTTPS. Then we have the network connection between SAS Logon and the LDAP Provider, here we can support LDAPS to encapsulate the LDAP connection in standard TLS encryption.
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.2 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.
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 Auth of Facebook. 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.2 visual interfaces without further prompting for credentials.
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, 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.
With all four options the connection to the SAS Cloud Analytic Services environment is performed using internal OAuth tokens generated by the SAS Logon Manager. In most cases the actual session started by the CAS Controller will now run on the operating system as the same user who launched the SAS Cloud Analytics Services operating system service. This account defaults to the name cas.
Programming Interfaces Authentication
Now we’ve looked at the visual interfaces for SAS Viya 3.2 what about the programming interfaces or SAS Studio. Unlike SAS 9.4 SAS Studio with SAS Viya 3.2 is not integrated with the SAS Logon Manager. The following diagram illustrates the case with SAS Studio.
SAS Studio in the full deployment is integrated with the HTTP Proxy so with SAS Viya 3.2 end-users do not directly connect to the SAS Studio web application as they did in previous releases. However, the username and password entered into SAS Studio 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 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-users credentials and launch the session process running as the end-user.
At this point in a full deployment with microservices the CAS Controller does operate differently to previous releases. SAS Cloud Analytic Services is integrated into the visual components and so as 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:
- PAM for SAS Studio (sasauth)
- PAM for CAS (cas)
- 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 to the same place we are likely to see errors when trying to connect.
Programming Only Deployment
The final case I want to mention is that of a programming only deployment. In this case we have SAS Studio and SAS Cloud Analytic Services but we don’t have any microservices or stateful services. So here all authentication is via the PAM configuration for SAS Studio and SAS Cloud Analytic Services. Since CAS knows there are no microservices it does not attempt to obtain an internal OAuth token from the SAS Logon Manager. This means we are back in the same type of setup we had for SAS Viya 3.1.
Conclusion
I hope that this overview has provided some context to the different types of authentication happening within a SAS Viya 3.2 deployment. Understanding the types of authentication available will be important for helping you to select the best options for your environment. In future posts we’ll look at the different options in more detail.
Stuart Rogers
