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.
SSSD
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.
Conclusion
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.
