SAS 9.1.3 Integration Technologies » Server Administrator's Guide


Security
Overview of Domains
Implementing Authentication
Host Authentication
Trusted Authentication Mechanisms
Alternative Authentication Providers
Defining Users, Groups, and Logins on the SAS Metadata Server
Implementing Authentication and Authorization for Xythos WFS WebDAV
Scenario
Implementing Encryption
Setting Up Additional Server Security
Planning the Workspace and Stored Process Server Security
Spawner Security
Scenario: Spawner and Load-Balancing
Pooling Security
Scenario: Pooling
Load Balancing Security
Scenario: Load-Balancing Across Two Machines
Implementing Security in Client Applications
Security

Scenario: Security Configuration for Pooling

The following scenario shows a recommended setup for user, group, and server security within a pooled SAS Workspace Server configuration. In this scenario, the requesting application uses a pool administrator to retrieve the credentials that are needed to launch the pooled workspace servers and allocate pooled connections to users.

Pooling Diagram

The diagram shows a pool that consists of the following server and security definitions on the SAS Metadata Server:

  • a pooled logical server with two puddle definitions and three server definitions. The pool consists of a pooled logical server that has two puddle definitions, Puddle1 and Puddle2; each puddle contains Servers 1, 2, and 3.

  • a user metadata identity for a pool administrator, PoolAdmin, whose login credentials (not shown) are used by the application to access the puddle logins.

  • two group metadata identities for puddle administration. The two groups, Puddle1Logins and Puddle2Logins, each contain a unique login definition that is used as the puddle login credentials to connect to SAS for Puddle1 or Puddle2. The pool administrator, PoolAdmin, belongs to both the Puddle1Logins and Puddle2Logins group. Because PoolAdmin is a member of each of the groups that contain the puddle login definitions for Puddle 1 and Puddle 2, PoolAdmin can access both of these puddle login definitions. Note that the login definitions for the puddle logins must have the same authentication domain as the servers in the pool.

  • two group metadata identities for group access to each puddle. A group named Puddle1Access is granted access to Puddle1. A group named Puddle2Access is granted access to Puddle2. The users who are members of Puddle1Access can access Puddle1; the users who are members of Puddle2Access can access Puddle2. Note that the login definitions for the users DO NOT need to have the same authentication domain as the servers in the pool.

When Joe connects to the logical server, because he is a member of the group Puddle1Access, he connects to Puddle 1. When PoolAdmin connects to the pooled logical server, because he can access puddle logins for both puddles, he might be directed to either Puddle 1 or Puddle 2, depending on which puddle is available.

The following diagram shows a view of the SAS Metadata Server's security and server setup for this scenario's pooled workspace server and spawner configuration:

Diagram showing pooling security for workspace server

Before a user can connect to a pool, the following prerequisites must be true:

  • The SAS Metadata Server is running.

  • Each spawner has been started and has connected to the SAS Metadata Server and read the appropriate metadata for the configuration.

  • The pool has used the appropriate puddle login credentials to connect to the object spawner to launch servers. The minimum number of servers are launched under the appropriate puddle login credentials.

A user who requests a connection from a pool is authenticated against the SAS Metadata Server's authentication provider and the pool uses the SAS Metadata Server to obtain the requesting user's metadata identity (user or group). The pool then allocates a connection from the pool to the requesting user as follows:

  1. The pool selects a puddle that meets one of these conditions:

    • the requesting user ID matches the puddle login's user ID, or it is owned by the user or group metadata identity of the puddle login's user ID. In this scenario, the PoolAdmin user metadata identity can access both puddles. (Also, the Puddle1Logins group metadata identity can access Puddle1 and the Puddle2Logins group metadata identity can access Puddle1).

    • the requesting user ID matches a user ID that is a member of the group granted access to each puddle. In this scenario, users who are members of the two groups that are granted access to the puddle (Puddle1Access or Puddle2Access) can access the pooled workspace servers.

  2. The pool returns a connection to the selected puddle as follows:

    • if a connection is available, the pool returns a connection to the requesting user. The user uses the connection as long as required.

    • if there are no available connections (to the puddle) and the maximum number of connections has been met, then the requesting user waits for a connection to become available.

    • if there are no available connections and the maximum number of connections has not been met, the pool obtains the puddle login credentials to create a new connection to a SAS server as follows:

      1. On the SAS Metadata Server, the pool administrator (PoolAdmin) reads the metadata information for the server and spawner configurations.

        The user metadata identity PoolAdmin can view the puddle logins (PCDOM\Pud1 and PCDOM\Pud2) because PoolAdmin is a member of the group metadata identities Puddle1Logins and Puddle2Logins; the group metadata identity Puddle1Logins owns the puddle login credentials for Puddle 1 (PCDOM\Pud1) and the group metadata identity Puddle2Logins owns the puddle login credentials for Puddle 2 (PCDOM\Pud2).

      2. The pool administrator uses the puddle login credentials to connect to the object spawner to launch a server. The object spawner uses the puddle login credentials to launch the pooled workspace server.

      3. The pool administrator returns a connection to the requesting user.