Developer's Guide to Oracle Solaris Security

Introduction to GSS-API

GSS-API enables programmers to write applications generically with respect to security. Developers do not have to tailor the security implementations to any particular platform, security mechanism, type of protection, or transport protocol. With GSS-API, a programmer can avoid the details of protecting network data. A program that uses GSS-API is more portable with regards to network security. This portability is the hallmark of the Generic Security Service API.

GSS-API is a framework that provides security services to callers in a generic fashion. The GSS-API framework is supported by a range of underlying mechanisms and technologies, such as Kerberos v5 or public key technologies, as shown in the following figure.

Figure 4–1 GSS-API Layer

Diagram shows the GSS-API and protocol layers between
the application and the security mechanisms.

    Broadly speaking, GSS-API does two main things:

  1. GSS–API creates a security context in which data can be passed between applications. A context is a state of trust between two applications. Applications that share a context recognize each other and thus can permit data transfers while the context lasts.

  2. GSS–API applies one or more types of protection, known as security services, to the data to be transmitted. Security services are explained in Security Services in GSS-API.

In addition, GSS-API performs the following functions:

GSS-API includes numerous support and convenience functions.

Application Portability With GSS-API

GSS-API provides several types of portability for applications:

Security Services in GSS-API

GSS-API provides three types of security services:

Available Mechanisms in GSS-API

The current implementation of GSS-API works with the following mechanisms: Kerberos v5, Diffie-Hellman, and SPNEGO. For more information on the Kerberos implementation, see Chapter 21, Introduction to the Kerberos Service, in System Administration Guide: Security Services for more information. Kerberos v5 should be installed and running on any system on which GSS-API-aware programs are running.

Remote Procedure Calls With GSS-API

Programmers who use the RPC (Remote Procedure Call) protocol for networking applications can use RPCSEC_GSS to provide security. RPCSEC_GSS is a separate layer that sits on top of GSS-API. RPCSEC_GSS provides all the functionality of GSS-API in a way that is tailored to RPC. In fact, RPCSC_GSS serves to hide many aspects of GSS-API from the programmer, making RPC security especially accessible and portable. For more information on RPCSEC_GSS, see Authentication Using RPCSEC_GSS in ONC+ Developer’s Guide.

The following diagram illustrates how the RPCSEC_GSS layer sits between the application and GSS-API.

Figure 4–2 RPCSEC_GSS and GSS-API

Diagram shows the RPCSEC_GSS layer, which provides security
for remote procedure calls.

Limitations of GSS-API

Although GSS-API makes protecting data simple, GSS-API avoids some tasks that would not be consistent with GSS-API's generic nature. Accordingly, GSS-API does not perform the following activities:

Language Bindings for GSS-API

This document currently covers only the C language bindings, that is, functions and data types, for GSS-API. A Java-bindings version of GSS-API is now available. The Java GSS-API contains the Java bindings for the Generic Security Services Application Program Interface (GSS-API), as defined in RFC 2853.

Where to Get More Information on GSS-API

These two documents provide further information about GSS-API: