users, and client products such as SAS Enterprise Guide, I believe that SAS connection profiles are worth mentioning.
Logging In
When users log on to a client, or an admin logs on an admin tool – whether it is a desktop or web client – a connection profile is used. Then, users or admins connect to the metadata server. In order for the web or desktop clients to “find” the metadata server, we need the metadata server “address,” aka connection profile. The connection profile simply stores user credentials, ports, and server names. You can find the profiles in the following location for SAS Data Integration Studio, SAS Information Map Studio, SAS Management Console and SAS OLAP Cube Studio:
Windows Vista or later: C:\Users\user-name\AppData\Roaming\SAS\MetadataServerProfiles
UNIX: /user-home/SASAppData/MetadataServerProfiles.
The client profiles have the extension swa. Here is a snippet of a client profile:
port=8561
userid=sasdemo
Name=SASDemo
password={sas002}1D57933958C580064BD3DCA81A33DFB2
host=machine_name
In this profile, the user name and password are stored, which means the user will not be prompted. The users have the option to check a box during login that saves the user ID and password in their profile.
| Tip: If you would like to avoid that users have the option to check this check box, you can do the following:On your metadata server machine, go to sas_config_dir\Lev1\SASMeta\MetadataServer and open the file omaconfig.xml.Change the value for SASEC_LOCAL_PW_SAVE from 1 to 0, where 1 is YES and 0 is NO.Save your changes and close the file.Restart your metadata server for the changes to take effect. Please keep in mind that the restart of the metadata server will throw out all your users, meaning, their work will be interrupted. For that reason, you might want to choose a time where there is the least user traffic.This will disable the check box to save user ID and password from the profile. |
Quick excursion to SAS encryption
Looking at the client’s .swa file, you might notice the password:
password={sas002}1D57933958C580064BD3DCA81A33DFB2.
SAS encrypts password at rest and in transit. There are several encryption mechanisms available in SAS. Here, you see sas002, which is the default SAS encryption called SASProprietary, which is a fixed coding algorithm with medium security.
OK, that was the SAS Application Servers. Next, I would like to take a moment and look at the SAS Object Spawner.
Object Spawner
Another important SAS component that we must talk about when talking about SAS application servers is the Object Spawner. An object spawner runs on each machine where you want to run a workspace server, pooled workspace server or stored process server.
The Object Spawner’s task is it to launch a workspace server, pooled workspace server or stored process server, whenever one is requested. If a user accesses a table in SAS Enterprise Guide to work with it, the workspace server is used to execute the user’s job, right? Not quite. The component that actually starts a workspace server session is the Object Spawner.
Before the Object Spawner starts any of these application servers, it establishes a communication with the metadata server to check whether the requesting user has a valid user ID.
To be able to have a communication between the Object Spawner and the metadata server, the object spawner uses a configuration file that includes the information needed to access the metadata server. The configuration file is called metadataConfig.xml and is located at SAS-config-dir\Lev1\ObjectSpawner.
It includes the metadata server machine, the metadata server port and other information. Think of it as if you are giving someone your address to find you.
The SAS documentation uses the following figure to show how the spawner obtains metadata:
The object spawner accesses the metadataConfig.xml
The object spawner connects to the SAS Metadata Server for configuration information.
It is like me asking my German pal where I can get the best Bratwurst. She gives me the name of a store and I take that information to get to the store. (quite the example, isn’t).
Authentication and starting SAS Servers
Example for Workspace server:
Before the Object spawner starts a workspace server, the metadata server provides credential information and details about how to start the server. In a default scenario, the object spawner uses host authentication, which means the workspace server is started under the users’ credentials.
After the client – such as SAS Enterprise Guide – is exited, the workspace server session is closed. You can use token-authentication instead of host authentication. Token authentication uses a shared user and generates a single-use identity token.
Let’s take a look at it:
The steps in detail:
1 Using the already established connection to the metadata server, the SAS client, here the user is using SAS Enterprise Guide, requests access to a workspace serve (1)
2 In step 2, the metadata server searches the metadata (metadata repositories) for the workspace server in question.
3 The metadata server then gets the machine name hosting the workspace server, the Object Spawners’s port and an authentication domain that is associated with the workspace serve (we will address authentication domains in the security chapter).
4 This connection information is returned to SAS Enterprise Guide.
5 SAS Enterprise Guide uses the connection information to make the request for a workspace server. If the authentication domain for the server matches that of the initial inbound login, SAS Enterprise Guide passes along the credentials as well.
6 The authentication domain comes into play for the credentials that are being used. If the user ID is not associated with the default authentication domain (called DefaultAuth), SAS Enterprise Guide searches its in-memory list of credentials to find the user’s credentials with the appropriate authentication domain. If no user credential is found, SAS Enterprise Guide queries the metadata server for credentials for this user for that particular authentication domain (outbound login). If none is found, the user will be prompted for credentials.
7 The object spawner sends the user’s credentials to its authentication provider. The default authentication provider is the host. As shown in the graph above, different authentication providers can be used.
8 The authentication provider verifies that the credentials are valid.
9 The object spawner launches the workspace server. It uses the launch command that was retrieved from the metadata at start-up. The workspace server runs under the credentials provided by SAS Enterprise Guide, that have been authenticated
