BookmarkSubscribeRSS Feed

SAS Viya 3.5 Login with Email

Started ‎08-11-2020 by
Modified ‎08-11-2020 by
Views 2,975

Following on from looking at the setup of different OpenID Connect providers, such as OKTA, WSO2, and Ping Identity I want to discuss logging into SAS Viya 3.5 with an email address. Normally when considering environments linked to Active Directory or OpenLDAP the end-users will be expected to log in with their sAMAccountName or userID. Here, we will examine some of the considerations for when you want your users to log in with their email address instead. As more people move to using a federated authentication provider such as OpenID Connect or SAML, it becomes more common for the unique identifier for the end-users to be their email address.


In our discussions here we will focus on the impacts of wanting to authenticate users by their email address rather than individual pieces of configuration. We will look at the impact for accessing the visual interfaces, such as SAS Visual Analytics, accessing SAS Compute Server sessions, and accessing SAS Cloud Analytic Services.

Visual Interfaces

SAS Viya 3.5 uses the accountId attribute in the Identities microservice to identify the users. The default setting for this is sAMAccountName. When we change this to mail or email, whichever is the correct LDAP attribute, we change the way internally the user is identified within the SAS Viya 3.5 environment. Changing this attribute after the environment has started to be used by your end-users is not supported. This decision needs to be made before your end-users start to access your SAS Viya 3.5 environment.


For the SAS Viya 3.5 visual interfaces there is no difference between authenticating with sAMAccountName, uid, or email address.

SAS Compute Server sessions

The SAS Compute Server session is launched for users who have already authenticated to SAS Logon Manager and obtained an internal OAuth token. This token includes the accountId, and the value of the accountId, is used to launch the SAS Compute Server session. In a default configuration the accountId will be the sAMAccountName or uid, which will need to be valid on the operating system. If the accountId is changed to be the users email address further consideration needs to be made for how the SAS Compute Server session will be launched.


When authenticating to the SAS Launcher Server with an internal OAuth token, the value of the accountId is used to launch the process. This means that the Name Service Switch (NSS) system needs to recognize the value of the accountId as a valid operating system user. In most cases this will not work when the accountId is an email address, except for certain cases when System Services Security Daemon (SSSD) is used – which will be covered below.


If the accountId is not valid on the operating system, then an alternative authentication mechanism must be used for the SAS Launcher Server. The two choices are either a stored account or a service account. A stored account leverages the Credentials microservice and a valid operating system username and password are stored either individually against every user or against a group that users are a member of. These credentials are stored against the DefaultAuth authentication domain. Remember a single end-user should only have a single stored credential, either individual or through a group membership.


Alternatively, the service account which we have discussed previously, is applied to a Compute Context. This means that any user using that Compute Context will have the SAS Compute Server session run as the service account, but with access to the end-user’s internal OAuth token. Remember SAS Studio 5.2 Enterprise is only able to use a single Compute Context, so all the SAS Studio 5.2 Enterprise users would use the same service account. If some isolation between groups of users is required, it would be better to use a stored group credential instead of a service account.


For SAS Viya 3.5 authenticating with an email address means that credentials will need to be stored within the environment to successfully launch a SAS Compute Server session.

SAS Cloud Analytic Services

As we know, by default for users of the visual interfaces, SAS Cloud Analytic Services runs the end-user sessions as the CAS service account. The end-users are authenticated using their internal OAuth token and a session is launched for the end-user. The CAS controller does create a user directory under /opt/sas/viya/config/data/cas/default/casuserlibraries. This directory will be named as per the accountId from the internal OAuth token. So, for end-users authenticating with an email address only the name of this directory will be different. The directory will still be owned by the CAS service account.


However, the situation is different for end-users who either make direct connections to the CAS controller or who request a host-launched session. Direct connections to the CAS controller could be from programming languages such as Java, Python, Lua, and also from SAS Studio 5.2 Basic or SAS 9.4. With a direct connection the CAS controller first authenticates against the operating system and then authenticates against SAS Logon Manager. Obviously if SAS Logon Manager only recognizes email address and the operating system does not these two linked authentication steps will fail. The only option would be to enable the operating system to authenticate end-users with email addresses, see some details on SSSD below.


Users who request a host-launched session are accessing CAS from the visual interfaces and have already authenticated with their email address to SAS Logon Manager. So, their internal OAuth token contains their email address, and this is passed to the CAS controller. If the email address is not valid for starting a process on the operating system, a stored credential will be required. Just like the SAS Launcher Server, the CAS controller can leverage a credential stored against DefaultAuth for either the individual or a group.


For SAS Viya 3.5 authenticating with an email address to SAS Cloud Analytic Services is much more complex. The solution will depend both on the type of client and the type of session requested.


The System Services Security Daemon (SSSD) has a number of different providers that can be used for both authentication and identification of users. The Active Directory provider searches for matching users using sAMAccountName, UserPrincipalName, and email address. This means that SSSD with the AD provider is able to both identify and authenticate users with their email address. This is independent of how the username is displayed for things like file listings.


This means that if the end-users who authenticate to SAS Viya 3.5 using their email address are referenced in Active Directory, they can still use SSSD. So, a SAS Compute Server session, or a host-launched CAS session can be correctly launched using the email address of the Active Directory user. Since SSSD will still identify the end-user via their email address.


With SAS Viya 3.5 authenticating with an email address is possible, but some consideration needs to be given to how users will launch either SAS Compute Server sessions or CAS sessions. The next release of SAS Viya introduces further enhancements to streamline the process of launching sessions for users.


In the discussion of sssd, you say the ad provider use sAMAccountName, UPN, and email address.   Can you give a reference to where in the sssd doc this is discussed?   Is there an option to choose which of the three is used?  Or does it try each in turn?  

We are using SAML to logon, but I am having trouble getting the launcher service  to allow the user to launch.   We are using kerberos constrained delegation, and whenI use sas.logon.kerberos, everything works fine.  But the organization wants to use SAML to logon.   I can get saml to allow the login.  But not to launch sas studiov.

Hello @CarlZeigler ,


I did have a quick look in the AD Provider documentation for SSSD and couldn't find a description of this.  I found this by examining the debug logging for SSSD.  Also for writing this answer I created a Test User in my Active Directory with the following attributes:

From a Linux host joined to the domain and using the AD Provider for all SSSD provider options (essentially the default sssd.conf after using realm join - just with use_fully_qualified_names = False set) I was able to run the following:


getent passwd testuser
testuser:*:1094009125:1094000513:Test User:/home/testuser:/bin/bash

getent passwd testuserUPN@GELLAB.NET
testuser:*:1094009125:1094000513:Test User:/home/testuser:/bin/bash

getent passwd
testuser:*:1094009125:1094000513:Test User:/home/testuser:/bin/bash


Which you can see SSSD is showing all three forms to be the same user since the numerical uid is the same.  I was then also able to SSH to the Linux host and successfully authenticate with any of those three forms of the username.


For your specific issues with your environment I would encourage you to open a Technical Support ticket so that you can work through the details with them.


Thank you for your time.





Version history
Last update:
‎08-11-2020 05:43 AM
Updated by:



Secure your spot at the must-attend AI and analytics event of 2024: SAS Innovate 2024! Get ready for a jam-packed agenda featuring workshops, super demos, breakout sessions, roundtables, inspiring keynotes and incredible networking events.


Register by March 1 to snag the Early Bird rate of just $695! Don't miss out on this exclusive offer. 


Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags