United States Patent (19)
`Wu et al.
`
`54). PLUGGABLE ACCOUNT MANAGEMENT
`INTERFACE WITH UNIFIED LOGIN AND
`LOGOUT AND MULTIPLE USER
`AUTHENTICATION SERVICES
`
`75 Inventors: Tajen R. Wu, Fremont; William A.
`Shannon, Los Altos; Paul Fronberg,
`Redwood City; Donald R. Stephenson,
`Pleasanton; Vipin Samar, Cupertino, all
`of Calif.
`
`73 Assignee: Sun Microsystems, Inc., Mountain
`View, Calif.
`
`21 Appl. No.: 499,487
`22 Filed:
`Aug. 7, 1995
`(51) Int. Cl." ........................................................ H04L 9/32
`52 U.S. Cl. ................................................................ 380/25
`58 Field of Search ................................................. 380/25
`
`56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,851,994 7/1989 Toda et al. .............................. 364/200
`5,032,979
`7/1991 Hecht et al. ............................ 380/4 X
`5,241,594 8/1993 Kung ........................................... 380/4
`5,263,157 11/1993 Janis ........................................ 380/4 X
`5,276,444
`1/1994 McNair .......
`340/825.33
`5,553,239 9/1996 Heath et al. .......................... 380/25 X
`
`Primary Examiner-Gilberto Barron, Jr.
`Attorney, Agent, or Firm-Fenwick & West LLP
`
`USOO5774551A
`Patent Number:
`11
`(45) Date of Patent:
`
`5,774,551
`Jun. 30, 1998
`
`ABSTRACT
`57
`A System and method provide transparent access from any
`System entry Service to multiple account management
`Services, and particularly to multiple authentication Services
`on a computer System, Supporting unified login and logout.
`Transparency between System entry Services and account
`management Services, including authentication, password,
`account, and Session Services, is provided by an application
`programming interface and a configuration file. The con
`figuration file Stores associations between System entry
`Services, and Selected account management Services, and
`allows an individual System entry Service to be associated
`with multiple different ones of a given type of account
`management Service, Such as authentication Services. The
`application programming interface determines dynamically
`in response to a request by a System entry Service for an
`account management operation, Such as authentication of a
`user, which account management Service is associated with
`the System entry Service by reading the configuration file and
`queuing pathnames Stored therein of the account manage
`ment Services associated with the System entry Service
`currently connecting user to the System. The application
`programming interface then invokes the queued pathnames
`for the desired operation. Multiple login is provided by
`encrypting authentication tokens used by the authentication
`Services associated with a given System entry Service with a
`primary authentication token of one of the authentication
`Services, and Subsequently decrypting the encrypted tokens
`as needed to authenticate the user. With unified login, the
`user need only provide the primary authentication token.
`Unified logout is provided by locating and destroying cre
`dentials of the user created by the multiple authentication
`Services in response to a request of the valid user to logout.
`26 Claims, 6 Drawing Sheets
`
`
`
`
`
`137
`TERMINAL
`
`COMPUTER
`
`
`
`
`
`
`
`
`
`
`
`119
`OUTPUT
`DEVICE
`
`17
`INPUT
`DEVICE
`
`
`
`21
`NETWORK
`INTERFACE
`
`
`
`129
`STORAGE
`
`135
`REMOTE
`COMPUTER
`
`ADDRESSABLE MEMORY
`107
`SYSTEM
`ENTRY
`SERVICE
`
`
`
`107
`SYSTEM
`ENTRY
`SERVICE
`
`100
`
`1.
`
`103
`
`107
`SYSTEM
`ENTRY
`SERVICE
`
`131
`OTHER
`SERVICES
`
`123
`PLUGGABLEACCOUNT MANAGEMENT INTERFACE
`t
`
`3
`13
`113
`PASSWORD
`SERVICE
`
`115
`115
`115
`SESSION
`SERVICE
`
`
`
`09
`109
`AUTH.
`SERVICE
`
`
`
`
`
`111
`1
`
`t
`ACCOUNT
`SERVICE
`
`27
`CONFIG. FILE
`
`141
`USER CONT.
`
`143
`CRED. STORE
`
`133
`OPERATING SYS,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`
`
`SS1
`
`
`
`98||
`
`ELOWEH
`
`EOLAEC]
`
`BOIAEO
`
`
`
`X|HOM LEN | 21
`
`HOW-IHELNI
`
`

`

`U.S. Patent
`
`Jun. 30, 1998
`
`Sheet 2 of 6
`
`5,774,551
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`201
`Determine Module Type,
`Invoking Service from
`User Handle
`
`
`
`
`
`
`
`
`
`2O3
`Read Entry in
`Configuration File
`
`
`
`2O5
`Module Type and
`Service Match?
`
`
`
`
`
`
`
`
`
`
`
`2O7
`Add Pathname to Queue
`
`
`
`209
`End of Configuration
`File?
`
`
`
`
`
`21
`For Each Queued
`Pathname
`
`213
`invoke Method On
`Service at
`Pathnane
`(SUCCESS/
`FAILURE)
`
`(FAILED), YES
`
`(SUCCESS)
`
`FIGURE 2
`
`

`

`US. Patent
`
`2m
`
`:80..on.<$82mumMA$585EX5?fig05%3.>a1.mmm296:
`9.6m5Amficmzvcoamwm
`E=ooo<gig}m522m:maimuoéEmmofimmpz.223:commowcm.mo_>mmm
`
`
`
`
`5mm835mR:38.<..uM:mJ.xokSm
`5m:.25;22m:.33383553”mom0,m2m38zo_.r<o:.zm=._5<Hzaooo<mom‘W$on.5329;2596m52603.5
`
`
`
`
`
`
`:EmIKnFmmom22.5n.
`
`
`
`
`5Fm:F:m:Eamofifié5w:
`
`
`._<_._zmommoszmmm#23002$03meSE963002
`
`
`
`
`
`mosmmw._.zms_m0<z<2:28.<3Em>m._.2m_
`
`
`
`mmo._.mmo_>mmmmo_>mmmmo_>mmm
`
`
`
`
`
`5,774,551
`
`
`
`m.WEDGE
`
`5.
`
`$15
`
`wwoSmwm
`
`
`
`

`

`U.S. Patent
`
`Jun. 30, 1998
`
`Sheet 4 of 6
`
`5,774,551
`
`FIGURE 4
`
`
`
`
`
`45
`Global Token
`Available?
`
`
`
`421
`Initiate Conversation
`with System Entry
`Service to Obtain
`Primary A.Token
`
`
`
`
`
`
`
`Global Token
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`401
`Get User Handle,
`Authentication Token,
`Global Token, Flag
`
`403
`Flag = Use Map?
`
`YES
`405
`Global Token
`Available?
`Global Token YES
`408
`Get Secondary A.
`Token and Decrypt wth
`GlobalToken
`
`
`
`407
`Verify Token
`
`409
`Verification
`Successful?
`
`411
`Global Token
`Available?
`
`413
`Store A. Token in
`Global Token
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Return Error
`
`

`

`U.S. Patent
`
`Jun. 30, 1998
`
`Sheet S of 6
`
`5,774,551
`
`EOLAHES
`
`NOILWOILNEHLOV
`
`
`
`TWILNEOBHO
`
`E??O 1S
`
`N /09
`
`( 80?ues L
`
`BOWHEELN||
`
`SEOLAHES
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Jun. 30, 1998
`
`Sheet 6 of 6
`
`5,774,551
`
`
`
`601
`Determine User
`
`
`
`
`
`603
`Verify User
`
`605
`User Verified?
`
`
`
`607
`Locate User
`Credentials
`
`609
`Destroy Credentials
`
`
`
`
`
`
`
`FIGURE 6
`
`

`

`5,774,551
`
`1
`PLUGGABLE ACCOUNT MANAGEMENT
`INTERFACE WITH UNIFIED LOGIN AND
`LOGOUT AND MULTIPLE USER
`AUTHENTICATION SERVICES
`
`2
`of independence further hampers the adaptability of the
`computer System, and increases the difficulty of System
`maintenance. These problems also apply to the other aspects
`of the account management System, Such as the Session,
`password, and account components that Separately admin
`ister these aspects of the user's interaction with the computer
`System.
`For any computer Security System to be Successful, it must
`be easy to use. However, in conventional Systems where
`multiple authentication Services are used to authenticate the
`user, the user must typically remember or provide an authen
`tication token, for each authentication System. Authentica
`tion tokens include password, public keys, private keys,
`Smart card personal identification numbers, biometric data
`Such as retinal Scans, fingerprints, Voiceprint, and the like.
`This requirement typically makes it difficult for the user to
`access the System, especially where each authentication
`Service has different requirements for allowable characters,
`length of key, age restrictions on keys, and other particular
`parameters. The use of multiple authentication tokens may
`be particularly difficult for novice users who are not familiar
`with the underlying System Security policies or authentica
`tion Services.
`Another problem with the use of multiple authentication
`Services arises when the user attempts to logout and termi
`nate their Session. When a user is authenticated, the user's
`credentials, including the user's authentication token, are
`typically Stored on the System. Storing the credentials is
`generally part of the Security System of the computer, and
`allows a System administrator to determine who is currently
`logged into the computer, which resources are being used,
`and other account related information. Currently, there is not
`provided a single logout mechanism that locates and
`destroys the credentials created by the various authentication
`Services used to authenticate the user. Rather, the user
`currently must manually destroy the credentials by invoking
`for each authentication Service the appropriate function to
`remove the credentials created by that authentication Ser
`Vice. For example, to destroy credentials created by a
`Diffie-Hellman authentication service, the user must invoke
`Keylogout on a UNIX(R) system which locates the private
`key of the user and removes it. Similarly, on a UNIX(R)
`System with a KerberOS authentication Service, the user must
`invoke kdestroy. Other authentication services have their
`own particular key removal or destruction process.
`Manual destruction of credentials presents Several prob
`lems. First, it eliminates the transparency of the authentica
`tion Services to the user. One of the essential ideas in
`providing a multiple authentication System is that the Sepa
`rate Services are transparent to the user, who needs only to
`initiate their login process for whatever type of connection
`being made. Requiring the user to then directly interact with
`the underlying authentication Services by invoking multiple
`different commands removes the transparency, and thus the
`ease of use of the authentication System as a whole. Second,
`while the user could modify a UNIX(R) logout file, or similar
`file on other Systems, that contains a number of processes to
`execute on logout, this requires that the user have a high
`degree of familiarity with the particular authentication
`Services, and the configuration of System files and Scripts.
`This high level of training is not applicable to the broad
`variety of users of Such system. Third, modification of
`logout files to initiate logouts of all authentication Services
`would result in logging out the user from all current
`Sessions, even if the user desires only to logout of one
`Session. This is an undesirable side effect that may frustrate
`many users, as they would be required to login again to
`re-establish one of the Sessions.
`
`25
`
`35
`
`40
`
`BACKGROUND
`1. Field of the Invention
`The invention relates generally to methods and Systems
`for managing user access to networked computers, and more
`particularly, to methods and Systems that Support the use of
`user authentication, account, password, and Session man
`agement Services.
`2. Background of the Invention
`Many computer Systems, particularly networked com
`15
`puter Systems Supporting many users, generally employ
`Some form of an account management System to track
`authorized users of the System, the type of account each user
`has, including what Services or resources are available to the
`user, each user's password, and the details of each Session
`the user has on the computer System. One of the critical
`aspects of account management is the authentication of users
`attempting to access the computer System.
`Conventional networked computer Systems typically pro
`vide in an account management System one or more mecha
`nisms that authenticate the identity of a user attempting to
`access the System. The authentication Services typically rely
`on data that is uniquely associated with a user to establish
`the user's identity. Conventional authentication Services
`include various password or key-based protocols Such as
`DES, Kerberos, Diffie-Hellman; biometric systems, such as
`retina Scans, fingerprint Scans, and Voiceprint analysis,
`challenge/response Systems that require the user to respond
`to a varying coded prompt with an appropriate response
`algorithmically dependent on the prompt; and hardware
`devices Such as Smart-cards encoded with information par
`ticular to the user. One factor authentication Systems use a
`Single authentication Service to authenticate the user. Multi
`factor Systems combine authentication Services, Such as a
`password and a retina Scan.
`Most computer Systems Support various types of System
`entry Services, Such as UNIXOR login, ftp, telnet, passwd,
`rlogin, and the like. These System entry Services are gener
`ally coupled directly to the authentication Service, whether
`one factor or multi-factor, to authenticate users during the
`initial connection and authentication process. The authenti
`cation Service is generally accessed through hard coded rules
`or linkages in the Source code of each of the System entry
`Services. If multiple authentication Services are used to
`increase the Security of the computer System, then each
`System entry Service must be coded or otherwise directly
`linked with each authentication Service.
`One problem with this approach is that it results in a very
`Specific combination of authentication Services, and requires
`Source code modification of the System entry Services in
`order to couple them to the authentication Services. Second,
`as the Strength of existing authentication Services declines
`over time, and as new authentication technologies are
`developed, a hard-coded approach Severely limits System
`administrator's ability to incorporate new authentication
`Services into the authentication System. Third, in this
`approach the System entry Services are not truly independent
`of the authentication services, but rather effectively inte
`grated with them. The System administrator is unable to
`easily Specify the use of particular authentication Services
`for a given type of System entry Service Since all System
`entry Services use the same authentication Services. The lack
`
`65
`
`45
`
`50
`
`55
`
`60
`
`

`

`3
`Accordingly, it is desirable to provide a System and
`method that Separates the System entry Services from the
`account management System in Such a way that any com
`bination of particular account management Services may be
`Specified for use with particular System entry Services, Such
`that the use of the account management Services is trans
`parent to the System entry Services, and the user. In
`particular, it is desirable to provide a System that allows
`Specific System entry Services to be associated with Selected
`authentication Services in an easily configurable, flexible
`manner. It is also desirable to provide a System and method
`where user is able to employ a single authentication token
`with any number multiple authentication Services to obtain
`a unified login. It is finally desirable to provide a System to
`provide unified logout So that the user does not have to
`manually logout and destroy credentials created during the
`authentication process.
`SUMMARY OF THE INVENTION
`The present invention overcomes the foregoing various
`limitations by providing an application programming inter
`face that mediates between the System entry Services and the
`account management Services on a computer, and a facility
`that Stores Service associations between each System entry
`Service and Selected ones of the account management Ser
`vices. The application programming interface receives invo
`cations from a given System entry Service for a given type of
`functionality, determines which particular account manage
`ment Services are associated with the invoking System entry
`Service, any restrictions or parameters of Such asSociation,
`and then invokes the appropriate account management Ser
`vice to provide the requested functionality. In a preferred
`embodiment the Service associations are Stored in a con
`figuration file, but other types of Storage facilities may also
`be used. The application programming interface is “plug
`gable” because any number of different account manage
`ment Services may be accessed by the application program
`ming interface through the Service associations. Thus, the
`application programming interface transparently and
`dynamically links a particular requested operation of a
`particular System entry Service with the appropriate account
`management Service, or Services for providing that opera
`tion. The application programming interface is here called a
`pluggable account management interface.
`The configuration file or other facility managing the
`Service associations allows for the establishing associations
`between a given System entry Service and multiple instances
`of a given account management Service type, Such as
`authentication, Session, and the like. The ability to provide
`Such multiple associations is called "stacking.” Stacking
`account management Services is particularly useful with
`authentication Services, providing multiple authentication
`Services for any given System entry Service, without the need
`to modify the Source code of each System entry Service to
`provide Such relationships.
`Stacking of authentication Services further Supports uni
`fied login and logout. Unified login is accomplished through
`a authentication token mapping process. This proceSS uses a
`user's primary authentication token for a primary authenti
`cation Service, Such as a password, private key, or other
`unique data, to encrypt the user's other authentication tokens
`for other Secondary authentication Services. The encrypted
`authentication tokens, along with data indicating which
`authentication Services they are associated with, are Stored in
`an available Storage facility, Such as a user context, naming
`Service, Smart card, or the like. In this manner, the user need
`only remember or provide a single authentication token to
`
`4
`the computer System, even though multiple authentication
`Services are Supported.
`The present invention further provides for unified logout
`in a transparent and easy to use and administer fashion by
`providing a transparent credential destruction process that
`handles the identification and removal of a user's credentials
`during a single logout process. The credential destruction
`process may be implemented either as an additional Service
`Separate from each of the authentication Services that create
`the credentials, or it may be incorporated into each authen
`tication Service as appropriate. The pluggable account man
`agement interface determines which authentication Service,
`or other Service that is Selected for providing destruction of
`credentials. The pluggable account management interfaces
`invokes of Such Service to provide a credential destruction
`process. The credential destruction proceSS determines the
`user requesting destruction of the credentials, Verifies that
`the user is the actual user for those credentials, locates the
`credentials as Stored by the authentication Service, and
`removes them from the System. In conjunction with the
`pluggable account management interface, the credential
`destruction process operates without the user having to
`manually invoke particular Services to destroy the creden
`tials.
`With the pluggable account management interface, uni
`fied login and logout together provide Substantial improve
`ments in the ease of use of otherwise complex computer
`Security Systems. This is particularly important as computer
`Systems are increasingly used in organizations with many
`novice users for whom it is not possible or efficient to
`provide extensive, detailed training on the underlying com
`mands and use of the computer System's various account
`management Services. Further, the use of the Service asso
`ciations in the configuration file, or other Storage facility
`Substantially increases ease of System administration and the
`flexibility of the computer system.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a computer System including
`the pluggable account management interface of the present
`invention.
`FIG. 2 is a flowchart of the operation of the pluggable
`account management interface in response to invocations for
`Services via the configuration file.
`FIG. 3 is a dataflow diagram illustrating the process of
`connecting to the computer System with a unified login.
`FIG. 4 is a flowchart of the process of handling multiple
`authentication Services for providing unified login through
`authentication token mapping.
`FIG. 5 is a dataflow diagram illustrating the process of
`disconnecting from the computer System during a unified
`logout.
`FIG. 6 is a flowchart of a process of handling multiple
`authentication Services for unified logout with multiple
`credentials.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`System Architecture
`Referring now to FIG. 1, there is shown one embodiment
`of a computer System providing a pluggable account man
`agement interface with unified login and logout, and mul
`tiple authentication services. The system 100 includes a
`computer 101, having an addressable memory 103, a pro
`
`5,774,551
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`5,774,551
`
`S
`cessor 115, input 117 and output devices 119, a network
`interface 121, and a mass Storage device 129. Users may
`connect through the network interface 121 to the computer
`system 100 over a network 139, such a LAN, WAN, or the
`like, from either a remote computer 135, or a terminal 137,
`or other similar device.
`The addressable memory 103 further includes a number
`of system entry services 107, a number of authentication
`services 109, account Services 111, password services 113,
`and session services 115. These services are jointly referred
`to as account management Services. Each Such Service
`provides particular functionality in managing the accounts
`of the users of the system 100, as further described below.
`The addressable memory 103 further includes a pluggable
`account management interface 123, and a set of other
`services 131 available to authorized users of the computer
`101. The other services 131 include any type of application,
`files, or data. Storage for user credentials is provided by a
`credential Store 143, or may provided in other Storage
`facilities, both private, for example, a Smart card, or public.
`Storage for encrypted authentication tokens is preferably
`provided in a user context 141 or other similar facility.
`The computer 101 may be realized by most general
`purposes computers, such as a SPARCstationTM computer
`manufactured by Sun Microsystems, Inc. of Mountain View,
`Calif. Any other general purpose computer may also be
`adapted for use with the invention. Computer 101 executes
`a general purpose operating System 133, Such as Sun Micro
`Systems Solaris(E) operating System, resident in the addres
`sable memory 103. The operating system 133 and various
`services provided in the addressable memory 103 are
`executed by the processor 115 in a conventional manner. The
`processor 115 also reads and writes data and code files to and
`from the mass storage device 129.
`System Entry Services
`The computer 101 includes one or more system entry
`services 107. The system entry services 115 are invoked by
`the processor 115 and the operating system 133 when a user
`attempts to access the computer 101. The System entry
`services 115 include, for example, UNIX(R) login, Sulogin,
`dtlogin, rlogind, uucpd, ftp, telnet, and the like. Generally,
`each system entry service 107 includes as attributes con
`nection data describing the operational, network, and con
`nection parameters used by the system entry service 107 to
`connect to the computer 101 via the network 139.
`Each system entry service 107 generally includes a
`method that provides the necessary processing to establish a
`connection over the network 139, telecommunication lines,
`or the like between the user's computer 135 or other device,
`and the computer 101. Such a method may be internal to the
`system entry service 107, or may provide an external inter
`face to the user; for the purposes of this disclosure the
`method used by each system entry services 107 to connect
`a user to the computer 101 is here generally labeled the
`“connect method.” It is understood by those of skill in the art
`that the actual method names employed by any of the
`Services referred to herein may vary in actual practice; the
`names are chosen here to be representative of the function
`ality. The connect method performs useful handshaking and
`error-checking to establish a networked connection for a
`user. The connect method further provides transaction con
`trol over other Set up functions, including authentication,
`account Validation, and the like. The process of connecting
`to the computer 101 via the connect method is further
`described below with respect to FIG. 3.
`
`6
`Each system entry service 107 further includes a method
`that terminate the user's Session on the computer. This
`method, here called “disconnect,” may be explicitly invoked
`by the user, for example with the “bye' command during an
`ftp Session, or implicitly invoked by the operating System
`133, for example where the user simply turns off his
`computer. The disconnect method terminates or completes
`any processes that the user has initiated, and Severs the
`connection between the user and the computer 101. The
`process of disconnecting from the computer via the discon
`nect method is further described below with respect to FIG.
`5.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Pluggable Account Management Interface
`Intermediating between the system entry services 107 and
`the various account management Services is a pluggable
`account management interface 123. The pluggable account
`management interface 123 allows any System entry Service
`107 to be used transparently with any combination of
`account, password, Session, or authentication Services 109,
`including multiple instances of a given type of account
`management Service. In this manner the pluggable account
`management interface 123 Supports the unified login and
`logout with multiple authentication services 109.
`The pluggable account management interface 123 is pref
`erably a library of methods that the system entry services
`107 invoke to obtain desired functionality from the various
`account management Services. When called, the pluggable
`account management interface 123 determines Selected ones
`of the account management Services associated with a given
`system entry service 107, and invokes selected methods of
`these account management Services, for example, to authen
`ticate the user, initiate or terminate a Session, or to and
`perform other account management operations. AS a Specific
`example, where the user is attempting to connect to the
`computer 101 through a login system entry service 107, the
`pluggable account management interface 123 dynamically
`determines which particular authentication service 109,
`account Services 111, password Services 113, and account
`Services 115, if any, are to specifically used with the login
`system entry service 107, and invoke any method of Such
`Services as requested by the login System entry Service 107.
`Since the pluggable account management interface 123
`handles the determination and invocation of the account
`management Services, both the user and System entry Service
`107 may interface transparently with any account manage
`ment service, without the system entry service 107 having to
`be hardcoded to specific account-management Service for
`providing the desired functionality.
`The particular methods of the pluggable account manage
`ment interface 123 are further discussed following a descrip
`tion of the configuration file 127.
`Configuration File
`In the preferred embodiment, the pluggable account man
`agement interface 123 determines the Selected account man
`agement Services associated with a given System entry
`service 107 through the configuration file 127. The configu
`ration file 127 allows multiple different ones of a selected
`account management Service type (account, Session,
`password, or authentication) to be dynamically associated
`with a given system entry service 107. The ability to use
`multiple different ones of a given account management
`Service is called "Stacking,” and it is particularly useful in
`conjunction with the authentication Services. The configu
`ration file 127 allows multiple authentication services 109 to
`
`

`

`7
`be stacked for authenticating a user, and further enables
`unified login to such stacked authentication services 109
`with a single password, and unified logout with a single
`logout command.
`Generally, the configuration file 127 stores a set of service
`asSociations. Each Service association relates one System
`entry service 107 with one or more selected account man
`agement Services. The Selected account management Ser
`vices may be of the same type, or from various types. The
`Service associations form a decision table used by the
`pluggable account management interface 123 to determine
`which account management Service is to be used provide
`account management functionality in response to the use of
`a particular system entry service 107.
`In the preferred embodiment, each Service association is
`a generally a tuple comprising the following information:
`<System entry Service name, account management Service
`type, control flag, account management Service path name,
`option parameters>
`Table 1 illustrates an example of one set of possible
`Service associations in a configuration file 127, and the
`description of the various elements of the Service association
`tuple will refer to this example:
`
`15
`
`5,774,551
`
`8
`may be any other type of account management Service that
`is implemented on the computer 101. The module type
`designation is used at various Stages of processing by the
`pluggable account management interface 123 to determine
`which account management Service of a given type is to be
`invoked in response to a request by a System entry Service
`107. Generally, the pluggable account management interface
`123 reads the configuration file to identify the service
`asSociations having a certain module type, and then queues
`the Specified pathnames for invoking the Specific Services
`listed for that module type.
`The account management Service pathname field Specifies
`the location of the account management Service on the
`computer 101 or network 133. The pluggable account man
`agement interface 123 loads the Specified Service upon
`demand of the system entry service 107 to invoke the
`required function. For any given system entry service 107,
`multiple different account management Service pathnames,
`and hence account management Services of a given type,
`may be specified. This is Stacking of account management
`Services. In the preferred embodiment, when a System entry
`Service 107 that is associated with Stacked account manage
`ment Services requests an operation thereof, the pluggable
`account management interface 123 invokes the account
`
`TABLE 1.
`
`System Entry
`Service
`Name
`login
`login
`login
`login
`ftp
`ftp
`
`Account
`Account
`Management Control Management Service
`Service Type
`Flag Path Name
`authentication required fusr/lib/PAM/unix auth.So.1
`authentication required fusr/lib/PAM/unix RSA.so.1
`session
`required fusr/lib/PAM/unix session.so.1
`account
`required fusr/lib/PAM/unix account.so.1
`authentication required fusr/lib/PAM/kerberos auth..so.1
`authentication required fusr/lib/PAM/rsa auth.So.1
`
`ftp
`ftp
`:
`:
`
`optional fusr/lib/PAM/unix session.so.1
`session
`optional fusr/lib/PAM/unix account.So.1
`account
`required fusr/lib/PAM/unix password.s.o.1
`password
`authentication optional fusr/lib/PAM/diffie auth.so.1
`
`Option
`Parameters
`
`use map
`debug
`
`uSe
`default
`
`The System entry Service name field denotes one of the
`system entry services 107 available on the computer system
`100, for example login, telnet, ftp, and the like, for which the
`Service association is defined. In addition to individually
`Specifying a Single System entry Service 107, a universal, or
`wild card, character, for example “*”, may be used to
`indicate all system entry services 107. In the preferred
`embodiment, Service associations that Specify a particular
`system entry service 107 for a given type of account
`management Service take precedence over associations that
`specify all system entry services 107 through a wildcard. In
`the example of Table 1, the wild card in the last entry
`indicates that for all system entry services 107 other than
`those already Specified, authentication is optional, and per
`formed by an authentication service 109 providing Diffie
`Hellman authentication. The wild card may also be used, in
`the preferred embodiment if all system entry services 107
`have the same association to a given account management
`Service. For example, the Second to last entry indicates that
`all system entry services 107 use the password service 123
`module provided in the UNIX(R) operating system to change
`the authentication token of the user.
`The module type field indicates the type of accoun