Pluggable Authentication Module

The Pluggable Authentication Module(PAM) API was developed by Sun in response to the proliferation of authentication and authorization technologies available on Solaris systems.

The aim with PAM is to provide a pluggable framework that allows the authentication-using application (such as telnet, rlogin, ftp and J2EE applications) to be de-coupled from the underlying authentication-providing service (such as Kerberos, LDAP, S/Key, RSA and DCE). PAM unifies the authentication and authorisation of system users' credentials, and allows for the system administrators to plug authorisation services in and out of systems purely through configuration.

This initiative combines well with current trend towards single-signon systems in which the credentials of systems users are stored and verified centrally and are accessed by disparate system applications to allow users access to their services with the same username/password credentials.

Sun defines the following goals for PAM:

• The system administrator should be able to choose the default authentication mechanism for the machine. This can range from a simple password-based mechanism to a biometric or a smart card based system.
• The administrator should be able to configure the user authentication mechanism on per application basis. For example, a site may require S/Key password authentication for telnet access, while allowing console login sessions with just UNIX password authentication.
• The framework should support the display requirements of the applications. For example, for a graphical login session, the user may have to enter the user name, and the password may have to be entered in a new window. For networking services, such as ftp and telnet , the user name and password has to be transmitted over the network to the server machine.
• The administrator should be able to configure multiple authentication protocols for each application. For example, one may want the users to get authenticated by both Kerberos and RSA authentication systems.
• The administrator should be able to configure the system so that the user is authenticated with all authentication protocols without retyping the password.
• The system-entry services should not have to change when the underlying mechanism changes. This can be very useful for third-party developers who often do not have the source code for these services.
• The architecture should provide for a pluggable model for system authentication, as well as for other related tasks, such as password, account, and session management.
• For backward-compatibility reasons, the architecture should support the authentication requirements of the current system-entry services.
• The API should be independent of the operating system.

The PAM framework consists of two parts:

• Authentication library API - this API provides the front-end integration that allows authentication-using applications to authenticate via PAM.
• Authentication mechanism-specific modules - these modules are the mechanism-specific implementations of the PAM back-end which preform the actual authentication and authorisation on behalf of the front-end application. The various services are connected to PAM via the Service Provider Interface(SPI).

Subsequent to its introduction with Solaris 2.5 the API has been adopted by several other operating systems, including Linux.
Windows implementations are also available.
A Java implementation of PAM is included in JDK1.4 and forms the core of the Java Authentication and Authorization Service (JAAS).