Beginning in SAS 9.0, separate client and server security contexts within the SAS Workspace Server are not supported. All file access checks are now performed solely with the user ID under which the server was launched. The additional level of security checking, which was based on the client user ID, has been removed.

This change affects sites that were relying on two levels of access checking, one under the ServerUserID and an additional level under a ClientUserID that can be distinct. Before upgrading to SAS 9 from SAS 8, the following sites should review their security policies:

Sites that launch COM workspace servers using the "This user" identity setting in the dcomcnfg utility.
Sites that use COM+ pooling.
Sites that use Web applications configurations where the site administration has control of the client security settings.

This change fixes several cases in which SAS running as a workspace server acted differently than SAS running interactively.

IOM Bridge for COM Security

Specifying the ServerUserID

When using the IOM Bridge for COM, the spawner uses the client-provided login name and password as the identity under which to launch the server. The server that is launched receives its ServerUserID (OS process user ID) from the login name provided by the client. The operating system then performs access checks using the ServerUserID.

Specifying Encryption

The IOM Bridge for COM supports encryption of network traffic between the client and the IOM server. Weak encryption support (through the SASPROPRIETARY encryption algorithm) is available with Base SAS software. Stronger encryption requires a license to SAS/SECURE on the server machine.

On the Windows platform, the SAS/SECURE license allows the encryption algorithms available through the CryptoAPI to be used. On other platforms, encryption algorithms are included in the SAS/SECURE software.

Note: The SAS/SECURE Client for Windows must be installed on the Windows client machines to use the CryptoAPI. (See Windows Client Installation for more information.)

When you define a ServerDef, you can use the BridgeEncryptionAlgorithm and BridgeEncryptionLevel attributes to specify the encryption algorithm and what gets encrypted. See the Object Manager package documentation (sasoman.chm) for details.

COM/DCOM Security

Specifying the ServerUserID

On Windows NT, the COM Service Control Manager (SCM) is responsible for launching COM and DCOM processes. The SCM reads values from the Windows registry to determine which identity to use when launching a process. These registry settings are configured using the Windows dcomcnfg utility on the server.

The ServerUserID is set under the Identity tab for the properties of the SAS.Workspace (SAS Version 9.1) application. For specific details about how to access this tab, see Setting Permissions per Application on Windows NT/2000 and Setting Permissions per Application on Windows XP in the SAS Integration Technologies: Server Administrator's Guide.

You can choose one of the following options for the identity to use to run the IOM server (the ServerUserID):

Interactive User

allows the interactive user to kill the SAS server process through the task manager, because the interactive user owns the process. This is a security risk for the interactive user, because SAS will be running under his or her user ID. Someone must be logged on, or the SAS process will not run.

Note: For SAS 9.0 and later, there is no longer an additional level of security checking based on the client user ID. All file access checks are performed based solely on the user ID of the interactive user. This setting is not recommended for production environments.

Launching User

specifies the default option, and is more secure than the other two identity settings. This ensures that the ServerUserID will be the same as the client who created it. This setting provides a single-signon environment for launching the server; however, it does require the use of network authentication to set up the identity of the server. The NTLM network authentication mechanism (which is the default if any Windows NT4 machines are involved or if Windows 2000 Kerberos is not set up) cannot pass the client identity across more than one machine boundary. If you configure IOM servers to use "launching user" for DCOM connections, they are not able to access network files unless special Windows registry settings are adjusted on the file server. They are also not able to deliver events back to a DCOM client unless one of the following is true:

the client permits "Everyone" to access its COM interfaces
the client turns off authentication and authorization by setting the AuthenticationLevel to "None"

This user

allows you to configure a specific user name and password that will be used to run the IOM server. This has the same security considerations as the interactive user, but you do not have to worry about always having someone logged on. Also, the identity you run under does not change based on who is logged on.

Specifying Encryption

For DCOM, encryption is enabled by using an AuthenticationLevel of "Packet Privacy".

Authentication and Impersonation Levels for COM/DCOM Security

Authentication levels must be set on both the client and server machines. The stronger of the two authentication levels is then selected. The available authentication levels are listed below. For more details, consult Microsoft documentation.

None: The client is not authenticated. It is not possible for the server to determine the identity of the caller.
Connect: The client is authenticated when the connection is first established, and never again.
Call: The client is authenticated each time a method call is made.
Packet: Client authentication occurs for each packet (there may be multiple network packets used for a given call).
PacketIntegrity: Each packet is authenticated and verified to have the same content as when it was sent.
PacketPrivacy: All data is encrypted across the wire. Note that for local COM, the AuthenticationLevel appears to be "PacketPrivacy", but no encryption actually occurs on the local machine.

The impersonation level set on the client machine determines the impersonation level used for the connection. The impersonation level set on the server machine is not used. The available impersonation levels are listed below.

Anonymous: Impersonation is not allowed.
Identify: The server is allowed to know who is calling, but cannot make calls using the credentials of the caller.
Impersonate: The server can access resources using the security credentials of the caller. The server cannot pass on the credentials. The IOM server attempts to impersonate the caller. This is the recommended setting.
Delegate: The server can access resources using the security credentials of the caller and pass on those credentials to other servers, possibly those on different hosts. Note that delegation is only supported on Windows 2000. SAS software does not currently support this option.

Programming Examples

This Visual Basic example retrieves the ClientUserID and the ServerUserID from the IOM server.

   Public Sub sectest()
   ' This example prints both the client user ID and the server user ID.
   ' In SAS 9, the ServerUserID and the ClientUserID will always be the same.
   ' Create a local COM connection.
   Dim sinfo As String
   Dim swinfo() As String
   Dim hwinfo() As String

   Dim obWSMgr As New SASWorkspaceManager.WorkspaceManager

   Set obSAS = obWSMgr.Workspaces.CreateWorkspaceByServer(
      "MyServer", VisibilityNone, Nothing, "", "", sinfo)

   ' Get the host properties.
   obSAS.Utilities.HostSystem.GetInfo swinfo, hwinfo

   Debug.Print "ServerUserID: " & swinfo(
      SAS.HostSystemSoftwareInfoIndexServerUserID)
   Debug.Print "ClientUserID: " & swinfo(
      SAS.HostSystemSoftwareInfoIndexClientUserID)

   obSAS.Close

   End Sub

COM Security Considerations for Client Applications

Here are a few additional points to consider when developing client applications:

Always test your application and configuration before making sensitive information available. This allows you to ensure that people who are not authorized cannot see the data.
Security settings and performance are inversely related. In general, the stronger the security, the slower things run. This may be due to the CPU time used to encrypt the data at one end and decrypt the data at the other end, or the overhead involved with launching a new process each time a new user connects to an IOM server. Security settings are highly configurable to allow the administrator to optimize performance for the required level of security.
No system is completely secure, even at the strongest security settings.
For maximum security when using the IOM Bridge for COM, use a BridgeEncryptionLevel of "All" and a strong BridgeEncryptionAlgorithm, such as RC4. For maximum performance, use a BridgeEncryptionLevel of "None". (In this case, the setting for the BridgeEncryptionAlgorithm is ignored.)
In general, for maximum security with DCOM, use an Impersonationlevel of "Impersonate", and an Authenticationlevel of "Packet Privacy". In SAS 9.0 and later,
- for SAS Workspace Servers, impersonation will not be applied
- for SAS Metadata Servers, SAS Stored Process Servers, and SAS OLAP servers, an impersonation level of Impersonate is currently required.
The use of connectionless transports (mainly UDP) can cause difficulty with configuring and debugging. If your system (particularly Windows NT4) still uses a connectionless transport, then you might avoid complications by naming a connection-oriented transport (typically TCP) as the primary default.

COM Security Settings for Threaded Multi-User IOM Servers

SAS 9 Integration Technologies provides three new threaded multi-user IOM servers. Dcomcnfg has an entry for each application as follows:

SASMDX.Server (SAS Version 9.1): SAS 9.1 OLAP Server
SASOMI.OMI (SAS Version 9.1): SAS 9.1 Metadata Server
StoredProcessServer.StoredProcessServer (SAS Version 9.1): SAS 9.1 Stored Process Server, which provides interfaces to run user-written SAS programs (stored processes) to produce HTML output

If you do not specify an objectserverparm of "nosecurity", then clients are authenticated when they connect to the server.

You can set DCOM security settings for each type of server individually. Use the dcomcnfg utility to specify security settings. For details about using dcomcnfg to specify security settings, see Setting SAS Permissions on the Server in the SAS Integration Technologies: Server Administrator's Guide. In dcomcnfg, after you view the properties of a server, you have several tabs that provide controls to customize the server's security.

Identity Tab

Controls the ServerUserID for COM launches. If you decide to launch the server via COM (rather than via the object spawner), then the first client that connects must be a Windows client. For multi-user servers, set the Identity tab to "This user", and specify a user ID and password under which the server will run. The server runs in its own logon session; therefore, interactive logon/logoff activity on the same machine does not affect it.

COM does not start the server with any environment variables and does not set a home directory based on the "This user" setting. You should edit the SAS config file to remove environment variable references and to specify the "-sasinitialfolder" that you need at startup.

General Tab

Controls the minimum client authentication level that the server accepts (which is also the level that the server would use on any outward calls). "Connect" (the default) is the minimum setting. Every COM client must also do the following:

define an authentication level of "Connect" or higher
set an impersonation level of "Impersonate."

These client settings can be specified specifically by the client program on each calling interface or, through one of two defaulting mechanisms:

a call to CoInitializeSecurity() in the client program
via the machine-wide default settings in COM security configuration

The ideal client program would install and use an AppID of its own. However, some commonly used development languages, such as Visual Basic, do not provide an easy means to install and use an AppID.

Security Tab

Controls access, configuration, and launch permissions. These can either be determined from machine-wide defaults or set up specifically for the particular IOM server application. Ensure that "System" is included in any of these permissions that you customize. You can use the access permissions editor to create a standard access control list to indicate who can use the server.

Location Tab

Indicates that the application should be run on this computer.

Endpoints Tab

Allows you to select the most used protocol. It is recommended you use connection-oriented protocols such as TCP.