Server Configuration, Data Retrieval, and Risk

Choices in Workspace Server Pooling

	About Workspace Server Pooling
	Benefits and Risks of Server-Side Pooling
	Which Requests Are Eligible to Use Pooling?
	Which Eligible Requests Actually Use Pooling?
	Modifying the Initial Pooling Configuration

About Workspace Server Pooling

The primary purpose of pooling is to enhance performance by avoiding the time penalty that is associated with launching all workspace servers on demand. In pooling, a set of workspace servers are made available to process certain types of query requests. In general, pooling is used when a relational information map is queried, processed, opened, or used indirectly (through a report).

The initial configuration in a new deployment conforms to the following general recommendations:

Use server-side pooling. The initial configuration includes a logical pooled workspace server.
Use client-side pooling only if you have security requirements that aren't met by server-side pooling. The initial configuration doesn't include client-side pooling.

Benefits and Risks of Server-Side Pooling

Server-side pooling offers the following benefits:

With server side-pooling, the spawner can request user-specific metadata layer access evaluations, such as whether a user has permission to use a particular server. This isn't possible in client-side pooling because use of the pool administrator prevents the spawner from knowing who the requesting user is.
With server-side pooling, you can track each request to a specific server instance. This level of auditing isn't possible in client-side pooling because use of the pool administrator prevents the spawner from knowing who the requesting user is.
With server-side pooling, testing of an information map in SAS Information Map Studio more closely approximates results in SAS Web Report Studio, because both requests can use the same server.
With server-side pooling, allocation of server processes is managed across clients, using the spawner's load-balancing capabilities. Client-side pooling uses round-robin assignments on a per-application basis.
A side effect of pooling is that the launched workspace servers run under a designated service account. This side-effect is beneficial in avoiding credential gaps that can occur when a desktop application requests a workspace server from a middle-tier service. This benefit is not provided by client-side pooling, because client-side pooling is supported only for Web applications.

Server-side pooling introduces the following risks:

Someone might write a rogue application that bypasses metadata layer access controls. This risk originates from the following difference in server control:
- In client-side pooling, the server is controlled by a designated Web application. Only that application can request a pooled workspace server, because only that application can provide the pool administrator's credentials. No other application can use (or exploit) the server.
- In server-side pooling, there is no pool administrator or alternate form of application-based gatekeeping. Anyone who can use the server legitimately (from a SAS application) can also exploit that server by writing a rogue application that uses the server to fetch SAS tables. The security issue is that retrieval from such an application bypasses metadata-layer controls that apply when the same data is accessed in a legitimate manner. For example, a request in SAS Web Report Studio might be filtered by a metadata layer permission condition that enables the user to see only certain rows in a data set.
Note: This exposure is also applicable to other SAS processing servers that provide mediated access (standard workspace servers that use SAS token authentication, stored process servers). This exposure occurs in client-side pooling if a user obtains the pool administrator's credentials.

Note: To avoid a similar exposure, nobody is allowed to assign a stored process to a server-side pooled workspace server.
Someone might exploit the server-side pooled workspace server from within SAS Information Map Studio. In general, only information map creators who have host access to the target data use this application. If someone else has SAS Information Map Studio, that person could bypass metadata layer controls when querying a relational information map from within that application.

Note: This is never a risk with client-side pooling, because client-side pooling isn't available for desktop applications such as SAS Information Map Studio.

The following table summarizes the trade-offs. For completeness, the table includes a column for a standard workspace server that uses SAS token authentication and a column for a standard workspace server that uses either form of host authentication (credential-based or Integrated Windows authentication).

Summary: Comparison of Workspace Server Configurations
Advantage	Pooled		Not Pooled
Advantage	Server-Side	Client-Side	SAS Token	Host
Performance and Compatibility:
Improves performance of Web applications.
Compatible with spawner-based load balancing.
Compatible with Web authentication.
Accommodates batch generation of scheduled reports.¹
Fully compatible with Integrated Windows authentication.²
Security:
The SAS identity of the requesting user (or group) is used for metadata layer evaluations.
Server access security is supported.
The server is controlled by designated client applications.
The user (or group) host identity is passed to the host layer.
The user (or group) host identity is passed to SQL Server.³
1 Credentials for the workspace server are available to the batch generation process. 2 Accommodates requests through SAS Intelligent Query Services for a workspace server (for example, opening an information map after logging on to SAS Enterprise Guide using Integrated Windows authentication). 3 If the workspace server's host authentication is by IWA and any additional configuration requirements are met.

Which Requests Are Eligible to Use Pooling?

Only requests that are handled by a particular query services software component are eligible to use pooling. That software component is primarily used to query, process, open, or otherwise interact with a relational information map.

Note: In SAS Enterprise Guide and the SAS Add-In for Microsoft Office, not all such requests are eligible. If the libraries that an information map references can be assigned within an existing SAS session, a request to open that information map is not eligible to use pooling. To ensure that such requests are eligible, limit physical (host operating system) access to the directories that are referenced by that information map's libraries. Deny access to users and grant access to the host identity under which a pooled server runs. [cautionend]

Note: Similar requests that don't involve a relational information map aren't eligible, because those requests aren't handled by the query services component. For example, requests to open a report that directly contains a stored process or open a report that contains OLAP data are not eligible. [cautionend]

Note: A few specialized low-level tasks (such as dynamically building a list of prompt values) are eligible, because the query services component is used for those tasks. [cautionend]

Not all requests that can use pooling actually do so. See the following topic.

Which Eligible Requests Actually Use Pooling?

Use of pooling for eligible requests is constrained as follows:

client-side pooling

can be used for eligible requests in only specially configured Web applications. For example, if SAS Web Report Studio's configuration includes a pool administrator, that application uses client-side pooling to process information maps.

server-side pooling

can be used for eligible requests in any application. For example, server-side pooling can be used to process information maps from SAS Web Report Studio, SAS Information Map Studio, SAS Enterprise Guide, and the SAS Add-In for Microsoft Office. However, eligible requests don't use server-side pooling in the following circumstances:

If a Web application has a configured pool administrator, requests from that application don't use server-side pooling.
If there is no logical pooled workspace server under a particular application server , requests for resources that are assigned to that application server can't use server-side pooling.
If a user doesn't have the ReadMetadata permission for the logical pooled workspace server , requests made by that user can't use server-side pooling.

Note: If you chose to limit ReadMetadata permission permission for the server, be sure to preserve necessary access for service identities.

Note: If the Use Server Access Security check box on the logical server's Options tab is cleared, users don't need ReadMetadata permission. This check box should always be selected.

The following figure summarizes the decision sequence that determines what type of server processes an eligible request. Most of the determinative factors can be controlled by an administrator.

Use of Pooling (Applies to Only Eligible Requests)

[Use of Pooling (Applies to Only Eligible Requests)]

In the preceding figure, the bold (green) text and arrows mark the decision path in a new deployment with the default configuration. In such a deployment, there are two logical workspace servers within the general-use application server (for example, SASapp):

a server-side pooled workspace server (the Logical Pooled Workspace Server) that is visible to all registered users.
a standard workspace server (the Logical Workspace Server) that is not converted to client-side pooling. There is no configured pool administrator, so client-side pooling is not attempted.

Modifying the Initial Pooling Configuration

If you are concerned about the risk that server-side pooling introduces, and that concern outweighs the advantages of server-side pooling, consider these options:

For a high security implementation of BI row-level permissions, you must use client-side pooling in a separate deployment of SAS Web Report Studio. You can continue to use server-side pooling in the original deployment.
To prevent only Web applications from using server-side pooling, configure those applications to use client-side pooling.

Note: In order to get the security benefit, you must set up client-side pooling correctly. For example, don't use the general SAS Spawned Servers credential (sassrv) as the puddle login.
To enable information map creators to run queries under their own host identities (instead of under the launch credential of the server-side pooled workspace server), hide that server definition from those users. Someone who can't see the logical pooled workspace server uses the standard workspace server instead.

Note: This is appropriate only if you have an information map creator who shouldn't be able to access all data that is available to the pooled workspace server. This doesn't eliminate the risk of unauthorized use of SAS Information Map Studio by someone who legitimately uses the server-side pooled workspace server from other applications.
To completely eliminate use of server-side pooling, delete the logical pooled workspace server. For performance reasons, we recommend that you also configure client-side pooling for SAS Web Report Studio.

	BI Row-Level Permissions
	Hiding Server Definitions
	Host Access to SAS Tables
	Criteria for a Designated Launch Credential
	Configuring Client-side Pooling in the SAS Intelligence Platform: Application Server Administration Guide