The PAM framework consists of four parts:
Applications that use PAM, also referred to as PAM consumers
PAM framework, also referred to as the PAM library (see libpam(3LIB))
PAM configuration, system-wide in /etc/pam.d/ or /etc/pam.conf and on a per-user basis pam_user_policy(5)
PAM service modules, also referred to as PAM service providers
The framework provides a uniform way for authentication-related activities to take place. This approach enables application developers to use PAM services without having to know the semantics of the policy. Algorithms are centrally supplied. The algorithms can be modified independently of the individual applications. With PAM, administrators can tailor the authentication process to the needs of a particular system without having to change any applications. Administrators configure PAM through the per-service files in the /etc/pam.d directory. The /etc/pam.conf file contains legacy configuration.
The following figure illustrates the PAM architecture. Applications communicate with the PAM library through the PAM application programming interface (API). PAM modules communicate with the PAM library through the PAM service provider interface (SPI). Thus, the PAM library enables applications and modules to communicate with each other.
Figure 1 PAM Architecture
The four types of PAM services are:
Authentication service modules (auth) – For granting users access to an account or service. Modules that provide this service authenticate users and set up user credentials.
Account management modules (account) – For determining whether the current user's account is valid. Modules that provide this service can check password or account expiration and time-restricted access.
Session management modules (session) – For setting up and terminating login sessions.
Password management modules (password) – For enforcing password strength rules and performing authentication token updates.
A PAM module can implement one or more of these services. Because the use of simple modules with well-defined tasks increases configuration flexibility, PAM services should be implemented in separate modules. The services can then be 'stacked', that is, placed in the order of execution in the PAM configuration file. See pam.conf(4).
For example, the Oracle Solaris OS provides the pam_authtok_check(5) module for system administrators to configure the site's password policy. The pam_authtok_check(5) module checks proposed passwords for various strength criteria.
For a complete list of Oracle Solaris PAM modules, see man pages section 5: Standards, Environments, and Macros. The PAM modules have the prefix pam_.
The PAM library, libpam(3LIB), is the central element in the PAM architecture:
libpam exports an API, pam(3PAM). Applications can call this API for authentication, account management, credential establishment, session management, and password changes.
libpam looks for the PAM configuration in /etc/pam.conf before the per-service PAM policy files in /etc/pam.d. The PAM configuration specifies the PAM module requirements for each available service and is managed by a system administrator.
libpam imports an SPI, pam_sm(3PAM), which is exported by the service modules.
The login application initiates a PAM session by calling pam_start(3PAM) and by specifying the login service.
The PAM library searches for login entries in the PAM configuration corresponding to the service module type of authentication (auth).
For each module in PAM configuration that is configured for the login service, the PAM library calls pam_sm_authenticate(3PAM). The pam_sm_authenticate() function is part of the PAM SPI. The control flag field in the PAM configuration files combined with the results of each call to pam_sm_authenticate() for the configured modules determines whether the user is allowed access to the system. This process is described in more detail in Configuring PAM in Managing Kerberos and Other Authentication Services in Oracle Solaris 11.3.
In this way, the PAM library connects PAM applications with the PAM modules that have been configured by the system administrator.
PAM consumers must be linked with the PAM library libpam. Before an application can use any service that is provided by the modules, the application must initialize its instance of the PAM library by calling pam_start(3PAM). The call to pam_start() initializes a handle that must be passed to all subsequent PAM calls. When an application is finished with the PAM services, pam_end() is called to clean up any data that was used by the PAM library.
PAM_AUSER – Authenticated user name
PAM_USER – Currently authenticated user
PAM_RUSER – The untrusted remote user name
PAM_AUTHTOK – Password
PAM_USER_PROMPT – User name prompt
PAM_TTY – Terminal through which the user communication takes place
PAM_RHOST – Remote host through which user enters the system
PAM_REPOSITORY – Any restrictions on the user account repository
PAM_RESOURCE – Any controls on resources
For a complete list of available items, see pam_set_item(3PAM). Items can be set by the application through pam_set_item(3PAM). Values that have been set by the modules can be retrieved by the application through pam_get_item(3PAM). However, PAM_AUTHTOK and PAM_OLDAUTHTOK cannot be retrieved by the application. The PAM_SERVICE item cannot be set.