Security Support Provider Interface is a Win32 API used by Microsoft Windows systems to perform a variety of security-related operations such as authentication. SSPI functions as a common interface to several Security Support Providers : A Security Support Provider is a dynamic-link library that makes one or more security packages available to applications.
Windows SSPs
The following SSPs are installed with Windows:
NTLM – Provides NTLM challenge/response authentication for client-server domains prior to Windows 2000 and for non-domain authentication.
Negotiate – Selects Kerberos and if not available, NTLM protocol. Negotiate SSP provides single sign-on capability, sometimes referred to as Integrated Windows Authentication. On Windows 7 and later, NEGOExts is introduced which negotiates the use of installed custom SSPs which are supported on the client and server for authentication.
Secure Channel – Introduced in Windows 2000 and updated in Windows Vista to support stronger AES encryption and ECC This provider uses SSL/TLS records to encrypt data payloads.
Distributed Password Authentication – Provides internet authentication using digital certificates.
Public Key Cryptography User-to-User – Provides peer-to-peer authentication using digital certificates between systems that are not part of a domain.
Comparison
SSPI is a proprietary variant of GSSAPI with extensions and very Windows-specific data types. It shipped with Windows NT 3.51 and Windows 95 with the NT LAN Manager Security Support Provider. For Windows 2000, an implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard RFC 1964 and providing wire-level interoperability with Kerberos 5 implementations from other vendors. The tokens generated and accepted by the SSPI are mostly compatible with the GSS-API so an SSPI client on Windows may be able to authenticate with a GSS-API server on Unix depending on the specific circumstances. One significant shortcoming of SSPI is its lack of, which makes some GSSAPI interoperability impossible. Another fundamental difference between the IETF-defined GSSAPI and Microsoft's SSPI is the concept of "impersonation". In this model, a server can switch to and operate with the full privileges of the authenticated client, so that the operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional model, when a server runs under a service account, it cannot elevate its privileges, and has to perform access control in a client-specific and application-specific fashion. The obvious negative security implications of the impersonation concept are prevented in Windows Vista by restricting impersonation to selected service accounts. Impersonation can be implemented in a Unix/Linux model using the seteuid or related system calls. While this means an unprivileged process cannot elevate its privileges, it also means that to take advantage of impersonation the process must run as root.
