Authentication Model

Authentication Scenarios

	Introduction and Template
	Example: Windows and Shared Access to Oracle
	Example: UNIX and Two Levels of Host Access
	Example: Mixed Hosts and SAS Token Authentication

Introduction and Template

The examples in this section show how different sites might annotate the following template to reflect their environment and choices. Not all deployments use all servers.

Template for Authentication Scenarios

[Template for Authentication Scenarios]

Here are some details about the template:

To facilitate integration with your environment, SAS provides several authentication choices for the metadata server. See Authentication to the Metadata Server.

Note: Most users should have their own inbound login for the metadata server. Exceptions are users who don't need an individual identity and users who use a SAS internal account.

Note: The metadata server also accepts SAS token authentication connections from processing servers.
The workspace server usually uses some form host authentication. If you have mixed providers, you might configure the workspace server to use SAS token authentication (instead of using host authentication). See Coordinate the Workspace Server.

Note: When a user requests a standard workspace server, it is actually the spawner that performs the authentication (in accordance with the workspace server's metadata settings) and then launches the server process. That detail is omitted in the general discussion.
Most other SAS servers use SAS token authentication for all metadata-aware requests. See SAS Token Authentication.
Some types of logical server can contain multiple servers with each server running under a different launch credential. See Host Access to SAS Tables.
The logical pooled workspace server provides server-side pooling. This is not the same as client-side pooling, which can be offered only by a specially configured standard workspace server. See Choices in Workspace Server Pooling.
The OLAP server doesn't have credentials as part of its metadata definition because that server isn't launched by the object spawner.
In order to provide seamless access to a third-party server that uses its own proprietary user registry, you must store individual or group credentials in the metadata. See Authentication to a Third-Party Data Server.

Example: Windows and Shared Access to Oracle

The following annotated template shows how a Windows site might provide access to servers. This example also illustrates one way to incorporate a third-party server (an Oracle server that maintains its own user registry and doesn't accept Windows credentials).

Authentication Scenarios: Windows Example

[Authentication Scenarios: Windows Example]

Here are some points about this example:

This site can offer Integrated Windows authentication (IWA) for the metadata server because that server is on Windows.
Because the metadata server offers IWA and the workspace server is also on Windows, this site configured the workspace server to also offer IWA. This is necessary in this scenario because when the initial logon is by IWA, there are no cached credentials that a client could reuse for credential-based host authentication to the workspace server.
If a user doesn't opt in to IWA in their connection profile, the user provides credentials in the initial logon dialog box. Those credentials are added to the user's in-memory credential cache (user context). When the user requests a workspace server, those credentials are reused even though the workspace server is configured for IWA.
This site chose to provide seamless shared access to Oracle by storing an Oracle user ID and password on the Accounts tab of a custom group, OracleUsers.
- If this site also stores individual Oracle credentials for selected members of the OracleUsers group, those members would authenticate with their individual credentials. A personal OracleAuth login would have priority over the group OracleAuth login.
- If this site doesn't store any Oracle passwords, interactive (prompted) access to Oracle is available from SAS desktop applications and in SAS Web Report Studio.
This site hasn't modified the initial configuration in which all process instances of the stored process server and the pooled workspace server run under the same server launch credential (sassrv). Host layer access from these servers is undifferentiated.

Example: UNIX and Two Levels of Host Access

The following annotated template shows how a UNIX site might provide access to servers.

Authentication Scenarios: UNIX Example

[Authentication Scenarios: UNIX Example]

Here are some points about this example:

This site can't offer Integrated Windows authentication (IWA) because the metadata server isn't on Windows.
This site chose to establish two levels of host access from the pooled workspace server. Notice that there are two servers under that logical server, each with a different launch credential. The site gave each credential different host layer access to SAS data sets. The ReadMetadata permission settings on each server determine who uses that server. See Hiding Server Definitions.

Note: Other reasons for defining multiple servers below a logical server include using multiple computers or different start-up scripts.

Example: Mixed Hosts and SAS Token Authentication

The following annotated template shows how a site that has mixed providers might provide access to servers. This site chose the solution of configuring the workspace server to use SAS token authentication. See Mixed Providers.

Authentication Scenarios: Mixed Providers Example

[Authentication Scenarios: Mixed Providers Example]

A side effect of using SAS token authentication for the workspace server is that host access from the workspace server no longer occurs under the host identity of each requesting user. This site chose to establish two levels of host access from the logical workspace server.

Note: The requesting user's SAS identity is still preserved for metadata layer access control and logging purposes. [cautionend]

Top of Page