Windows Client Security

This section discusses security issues that arise when developing Windows client applications that attach to IOM servers.

Security Contexts

The SAS Server maintains two distinct security contexts, ClientUserID and ServerUserID. ServerUserID is the context under which the SAS server process is running. All calls from the SAS operating system process into the host operating system are made using the security context of the ServerUserID. All files are created under the ServerUserID.

The ServerUserID remains fixed for the entire lifetime of the SAS operating system process. It cannot be changed once the process has been created.

The ClientUserID context is used by SAS for checking authorization prior to actually making a system call. Once the SAS server has determined that the ClientUserID is authorized to perform an operation (usually open/read/write) against a resource (usually a file), the actual call goes through to the operating system using the ServerUserID.

You will have a more secure environment if both the ClientUserID and the ServerUserID are the same. In most cases, they will be the same. However, it is possible to configure the system to make these contexts different.

There are several points to consider if the ServerUserID is different from the ClientUserID:

• Both the ClientUserID and the ServerUserID must have sufficient permissions to perform the requested operation (read a file, write a file, and so on.)
• It is possible to create a file that the creator cannot read. For example, on UNIX, setting a umask of 007 causes files to be created such that only the owner of the file can read it. The owner of the file is always the ServerUserID, so when the SAS server subsequently checks to see if the ClientUserID can access the file, it gets an error message indicating that the user does not have appropriate authorization level to access the file.
• System audit logs show that the ServerUserID is the one accessing files.
• Pipes execute under the ServerUserID.

ClientUserID and ServerUserID are specified differently depending on whether you are using COM/DCOM or the IOM Bridge for COM to communicate between client and server. Both methods are discussed in the following sections.

Security Using the IOM Bridge for COM

Specifying the ClientUserID

When establishing a connection through the IOM Bridge for COM, a client provides a Login name and Password that the IOM server uses to establish the ClientUserID. This ClientUserID will remain fixed for the duration of the lifetime of the Workspace.

Specifying the ServerUserID

When using the IOM Bridge for COM, the SAS server process is launched by the spawner.

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. See Using the Workspace Manager for details on how to specify which encryption algorithm to use and how to specify what gets encrypted.

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.)

COM/DCOM Security

Specifying the ClientUserID

On every IOM method call, the SAS server attempts to impersonate the caller. If this impersonation is successful, then the ClientUserID will be set to the caller's UserID. If not successful, then the ClientUserID will default to the ServerUserID.

Permission to impersonate must be granted by the client application by calling CoInitializeSecurity, or by setting entries in the Windows registry (on the client).

Note: Client-side registry settings are ignored for applications that call CoInitializeSecurity.

The client-side Windows registry settings are configurable with the Windows utility dcomcnfg). In dcomcnfg, the ImpersonationLevel must be at least Impersonate, and the AuthenticationLevel must be set to a value other than None. The ClientUserID may change with every call, based on who is making the call (This is not possible using the IOM Bridge for COM).

Please see Setting up a COM/DCOM Server for more information on using the dcomcnfg utility to configure DCOM settings.

Notes:

• The above discussion is true for both COM (used when the client runs on the same machine as the server) and DCOM.
• DCOM requires impersonation to be disabled in order for a client application to receive events. (In this case, the ServerUserID and the ClientUserID must always be the same.)

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 (Ver 1.0) application. (See Setting Launch Policies per Application for specific details on how to get to this tab.)

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

The interactive user

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

The launching user

This is 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. The ServerUserID and the ClientUserID will always be the same unless the client passes a SAS interface to code running under another userid. The SAS server process cannot be killed by the interactive user.

This user

This option allows you to configure a specific username and password that will be used to run the IOM server. This has the same security considerations as the interactive user, but you don't have to worry about always having someone logged in. Also, the identity you run under doesn't change based on who is logged in.

Encryption

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

Additional Notes on COM/DCOM Security

Here is a quick summary of the authentication levels available. These must be set on both the client and server machines. The stronger of the two is selected. 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 following is a summary of the impersonation levels available. The value set on the client machine determines the impersonation level used for the connection. The impersonation level set on the server machine is not used.

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 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.

' This example prints both the client userid and the server userid.

' Create a local COM connection
set obSAS = obWSMgr.Workspaces.CreateObject("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)

' Under COM on NT, the ServerUserID will always report the same thing as the ClientUserID,
' even though they may be different.  This is fixed by Windows2000.

Client Application Security Considerations

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

• Always try your application and configuration out 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.)
• For maximum security with DCOM, use an Impersonationlevel of Impersonate, and an Authenticationlevel of Packet Privacy.
• Events (or outcalls) require the server to make calls on interfaces provided by the client. This is the opposite of what usually happens (when the client makes calls on server interfaces). To allow event delivery, the AuthenticationLevel must be negotiated to None. This can be accomplished by setting the AuthenticationLevel equal to None on the client side since the server always uses an AuthenticationLevel of None for event delivery.