Previous section.

X/Open Single Sign-on Service (XSSO) -<br> Pluggable Authentication Modules

X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
Copyright © 1997 The Open Group

PAM Configuration Administration

The syntax and semantics of the PAM configuration data are part of this specification. However, the physical form in which that configuration data is stored is not specified.

Existing implementations of PAM utilize a file, pam.conf, located on each platform supporting PAM to hold the PAM configuration data. It is not a requirement of this specification that an implementation needs to support a local pam.conf file. A centralized service could be provided for ease of administration.

The current PAM configuration syntax supports the definition of PAM behavior on a host/service basis. The possibility of extending the PAM configuration file to include user identities and thus support a host/user/service basis has been discussed during the development of this specification but has been deferred to a future version.

This specification does not include any definition of the way in which underlying modules are configured, except where module specific parameters are to be included in the options field as part of an entry within the PAM configuration data. The purpose and value of this specification is to define a common interface to authentication and other types of modules. The mechanism by which the modules used are configured is implementation specific.

Mapping Service Configuration

The mapping service is configured through the PAM configuration file. Such services are identified by a PAM type mapping. Just like the other PAM types, mapping modules can be specified on a per service basis or for all services through the "OTHER" entry. Multiple mapping modules can also be stacked.

It is not a requirement for the module providers to use mapped user names or passwords. If mapping is supported, the module provider should document whether mapping is provided and whether for user names, passwords, or both. The system administrator can enable mapping on a per application basis through the use of option flags such as "map=user" or "map=pass". Based on such flags, the modules should call pam_get_user() or pam_get_mapped_username() to get the name of the user.

It is the responsibility of the PAM engine to load the mapping services and route the "get" and "set" calls to the appropriate mapping services, and return appropriate status to the calling module. This is very similar to the way PAM engine handles other PAM types such as auth.

If there are multiple mapping modules, the semantics of the control flags (that is, optional, required, and sufficient) require special attention. With multiple mapping services, the desired semantics are that the result from the first successful map will be used. For updates, the new map should be sent to all the configured mapping services so that the appropriate mapping service gets updated. Thus for the get calls, the semantics required are of the sufficient flag, and for the set calls, the semantics required are of the optional flag.

Module Option Parameters

Modules may be supplied with parameters via the options field of a PAM configuration entry. The recommended syntax is:
option
or
option_name=option_value

WHITE SPACE is delimiter between options

Proprietary option names may be used. Collision with standard names is considered to be unlikely and easily addressed by one or other names being changed.

Option names should be registered with The Open Group. The list of registered names will be published by The Open Group, and details about the procedure for registering new option names will also be published. For further details write to:

OGsecurity-request@opengroup.org

That document also describes the procedure for registering new option names.

Additional PAM Options

The introduction of options in the PAM configuration are necessary to accommodate mapping and additional authentication attempts. The following options are defined:

map=user

The module should do mapping for user names.

map=pass

The module should do mapping for passwords.

map

The module should do mapping for user names and passwords.

retry_user

If an authentication service retrieves an invalid user name (this could be due to unsynchronized database), the authentication would fail. If an option such as retry_user were present in the configuration file, the authentication service should prompt the user for another name and reattempt authentication. If this user name is valid, it should update the mapping database, using the appropriate PAM set mapping routines.

retry_pass

If an authentication service retrieves an invalid password (this could be due to unsynchronized database), the authentication would fail. If an option such as retry_pass were present in the configuration file, the authentication service should prompt the user for another password and reattempt authentication. If this password is valid, it should update the mapping database, using the appropriate PAM set mapping routines.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index