Server Configuration, Data Retrieval, and Risk

Identity Passing

	About Identity Passing
	How SAS Servers Preserve Identity

About Identity Passing

When a request is passed from one system to another, it is often preferable that the requesting user identity is passed along with the request. This provides individualized access control evaluations and individual accountability in the receiving system. Here are a few examples:

When a stored process server is launched, it has to use some SAS identity to contact the metadata server in order to discover any pre-assigned libraries.
When a user opens a SAS folder that contains cubes, the OLAP server has to use some SAS identity to contact the metadata server to determine which cubes to show to that user.
When a workspace server fetches SAS data from the operating system, it has to use some host identity to authenticate to the operating system and request the SAS data set files.

In each example, the identity that is used affects the outcome (for example, which libraries are available, which cubes are visible, or which data files are returned).

How SAS Servers Preserve Identity

The following table provides details about how SAS servers preserve identity.

Preservation of User Identity
Server	SAS Identity for Metadata Layer Evaluations	Host Identity for Host Layer Evaluations
OLAP server	The SAS Trusted User. However, user identity is preserved because this privileged service identity impersonates each requesting user.¹	The server's host identity. This affects drilling to detail if the underlying data is in SAS tables.
Stored process server	Each requesting user's SAS identity. The exception is for library pre-assignment, which happens under the server identity.²	The server's host identity (the multi-user credential).
Workspace server (using any form of host authentication)	The SAS identity of the server. This is the same as the SAS identity of the requesting user or group.	The server's host identity (the host identity of the requesting user or group).³
Workspace server (using SAS token authentication)	Each requesting user's SAS identity.	The server's host identity (the launch credential).
Pooled workspace server	Each requesting user's SAS identity.	The server's host identity (the launch credential).
Client-pooled workspace server	The SAS identity of the server. However, SAS Web Report Studio pre-processes requests based on each requesting user's SAS identity.	The server's host identity (the puddle login).
1 Except for retrieval of DBMS credentials, which happens under the SAS Trusted User's identity. This affects drilling to detail if the underlying data is in a third-party DBMS. 2 The requesting user isn't known at the time that library pre-assignment happens (during server initialization). 3 Each server process instance is launched on-demand and runs under the host identity of the requesting user (or group, if authentication is via stored group logins).

Note: You can directly specify which identity to use on a connection to the metadata server (for example, with METAUSER and METAPASS). You can directly specify which identity to use on a connection to a host (for example, by providing explicit credentials in your code). [cautionend]

In the preceding table, notice that although metadata layer evaluations are almost always individualized (for example, Does Joe have metadata layer permission to see this stored process?), physical layer evaluations are often generalized (for example, Does the sassrv account have host layer permissions for this data? ).

In particular, requests from metadata-aware clients for SAS data often aren't evaluated under the host identity of each requesting user. The host doesn't know the user's SAS identity, so the host can't evaluate the user's operating system permissions. Instead, the host checks the permissions of the service account that is fetching the SAS data on behalf of the requesting user. These service accounts are referred to as launch credentials.

	Launch Credentials
	Host Access to SAS Tables
	Choices in Workspace Server Pooling