The network security architecture works with standard industry interfaces, such as PAM, GSS-API, SASL, and the OASIS PKCS #11 open standard. Through the use of standardized protocols and interfaces, developers can write both consumers and providers that need no modification as security technologies evolve.
An application, library, or kernel module that uses security services is called a consumer. An application that provides security services to consumers is referred to as a provider and also as a plugin. The software that implements a cryptographic operation is called a mechanism. A mechanism is not just an algorithm but includes the manner in which the algorithm is to be applied. For example, one mechanism might apply the AES algorithm to authentication. A different mechanism might apply an algorithm with block-by-block encryption.
The network security architecture eliminates the need for developers of consumers to write, maintain, and optimize cryptographic algorithms. Optimized cryptographic mechanisms are provided as part of the architecture.
The Oracle Solaris OS provides the following public interfaces for security:
PAM – Pluggable authentication modules. PAM modules are mainly used for the initial authentication of a user to a system. The user can enter the system by GUI, command line, or some other means. In addition to authentication services, PAM provides services for managing accounts, sessions, and passwords. Applications such as login and ftp are typical consumers of PAM services. The PAM SPI is supplied services by security providers such as Kerberos v5. See Writing PAM Applications and Services.
GSS-API – Generic security service application program interface. The GSS-API provides secure communication between peer applications. The GSS-API provides authentication, integrity, and confidentiality protection services as well. The Oracle Solaris implementation of the GSS-API works with Kerberos v5, SPNEGO, and Diffie-Hellman encryption. The GSS-API is primarily used to design or implement secure application protocols. GSS-API can provide services to other kinds of protocols, such as SASL. Through SASL, GSS-API provides services to LDAP.
GSS-API is typically used by two peer applications that are communicating over a network after the initial establishment of credentials has occurred. GSS-API is used by login applications, NFS, and ftp, among other applications.
See Writing Applications That Use GSS-API for an introduction to GSS-API. GSS-API Client Example and GSS-API Server Example provides the source code descriptions of two typical GSS-API applications. Sample C-Based GSS-API Programs presents the code listings for the GSS-API examples. GSS-API Reference provides reference material for GSS-API. Specifying an OID demonstrates how to specify a mechanism other than the default mechanism.
SASL – Simple authentication and security layer. SASL is used largely by protocols, for authentication, privacy, and data integrity. SASL is intended for higher-level network-based applications that use dynamic negotiation of security mechanisms to protect sessions. LDAP is one of the better-known consumers of SASL. SASL is similar to GSS-API. SASL is on a somewhat higher level than GSS-API. SASL consumes GSS-API services. See Writing Applications That Use SASL.