SAS/SHARE User's Guide

Server Security

Controlling Administrator Access to a Server

By default, any user can send administrator requests to a SAS/SHARE server to stop the server or to display and modify its characteristics, such as who can access the server and what SAS libraries it can serve. To prevent unauthorized users from sending these types of requests, you can assign an administrator password to a server when you start it. To do this, use the OAPW= option in the PROC SERVER statement. Here is an example:

proc server id=share1 oapw=blue31;

When you use PROC OPERATE to send administrator commands to the server, you must use the SAPW= option to specify the administrator password. For example,

proc operate id=share1 sapw=blue31;

You can also specify the administrator password in the individual PROC OPERATE server management commands. For details, see Displaying Information about a Server.

Controlling Access to Data through a Server

A SAS/SHARE server must have appropriate permissions to read and write any data that any of the server's clients will access through it. Usually this means that a server is authorized to access more libraries and data sets than any one of its clients. For this reason, you may want to employ security measures to prevent unauthorized access to data through the server by using one or more of the following:

a single password on the server
limitations on what libraries the server can access
passwords on SAS data sets, views, and catalogs
host or file system protections on libraries and data sets
userid authentication.

Assigning a User Password to a Server

The simplest method that you can use to limit access to data through a server is to assign a user password to the server when you start it. This password must be supplied whenever a client connects to the server. This method offers the broadest control over who can access data through the server. It applies to all users regardless of the data that they access or the operations that they perform.

To assign a user password to a server, use the UAPW= option in the PROC SERVER statement. Here is an example:

proc server id=share1 uapw=hotwings; 
run;

When a user specifies the server for the first time in a LIBNAME statement or in a PROC SQL CONNECT TO statement, the SAPW= option must be used to specify the user password. Here is an example:

libname invoice server=share1 sapw=hotwings;

Limiting Which Libraries the Server Can Access

If there are libraries or data sets that should not be accessed through a particular server, you can prevent such unauthorized access by using the host or file system security software to deny the server access to those libraries or files.

You can also use the NOALLOC option in the PROC SERVER statement to limit users to accessing only those libraries that you pre-define. For more information, see Pre-Defining SAS Data Libraries to the Server and Limiting Users to Pre-Defined Libraries.

Host or File System Protections

When a user reads or writes SAS libraries and SAS files, most hosts and file systems verify the user's authority to read or write that data.

Because a server is interposed between a user and the data, the authority checking that is normally performed by the host or the file system security software must be done in the server's session to protect access to that data through the server. For this reason, a SAS/SHARE server calls the host or the file system to check a user's authority whenever an attempt is made to read or write a library through the server.

In Version 7, by default, a SAS/SHARE server required each communications access method to present, for each user that connects to the server, an authenticated userid for the host on which the server runs. In Version 8, the provision of an authenticated userid and password as arguments to either the LIBNAME statement, the ALLOCATE LIBRARY command of the PROC OPERATE statement, or the Remote SQL Pass-Through statement preempts the Version 7 method of supplying a userid and password by way of a communications access method. Regardless of the method used for collecting a userid and password, the server uses the authenticated userid in making the authority check. To permit access by unauthenticated userids, you can use the AUTHENTICATE=OPTIONAL option in the PROC SERVER statement for both Version 7 and Version 8 behaviors. See The SERVER Procedure for details about setting options in the PROC SERVER statement. For details about implementing Version 8 userid and password behavior, see the syntax for The LIBNAME Statement, Remote SQL Pass-Through (RSPT) Facility, or The OPERATE Procedure.

In order to authenticate a userid, most access methods require the user to use an access method-specific mechanism to supply the userid and corresponding password for the server host. The access method encrypts the userid and password and transmits them to the server session to be authenticated. For details about the mechanisms that are available to control whether an access method authenticates connecting users and the mechanisms by which users can supply their userids and passwords, see Communications Access Methods for SAS/CONNECT and SAS/SHARE Software.

On most hosts, to authenticate a userid and to make an authority check, a SAS/SHARE server calls the host or the file system directly. However, on CMS and UNIX, the server performs these functions by calling an external program that you can modify.

Ensuring That Userids Are Authentic

Because a SAS/SHARE server calls the host or the file system to check a user's authority to access data, the accuracy of the userid that the server presents to the host or to the file system determines whether a user is allowed to access data.

When all communications access methods are configured (see Communications Access Methods for SAS/CONNECT and SAS/SHARE Software), on most hosts each userid is authenticated by the communications access methods when a user connects to the server. That authentication is valid for the duration of the connection, and the server presents the userid to the host or to the file system whenever the user attempts to access data through the server.

The option AUTHENTICATE=OPTIONAL specified in a PROC SERVER statement is used to bypass the requirement that the access methods authenticate connecting userids. This illustrates the usefullness of the option AUTHENTICATE=OPTIONAL for getting a server up and running quickly with an absolute minimum of work. In addition, this use shows the value of configuring production servers to run without the option AUTHENTICATE=OPTIONAL, so that production servers can run unattended yet only allow users to access data that they have permission to access.

If you are running a SAS/SHARE server on a platform that does not have a security facility, which controls users' access to files, or if you are running a SAS/SHARE server in an environment in which every user should have full access to every file available to the server, you may want to use the option AUTHENTICATE=OPTIONAL instead of implementing security for each of the access methods that is used by the server. An example of this situation is a SAS/SHARE server that is running under OS/2 without a security facility installed. In that situation, it is not possible for communications access methods to validate connecting userids, nor is it possible for the server to verify access to files on a per-userid basis.

There is another situation in which a communications access method used by a SAS/SHARE server runs in a secure, distributed network of computers, but not all of the users have userids on the computer on which the SAS/SHARE server runs. In this case, users without userids who are connecting by means of that access method can be "trusted" by the server because this type of connection can come only from computers in the secure network. If all of the files that are available to the server can be safely accessed by all of the userids in the secure network, the convenience of "bypassing" security checking for that access method outweighs the trouble of creating userids on the server's computer just so the access method can re-validate each user's identity.

An example of this situation is a SAS/SHARE server that is running on a UNIX platform that can be accessed by either the TCP/IP or the APPC access method. If all connections by means of the APPC access method can come only from mainframe computers in a secure network but it is impractical to duplicate the mainframe userids on the UNIX computer, trusting the connections made by way of the APPC access method might be the most practical decision. Meanwhile, connections to the specific server that is using the TCP/IP access method would not be trusted because (at this hypothetical installation) the TCP/IP network is not secure. In this case, specifying TCPSEC=_SECURE_ and APPCSEC=_NONE_ to control the access methods and using the option AUTHENTICATE=OPTIONAL in the PROC SERVER statement allows each APPC user to access any file available to the server, but limits TCP/IP users to the files available to their userids on the computer on which the server is running.

Using Encryption Services

As another form of security, you may choose to implement encryption services that protect data that is sent between hosts across a network. See Encryption Services for more information.

Chapter Contents
Previous
Next
Top of Page