Sybase Technical Library - Product Manuals Home
[Search Forms] [Previous Section with Hits] [Next Section with Hits] [Clear Search] Expand Search
Security features [Table of Contents] Secure Sockets Layer in Open Client/Open Server

Open Client Client-Library/C Reference Manual

[-] Chapter 2 Topics
[-] Security features
[-] Network-based security

Network-based security

A distributed client/server computing environment introduces security concerns that go beyond those of a local system. Because users are out of sight and data is moving from system to system, even across public data networks, intruders may view or tamper with confidential data. Security services allow client/server applications to create secure connections.

Network-based security takes advantage of third-party distributed security software to authenticate network users and to protect data transmitted over the network.

Security mechanisms and security drivers

Sybase defines a security mechanism as external software that provides security services for a connection. For example, these are some security mechanisms that can be used on a Client-Library connection:

Sybase provides security drivers that allow Client-Library and Server-Library applications to take advantage of an installed network security system. By using security drivers, Client-Library and Server-Library provide a portable interface for implementing secure applications that work with several different network security systems.

To use a security mechanism on a connection, each item below must be true:

Choosing a network security mechanism

The value of the CS_SEC_MECHANISM connection property determines the name of the security mechanism to be used to establish a connection. The default depends on the Sybase security driver configuration for your system.

Client-Library uses a driver configuration file to map security mechanism names to security driver file names. On most platforms, this file is named libtcl.cfg. See your Open Client/Server Configuration Guide for a full description of the driver configuration file.

Determining the default security mechanism

The default security mechanism name corresponds to the first entry in the [SECURITY] section of the libtcl.cfg driver configuration file. This section has entries of the form: 

[SECURITY]
 mechanism_name = driver_file_name init_string
 mechanism_name = driver_file_name init_string

where mechanism_name specifies a possible value for the CS_SEC_MECHANISM property, driver_file_name is a file name for the driver, and init_string specifies start-up settings for the driver.

If no driver configuration file is present on the system, or the file lacks a [SECURITY] section, the CS_SEC_MECH property defaults to NULL.

See the Open Client/Server Configuration Guide for a detailed description of driver configuration for your system.

Loading the default security driver

If an application does not request a driver by name, Client-Library loads the default security driver (if any) when needed. If a security driver is not loaded, ct_con_props or ct_config load the default driver when called with action as CS_SET or CS_SUPPORTED and any of the following values for property:

Global mechanism names

The security mechanism names in the driver configuration file are local names that may vary from system to system. For the client and the server to both determine the identity of the connection's security mechanism, they require invariant global names for security mechanisms.

When setting the CS_SEC_MECHANISM property or when loading the default security driver, Client-Library reads a configuration file, the global object identifiers file, to map local security mechanism names to object identifier (OID) strings. On most platforms, this file is called objectid.dat. Client-Library looks for security mechanism OIDs in the section [SECMECH]. The entries in this section have the form: 

[SECMECH]
 mechanism_oid = local_name1, local_name2, ...

where mechanism_oid is the OID string that globally identifies the security mechanism and local_name1, local_name2, and so forth are local security provider names from the libtcl.cfg file. See the Open Client/Server Configuration Guide for more information on the global object identifiers file.

Requesting network security services

Each security mechanism provides a set of security services. Each security service addresses some security concern. In a Client-Library application, the requested services correspond to context or connection properties.

Not all of the security services are supported by all security mechanisms. To find out whether a given service is supported by the current security mechanism, the application calls ct_config or ct_con_props with action as CS_SUPPORTED, buffer as the address of a CS_BOOL variable, and property as the symbolic property constant that represents the security service. *buffer is set to CS_TRUE if the service is supported. ct_config and ct_con_props both fail when the application requests a service that is not supported by the current security mechanism.

Network security services are split into two categories:

Requesting login authentication services

The fundamental security service is login authentication, or confirming that users are who they say they are. Login authentication involves user names and passwords. Users identify themselves by their user name, then supply their password as proof of their identity.

In Sybase applications, each connection between a client and a server has one user name associated with it. If the application uses a security mechanism, then Sybase uses the mechanism to authenticate this user name when the connection is established. The advantage of this service is that the user name/password pairs are managed in a central repository, and not in the system catalogs of individual servers.

When an application requests to connect to a server using network-based authentication, Client-Library queries the connection's security mechanism to confirm that the given user name represents the authenticated user that is running the application. This means that users do not have to supply a password to connect to the server. Instead, users prove their identity to the network security system before the connection attempt is made. When connecting, Client-Library obtains a credential token from the security mechanism and sends it to the server in lieu of a password. The server then passes the token to the security mechanism again to confirm that the user name has been authenticated.

The following connection properties are related to login authentication. To take effect, these properties must be set before a connection is established. At the connection level, all the following properties are retrieve-only when the connection is open:

Requesting per-packet security services

In some environments, distributed application designers have to deal with the fact that the network is not physically secure. For example, unauthorized parties may listen to a dialog by attaching analyzers to a physical line or capturing wireless transmissions.

In these environments, applications require protection of transmitted data to assure a secure dialog. Per-packet security services protect transmitted data.

All per-packet services require that one or both of the following operations be performed for each TDS packet to be sent over a connection:

If an application selects multiple per-packet services, each operation is performed only once per packet. For example, if the application selects the data confidentiality, sequence verification, data integrity, and channel binding services, then each packet is encrypted and accompanied by a digital signature that encodes the packet contents, packet sequence information, and a network channel identifier.

All per-packet services, except data confidentiality, require the connection's security mechanism to compute a digital signature for each packet that is sent over the connection. The signature encodes information about the packet's contents, and may encode other information as well. The client and the server both compute packet signatures and send them with each TDS packet. When the packet and signature are received, the security mechanism verifies the received signature. If packet signature is rejected, the connection is closed as follows:

The following connection properties control the use of the per-packet services. To take effect, these properties must be set before a connection is established. At the connection level, all of the following properties are retrieve-only when the connection is open. All of the following properties take CS_BOOL *buffer values, and all are CS_FALSE by default:

Security features [Table of Contents] Secure Sockets Layer in Open Client/Open Server