My post SAS Workload Orchestrator: Introduction to Authentication introduces general concepts about SAS Workload Orchestrator authentication and explains that all of its REST endpoints require authentication. This post will cover in more detail the default authentication method, HTTP Basic Authentication.
As we have seen in the first post, SAS Workload Orchestrator uses the HTTP protocol through REST interfaces for every communication channel, either with clients or between peer services. All the REST endpoints are protected and require authentication. SAS Workload Orchestrator supports two authentication schemes:
Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the Basic keyword, followed by a space and a base64-encoded string in the form username: password. It is important to understand that this is "encoding", not "encrypting". The original string can always be decoded to get back the plain version of the username and password.
For example, if the username is sasadmin and the password is saspassword, you can easily encode the credentials for basic authentication on any Linux host :
In the same way, if anyone intercepts the network communication with the SAS Workload Orchestrator and extracts the Authentication header, it's easy for them to get back the original credentials:
It's easy to understand now that basic authentication is equivalent to sending your credentials in clear; it is therefore a good practice to configure TLS (HTTPS) to encrypt all communication, including the authorization header. You can find further details on TLS encryption for SAS Workload Orchestrator in different community articles, including SAS Workload Orchestrator Options for Availability and Encryption, SSL Encryption for SAS Grid Manager and High Availability and TLS with SAS Workload Orchestrator.
SAS Workload Orchestrator is configured by default with support for Basic authentication. It is always accepted and works out of the box. There is only one requirement: ensure that a proper Authentication Domain, such as DefaultAuth, is specified in metadata in the properties of the Connection of the Grid Server, as shown in the following picture:
Do not select <none> as an authentication domain, since that is one trigger to turn on Kerberos Authentication.
Grid clients can retrieve the username and password, to send to SAS Workload Orchestrator, in different ways:
Not all options are available to all clients. My post SAS Workload Orchestrator: Introduction to Authentication includes a summary by client.
Here is an example of retrieving credentials from metadata. When using SASGSUB, you can specify
-METAUSER student to connect to metadata with user account student to get grid information from a SAS Application Server Context (like SASApp). If the SASApp application server context has a logical grid server whose connection object has the authentication domain DefaultAuth, SASGSUB will look in the student accounts searching for one that is valid for the DefaultAuth domain. If found, it will retrieve and use the username and password stored there:
Authinfo files are the same kind of files used by SAS Viya clients to connect to CAS server, as documented here.
Clients look for authinfo files in default locations, such as the $HOME directory on Unix (i.e. /home/student) , or the %HOMEPATH% directory on Windows (i.e. C:\Users\student\ ). It is also possible to specify a custom authinfo path using the AUTHINFO environment variable, AUTHINFO SAS option or AUTHINFO command-line option, depending on the client.
When configured to use the grid load-balancing algorithm, the SAS object spawner connects to the SAS Workload Orchestrator with a service account in order to obtain information about the grid. With basic authentication, this service account can assume different identities, depending on the credential retrieval method.
The SAS object spawner can use the credentials that are available in metadata for the SAS Trusted User for the grid’s authentication domain. By default, this corresponds to the sassrv OS account, saved under the SAS General Servers metadata group:
The SAS object spawner queries the grid for information that is only available to administrative accounts: for this reason, this OS identity (as we have seen, by default sassrv) must be configured as a grid administrator.
As an alternative, the SAS object spawner can use the credentials stored in an authinfo file. The owner of the SAS object spawner process is the SAS installer user on Unix, so the authinfo file has to be saved in this user's home directory. By default, the SAS installer is also a grid administrator, so there is nothing else to configure in this case.
Independently from all of the above, when it's time to start grid-launched servers, the SAS object spawner performs additional REST calls and connects to the grid with the end-user’s username and password. This happens in order to execute the grid job as them and is possible because the SAS object spawner gets end-users' credentials from the client application where the end-user initially logged in (such as SAS Enterprise Guide).
Basic authentication is the default and simplest method to authenticate to SAS Workload Orchestrator. A more robust and secure method is provided by the Kerberos protocol. More details on Kerberos authentication will be covered in another article.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.