Introduction

Applications do not need to be aware of the actual method used for an identification and authentication method (which could be by means of a username/password pair or biometric fingerprinting, for example), as long as it uses the API (application programming interface) provided.

AIX®, Linux®, and Solaris each use different types of I and A systems. Therefore, in a heterogeneous environment comprising these systems, you need a strategy to provide a uniform mechanism for identification and authentication. This article targets IT personnel who are developing and deploying such an I and A system for their heterogeneous, multi-platform environment.

We begin with an overview of the I and A system and then introduce LAM (loadable authentication modules), PAM (pluggable authentication modules), and NSS (name service switch), which are different existing I and A systems used on the platforms that we cover. Finally, we give implementation guidelines for rolling out such a uniform solution.

Back to top

Overview of identification and authentication

User identification verifies whether the user is a registered user of the system. User authentication verifies whether the user can prove his identity.

A simple example should make things clear. Consider a user telneting to a system:

1. The Telnet client program opens a TCP (Transmission Control Protocol) connection to the Telnet server.
2. The user replies to login query with his username. This provides the identification of the user.
3. The user is prompted for the password shared by the user and the server.
4. The password provides the verification for the user's identity. This completes authentication.

The system which provides the identification and authentication is called an I and A system. It provides a means for extending identification and authentication for new technologies.

The I and A system provides a layer of abstraction between a user application and the implementation of any authentication / identification functions it needs to perform. A user application needs only call functions exported by the UNIX® C library. Based on user-level settings defined by the system administrator, different modules providing different mechanisms (for authentication and / or identification) might be used to perform the actual task.

For instance, the system administrator might require that user "A" on machine "M" be authenticated by a simple username/password pair, using the local password file. Another user "B" on machine "M" might be authenticated by means of, say, a fingerprint sensor, and so on. In all of these cases, the same authentication program will be used, making use of the same functions exported by the security library. However, a different authentication module will be used in each case -- each carrying out the authentication in its respective manner.

Back to top

Comparison chart of authentication and / or identification mechanisms on AIX, Linux, and Solaris

There is a slight difference in the way different UNIX platforms implement identification and authentication. Table 1 below illustrates how this is implemented on AIX, Solaris, and Linux. It provides the names of the subsystems that facilitate the implementation of identification and authentication modules.

Back to top

NSS service

Once a user is authenticated, many applications still need access to user information. This information is traditionally contained in text files (/etc/passwd, /etc/shadow, and /etc/group) but can also be provided by other services. For this purpose, common name service APIs are provided and a set of modules are written that retrieve this information by performing technology-based operations. This service is called NSS. NSS uses a common API and configuration file (/etc/nsswitch.conf) in which the name service providers for every supported database are specified. See System Databases and Name Service Switch in the GNU C Library for additional information.

Figure 1 above shows the path of execution when a C library routine related to identification is called. The C library call first goes to the NSS library, which has exported the common name service APIs. The NSS library first refers to the entries in the /etc/nsswitch.conf file. And then loads the appropriate module required for the request.

The nsswitch.conf file is illustrated in Listing 1 below. The first column is the database and the rest of the lines specify how the lookup process works.

Listing 1. NSS configuration file

# /etc/nsswitch.conf

#

# Name Service Switch configuration file.

#



passwd:     db files nis

shadow:     files

group:      db files nis



hosts:      files nisplus nis dns

networks:   nisplus [NOTFOUND=return] files



ethers:     nisplus [NOTFOUND=return] db files

protocols:  nisplus [NOTFOUND=return] db files

rpc:        nisplus [NOTFOUND=return] db files

services:   nisplus [NOTFOUND=return] db files

Back to top

PAM framework

PAM gives system administrators the flexibility of choosing any authentication service available on the system to perform authentication. The framework also allows new authentication service modules to be plugged in and made available without modifying the application.

The PAM framework consists of an interface library and multiple authentication service modules. The PAM interface library is the layer implementing the API. The authentication service modules are a set of dynamically loadable objects invoked by the PAM API to provide a particular type of user authentication.

Figure 2 below illustrates the relationship between the applications, library, and modules. The applications (FTP, Telnet, and Login) use the PAM API library to access the appropriate module. The pam.conf file defines which modules are to be used with each application. Responses from modules are passed back through the library to the application.

The PAM configuration file, /etc/pam.conf, can be edited to select authentication mechanisms for each system entry application. The file consists of the entries following this syntax:

Service_name module_type control_flag module_path module_option

service_name indicates the name of the service, module_type denotes the module type for the service, control_flag selects the continuation and failure semantics for the module, module_path specifies the pathname to a library object which implements the service functionality, and module_options are specific options that can be passed to the service modules. An example entry in the pam.conf file looks like:

login auth required /usr/lib/security/pam_unix debug

Back to top

The LAM framework

The LAM interface is the AIX default subsystem for providing the identification and authentication facilities. LAM is capable of providing both authentication and identification functions. Each module defines a number of interface subroutines. Which of the possible subroutines must be implemented is determined by what functionality it is meant to provide.

A LAM module is implemented as a shared library. When the LAM module is loaded, an initialization function is executed. This function is the entry point into the library -- it is defined at compile time. Now, the LAM module communicates with the AIX security library through the secmethod_table interface. This interface contains a list of function pointers. Each interface function performs a well-defined operation. The initialization function accepts a pointer to the struct secmethod_table object and sets its function pointers to the corresponding custom implementations of those functions. The security library will now use the custom implementations of functions, which would normally have been performed using the local security database files.

Let's take a simple example to demonstrate, step-by-step, how authentication or identification takes place using a LAM module.

1. An AIX application calls an authentication function in the AIX security library.
2. The /etc/security/user file is then looked up. This file is a set of stanzas. Each stanza contains one or more name/value pairs. LAM enforces policy on a per-user basis. Each stanza in the /etc/security/user file corresponds to one user where these policies are defined. (There is also a default stanza for default policies!) The value of the SYSTEM variable defines the authentication mechanism for a particular user. This value is a keyword -- an index into the /usr/lib/security/methods.cfg file. For example, here's how the entry for user "rahul" might be set.

   * /etc/security/user: * stanza for user "rahul" rahul: . . . SYSTEM="MY_AUTH" . . .

   
   
3. After the value of the SYSTEM variable for a user is read, the /usr/lib/security/methods.cfg file is looked up. The syntax for this file is similar to the /etc/security/user file that is a set of stanzas -- each stanza is a set of name/value pairs. Now, a stanza corresponding to the keyword in the /etc/security/user file is located. The "program" entry in this stanza is the name and path of the LAM module to load. So, the entry in the methods.cfg file corresponding to the "MY_AUTH" keyword in the listing above might be:

   * /usr/lib/security/methods.cfg *stanza for "MY_AUTH" MY_AUTH: program = /usr/lib/security/LAM_MY_AUTH . . .

   
   

   Here, /usr/lib/security/LAM_MY_AUTH is the LAM module that will actually implement the authentication or identification function, which the security library might have otherwise implemented using local files such as /etc/passwd. This LAM module is then loaded and the appropriate function is executed.

   The return value is returned to the application by means of the return value of the function in the security library.

Back to top

Complications on older AIX systems

This section is targeted towards administrators looking to integrate older AIX (prior to Version 5.2) systems into a common A and I framework.

AIX 5.2 and above support PAM natively; a true PAM solution is possible. However, prior to AIX 5.2, applications were not PAM-aware. This meant that AIX had to provide a rather complicated mechanism to achieve authentication using PAM. This section describes how this mechanism works. It also gives a recap of how LAM works.

AIX provides a loadable authentication module (PAM) to provide PAM authentication to native AIX applications. AIX security services call functions offered by the PAM module through the existing LAM framework.

Note that this is a "PAM over LAM" solution, not pure PAM. That is why it is no longer the recommended means to provide authentication to native AIX applications.

This is how LAM is typically used. In this case, however, we would like your application to use the PAM module. Therefore, you need to use the LAM module (PAM) to do the job. In the /usr/lib/security/methods.cfg file, replace the line (see the LAM framework section):

program = /usr/lib/security/LAM_MY_AUTH

with

program = /usr/lib/security/PAM

options = authonly

The LAM module (PAM) routes calls made by AIX security services to the PAM library (libpam.a). In other words, it maps AIX security library functions to functions in the PAM API, where applicable. From here on, it is a pure PAM environment. libpam.a looks up the /etc/pam.conf file to determine which PAM module to load based on the service that invoked the call in the first place. Typically, in such a "PAM over LAM" setup, all authentication functions, regardless of service, make use of the custom PAM module.

Table 2 below shows part of the mapping that the LAM module (PAM) performs:

As is clear, not all AIX security library functions have PAM API equivalents. In such cases, dummy placeholder functions need to be implemented within the PAM module. In the example above, such a function simply returns SUCCESS.

WARNING: For systems that are PAM-aware where applications interface with the PAM library directly, functions within the PAM module can prompt the user for data items such as the user name. In this setup, however, it is not possible to have user dialog within the PAM module. Therefore, any data prompted by an AIX security service is passed to the PAM module using the pam_set_item function. Also, PAM modules should retrieve all data using pam_get_item, and not directly; all user interaction is handled by AIX's security library.

Back to top

Implementation guidelines

If you want to write your own I and A system that works on AIX, Solaris, and Linux, you need to write the following modules:

• NSS module: This module handles identification jobs for Solaris and Linux.
• PAM module: This module handles authentication jobs for Solaris, Linux, and AIX.
• LAM module: This module handles identification jobs for AIX.

There's a lot of documentation on how to implement your own PAM module. This article also includes reference links to example PAM implementations and how-to documents (see Resources).

Now we will try to explain how you can write an NSS module and an LAM module, which offers the same identification functionality. The idea is to have a uniform identification solution across the three platforms. So the actual implementations of the functions (see Table 3) will be much the same, whether it's an LAM or an NSS module.

Let's take a very simple identification system. This system is implemented for password and group entries.

NSS implementation for identification

Now here is how the NSS module, "mynss", will handle identification. Table 3 highlights the password-related entries -- the similar is true for group entries. So, the file which implements identification for password entries will have following functions implemented:

Listing 2 illustrates a typical getpwnam function:

Listing 2. getpwnam function

nss_status_t _nss_mynss_getpwnam( void* mynssinfo, void *data)

{

        nss_XbyY_args_t *lookup_data = (nss_XbyY_args_t *)data;

        int string_length;

  

        printf ("_nss_mynss_getpwnam: called for username %s\n", 

lookup_data->key.name);  /*Here is the implementation which looks 

up for passwd structure entries taking username as an input. This 

passwd structure is filled in the same data pointer’s buffer field 

and is returned*/

        

        return SUCCESS;

}

LAM implementation for identification

A typical LAM module: The module is titled mylam to handle identification functions. Table 4 below shows a minimal list of functions to implement within the file:

Listing 3 represents a sample of the mylam_getpwnam function:

Listing 3. mylam_getpwnam function

struct passwd* adfs_getpwnam (const char *username) {

     /*

     * Get the password information into a struct passwd

     * data structure, and return a pointer to it in case of

     * success, or return NULL.

     */

}

Resources

Learn

• Kernel Extensions and Device Support Programming Concepts : Loadable Authentication Module Programming Interface provides a means for extending identification and authentication (I and A) for new technologies.
  
  
• AIX 5L Security Guide Pluggable Authentication Modules provides an overview of the Pluggable Authentication Modules and how to incorporate multiple authentication mechanisms into an existing system.
  
  
• The AIX user file in the Files Reference manual provides a description of the attribute stanzas for users.
  
  
• The /usr/lib/security/methods.cfg file described in the AIX Files Reference manual contains the information for loadable authentication module configuration.
  
  
• The GNU C Library System Databases and Name Service Switch provides information on configuring the various functions in the C Library to work correctly in the local environment.
  
  
• The Linux-PAM page is the primary distribution site for the Linux-PAM (Pluggable Authentication Modules for Linux) project.
  
  
• Want more? The developerWorks eServer zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on the eServer brand.
  
  
• The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
  
  

Get products and technologies

• Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. You can download evaluation versions of the products at no charge, or select the Linux or Windows® version of developerWorks' Software Evaluation Kit.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Overview of identification and authentication
• Comparison chart of authentication and / or identification mechanisms on AIX, Linux, and Solaris
• NSS service
• PAM framework
• The LAM framework
• Complications on older AIX systems
• Implementation guidelines
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers