Page 229 - DCAP311_DCAP607_WIRELESS_NETWORKS

Unit 14: Authentication

guide identified that simple-password authentication is insufficient for ensuring authorized Notes
access to important financial services. Many other regulatory provisions also have identified
similar needs, such as the Homeland Security Presidential Directive (HSPD)-12, Electronic
Signatures in Global and National Commerce (E-SIGN) Act, Federal Information Processing
Standards Publication (FIPS PUB) 201-1, HIPAA, SOX, GLBA, PATRIOT, and so on.
Subsequently, various methods have been developed to improve the "strength" of an
authentication system in withstanding identity-theft attacks. While the spectrum of methods
spans a wide range of concern areas—such as enterprises, consumers, hardware, mobility, and
so on—this article focuses on methods that are used to implement strong user authentication
for online-consumer identities. It discusses effective solution approaches, overall architecture
design, and emerging developments.

14.1.1 Importance of User Authentication

Each user is required to log in to the system. The user supplies the user name of an account and a
password if the account has one (in a secure system, all accounts must either have passwords or
be invalidated). If the password is correct, the user is logged in to that account; the user acquires
the access rights and privileges of the account. The /etc/passwd and /etc/security/passwd files
maintain user passwords.
By default users are defined in the Files registry. This means that user account and group
information is stored in the flat-ASCII files. With the introduction of plug-in load modules, users
can be defined in other registries too. For example, when the LDAP plug-in module is used for
user administration, then the user definitions are stored in the LDAP repository. In this case
there will be no entry for users in the /etc/security/user file (there is an exception to this for the
user attributes SYSTEM andregistry). When a compound load module (i.e. load modules with an
authentication and database part) is used for user administration, the database half determines
how AIX® user account information is administrated, and the authentication half describes the
authentication and password related administration. The authentication half may also describe
authentication-specific user account administration attributes by implementing certain load
module interfaces (newuser, getentry, putentry etc).
The method of authentication is controlled by the SYSTEM and registry attributes that are defined
in the /etc/security/user file. A system administrator can define the authcontroldomain attribute
to the /etc/security/login.cfg file to force the SYSTEM and registry attributes to be retrieved from
the authcontroldomain. For instance, authcontroldomain=LDAP forces the system to look for
user's SYSTEM and registry from LDAP to determine the authentication method that was used
for the user. There is an exception for locally defined users where the authcontroldomain setting
is ignored , and the SYSTEM and registry are always retrieved from /etc/security/user file.
The acceptable token for the authcontroldomain attribute is files or a stanza name from the/usr/
lib/security/methods.cfg file.
The value of the SYSTEM attribute is defined through a grammar. By using this grammar, the
system administrators can combine one or more methods to authenticate a particular user to the
system. The well known method tokens are compat, DCE, files and NONE.
The system default is compat. The default SYSTEM=compat tells the system to use the local
database for authentication and, if no resolution is found, the Network Information Services
(NIS) database is tried. The files token specifies that only local files are to be used during
authentication, whereasSYSTEM=DCE results in a DCE authentication flow.
The NONE token turns off method authentication. To turn off all authentication, the NONE token
must appear in the SYSTEM and auth1 lines of the user's stanza.

You can specify two or more methods and combine them with the logical constructors AND and OR.
For instance SYSTEM=DCE OR compat indicates that the user is allowed to login if either DCE or
local authentication (crypt()) succeeds in this given order.

LOVELY PROFESSIONAL UNIVERSITY 223