United States Patent [19]
`Mashayekhi
`
`US005818936A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,818,936
`Oct. 6, 1998
`
`[54] SYSTEM AND METHOD FOR
`AUTOMICALLY AUTHENTICATING A USER
`IN A DISTRIBUTED NETWORK SYSTEM
`
`Primary Examiner—Stephen C. BucZinski
`Attorney, Agent, or Firm—Cesari and McKenna, LLP
`[57]
`ABSTRACT
`
`[75] Inventor: Cameron Mashayekhi, Provo, Utah
`
`[73] Assignee: Novell, Inc., Orem, Utah
`
`[21] Appl. No.: 617,940
`[22]
`Filed:
`Mar. 15, 1996
`
`[51] Int. Cl.6 ............................ .. H04K 1/00; G06F 12/14
`[52] US. Cl. ................................. .. 380/25; 380/4; 380/49;
`395/188.01
`[58] Field of Search .................................. .. 380/4, 23, 24,
`380/25, 49; 395/188.01
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,073,933 12/1991 Rosenthal ................................ .. 380/25
`5,349,642
`9/1994 Kingdon
`.... .. 380/25
`
`5,594,921
`
`1/1997 Pettus . . . . . . . .
`
`. . . . .. 380/25
`
`5,606,614
`5,625,793
`
`.. 380/23
`2/1997 Brady et al. ..
`4/1997 Priem et al. .............................. .. 380/4
`
`OTHER PUBLICATIONS
`Netscape 2, Special Ed.; Que Corp.; Indianapolis, IN, Sep.
`1, 1995.
`Pro, Aps—Tr—Trg—00—06.03; Manual of the Automated
`Patent System, Sep. 1988.
`Pro, Aps—Tr—Trg—00—06.09; Manual of the Automated
`Patent System, May 29, 1990.
`
`A distributed authentication service that automates an
`authentication exchange between a user and an application
`program of a distributed network system. The novel distrib
`uted authentication service comprises an exchange control
`ler coupled to an authentication database containing a group
`of encrypted application secrets associated With the user.
`Each application secret is, in turn, associated With a par
`ticular program resident in the system. According to the
`present invention, the controller cooperates With the data
`base to automate the exchange procedure by
`receiving an
`authentication inquiry generated by the particular program
`in response to the user’s request to access that program and
`(ii) providing that program With the proper application secret
`retrieved from the database. The group of encrypted appli
`cation secrets associated With the user is referred to as a
`“keychain.” Each keychain is assigned a public/private key
`pair, With all secrets in the keychain being encrypted With
`the public key. The user may be associated With one or more
`keychains, each of Which may be further associated With
`different secrets. Since these secrets correspond to applica
`tion programs, the association of programs to keychains may
`be based upon various characteristics, such as the user’s
`rights With respect to the programs. Furthermore, each
`application program may be accessible by the same or
`different users so that, e.g., those users having the same
`access rights for a program may utilize the same keychain
`containing each user’s secrets for the programs.
`
`20 Claims, 6 Drawing Sheets
`
`/
`
`|
`
`I‘ _______________ __‘I
`I AUTHENTICATION 1204
`I
`I
`DATABASE
`I
`I ____|_I_:__TT_:__ I
`I
`I
`‘I
`I
`I
`I
`DATABASE
`I
`l
`I
`I
`I
`I
`API
`IDIRECTORY sERvICEs k206 I
`I
`i
`i
`l
`I
`l
`I
`|
`I
`l
`|
`|
`l
`I
`I
`I
`I
`I
`I
`201 I
`E_,
`I
`207
`\I. I
`I
`I
`*5 I
`API 214 I p210
`I
`I
`
`------
`
`usER
`
`II
`I/o
`I
`I
`DEVICE :I
`L:
`
`202b
`r
`
`APPLICATION
`
`r—--.
`| DS R238
`l-—-'
`
`sERvER NODE
`
`F _ _ _§§?_2_ _ _ _ _
`
`(220
`
`l
`I CERTIFICATE
`I AUTHORITY
`(CA)
`|
`I
`I
`
`(21a
`
`_'
`|
`|
`KEY
`GENERATOR I
`(KG)
`|
`I
`_I
`
`.~——.
`| DS Lr~232
`l__ _I
`
`API r216 v~2020
`
`m
`
`APPLICATIONS
`
`WORKSTATION
`
`L24o
`
`APPLICATIONS sERvICEs
`\
`\
`sERvER NODE 228
`230
`
`VMware Exhibit 1006 Page 1
`
`

`

`US. Patent
`
`Oct. 6, 1998
`
`Sheet 1 0f 6
`
`5,818,936
`
`ooru\
`
`cvov
`
`nvow
`
`mvoF
`
`
`
`wDOZmm>mwm
`
`
`
`MDOZmm>mmm
`
`mow
`
`
`
`>102m§mmemOOmm
`
`
`
`mmOZmm>mmw
`
`cor
`
`
`
`mQOZEmma
`
`ENE.
`
`h.GE
`
`mmoj
`
`
`
`>mO§m=2mmemOOmm
`
`
`
`mDOZEmma
`
`
`
`N:mo_>m_oO:mmmD
`
`VMware Exhibit 1006 Page 2
`
`VMware Exhibit 1006 Page 2
`
`
`
`

`

`US. Patent
`
`Oct. 6, 1998
`
`Sheet 2 0f 6
`
`5,818,936
`
`I—
`
`_*____I
`
`I
`
`I I I I |
`
`>m¥
`
`moEmmZmo
`
`6v:
`
`20V
`
`>tmoIS<
`
`mEoEEmo_
`
`m_‘NONNL$91
`
`ZO_.r<0_.En_<
`mmOSmmw
`
`QNON
`
`8?;mo_
`7|I_
`
`.IIIL
`
`_
`
`____.____
`
`N.GE
`
`mm0_>mmw
`mZOF<Oan<
`
`N
`
`omNwN
`
`MQOZmm>mmm
`
`m20F<OZam<
`
`ZO_._.<._.mv_mO>>
`
`VMware Exhibit 1006 Page 3
`
`I
`
`OON
`
`oNQN
`
`NmNSm0”
`
`_II.
`
`o
`
`rN
`
`
`
`MDOZmm>mmm
`
`
`
`wm0_>mmw>mO._.Om_m=n:
`
`
`
`VMware Exhibit 1006 Page 3
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Oct. 6, 1998
`
`Sheet 3 of6
`
`5,818,936
`
`302
`
`USER
`OBJECT
`1
`
`304a
`
`KEYCHAIN I
`OBJECT1
`FOR
`USER1
`
`304b
`4__|
`KEYCHAIN
`OBJECT2
`FOR
`USEFH
`
`APPLICATION
`OBJECT1
`
`306a
`
`I
`.
`
`APPLICATION
`OBJECT
`
`30Gb
`
`APPLICATION
`OBJECT
`
`306C
`
`1
`.
`
`APPLICATION ,_
`OBJECT
`306d
`
`. m
`
`APPLICATION ?aoee
`OBJECT
`
`APPLICATION
`OBJECT
`
`304“
`
`KEYCHAIN
`OBJECT n
`FOR
`USER 1
`
`FIG. 3
`
`VMware Exhibit 1006 Page 4
`
`

`

`U.S. Patent
`
`0a. 6, 1998
`
`Sheet 4 0f 6
`
`5,818,936
`
`400
`
`RECEIVE APP.
`AUTHENTICATION
`REQUEST
`
`402
`
`406
`
`USER
`LOGGED-IN
`?
`
`NO
`
`SERVICE
`DENIED
`
`CALL RETRIEVE
`APP. SECRET API
`W/APP. ID
`
`410
`
`API SENDS
`REQUEST ACROSS
`NETWORK
`
`412
`
`RECEIVE RESPONSE
`FROM DATABASE
`API
`
`414
`
`FIG. 4A
`
`VMware Exhibit 1006 Page 5
`
`

`

`U.S. Patent
`
`Oct.6,1998
`
`Sheet 5 of6
`
`5,818,936
`
`420
`
`SERVICE
`DENIED
`
`DECRYPT
`THE DATA WITH
`PRIVATE KEY
`
`RETURN USER ID
`AND APP. SECRET
`TO APPLICATION
`
`FIG. 4B
`
`VMware Exhibit 1006 Page 6
`
`

`

`U.S. Patent
`
`Oct.6,1998
`
`Sheet 6 of6
`
`5,818,936
`
`500
`
`506
`
`RETURN
`FAILURE
`TO
`WORKSTATION
`
`510
`
`RETURN
`FAILURE
`TO
`WORKSTATION
`
`502
`
`RECEIVE THE
`RETRIEVED APP.
`SECRET FROM
`WORKSTATION
`API
`
`VERIFY
`APP. ID ON
`
`LOCATE
`USER'S KEYCHAIN
`OBJECT FOR
`SELECTED
`
`LOCATED
`
`RETRIEVE APP.
`SECRET, USER ID,
`& KEYCHAIN
`PRIVATE KEY
`
`512
`
`RETURN
`INFORMATION
`TO CLIENT
`
`514
`
`FIG. 5
`
`VMware Exhibit 1006 Page 7
`
`

`

`1
`SYSTEM AND METHOD FOR
`AUTOMICALLY AUTHENTICATING A USER
`IN A DISTRIBUTED NETWORK SYSTEM
`
`FIELD OF THE INVENTION
`The present invention relates generally to public key
`cryptography in distributed data processing systems and
`more speci?cally, to a means for transparently authenticat
`ing a user to multiple services and applications in a distrib
`uted system.
`
`BACKGROUND OF THE INVENTION
`
`In a distributed data processing netWork system, the
`methodology employed to reliably verify the identity of a
`communicating device across the netWork prior to alloWing
`the device to access system operations and resources is
`referred to as authentication. Access to the system may be,
`for example, for the purpose of communicating With other
`users, retrieving secure information, or receiving a service.
`Distributed systems generally include various computer
`nodes interconnected by a communications medium. The
`computer nodes may include nodes that are directly accessed
`by users, e.g., Workstations, and nodes running specialiZed
`applications, e.g., servers. These nodes, the processes run
`ning on these nodes, and the users of the distributed system
`are referred to as “principals.” The authentication eXchange
`is performed on behalf of the principals.
`Public key cryptography is a method of secure commu
`nication in Which each principal has a public encryption key
`and a private encryption key, and tWo principals can com
`municate knoWing only each other’s public keys. An encryp
`tion key is a code or number Which, When taken together
`With an encryption algorithm, de?nes a unique transforma
`tion used to encrypt or decrypt data. A public key system
`may be used in such a Way as to ensure con?dentiality of the
`information being transmitted, i.e., to ensure that the infor
`mation may not be understood by an eavesdropper, as Well
`as to ensure the authenticity of the sender of the information.
`The manner in Which a public key cryptography system
`operates to ensure authentication may be understood Without
`reference to the mathematical transformations that are used
`for encryption and decryption. Public key cryptography is
`also referred to as a “asymmetric” encryption because
`information encoded With a public key may be decoded only
`by using a complementary private key, the associated public
`and private keys de?ning a key pair. According to this type
`of encryption, the private key is knoWn only to the oWner of
`the key, While the public key is knoWn to other principals in
`the system.
`Accordingly, to effect a secure transmission of informa
`tion to a recipient, a principal encodes (“encrypts”) the
`information With the recipient’s public key. Since only the
`intended recipient has the complementary private key, only
`that principal can decode (“decrypt”) it. On the other hand,
`to prove to a recipient of information that the sender is Who
`he purports to be, the sender encodes (“signs”) the infor
`mation With its private key. If the recipient can decode
`(“verify”) the information, it knoWs that the sender has
`correctly identi?ed itself. In public key cryptography, each
`principal is responsible for knoWing its oWn private key and
`all the public keys are generally accessible from one
`location, typically a directory service.
`Operation of a public key cryptography system Will noW
`be described With reference to an illustrative log in authen
`tication eXchange betWeen a Work station, acting on behalf
`of a user, and a remote server. Basically, the Workstation
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,818,936
`
`2
`encrypts a message for con?dentiality by performing a
`transformation using the server’s public key, and a server
`decrypts the message by performing a transformation using
`its private key.
`Speci?cally, a user logs into the Workstation With the
`user’s passWord and the Workstation derives a secret, non
`complimentary, encryption key by applying a knoWn hash
`algorithm to the passWord. The Workstation then requests the
`user’s private key from a directory service (DS) of the
`remote server. The user’s private key has previously been
`encrypted under the same secret encryption key and stored
`as a “credential” of the directory. Acredential is a table entry
`comprising the user’s name and the user’s private key; in
`other Words the credential is a representation of the user in
`the computer. The remote server returns the encrypted
`private key to the Workstation, Which uses the secret key to
`encrypt and obtain the private key.
`Once the user is authenticated by the directory services on
`the netWork, and is then given access to the netWork, the user
`attempts to access either netWork-based services or appli
`cations. For eXample, the user may attempt to log into a
`different netWork or access a different operating system
`(e.g., accessing a DCE-based Unix server) or access appli
`cations such as Lotus Notes or Novell GroupWise.
`Generally, each of these entities includes a component
`referred to as an authentication agent that maintains the
`user’s identity (ID) and secrets (e.g., passWords). Although
`the user has been authenticated on the netWork, authentica
`tion agents generally are not aWare of the netWork
`authentication, and thus query the user for its passWord. This
`can consume considerable bandWidth and can be quite
`intrusive to the user, particularly in systems requiring users
`to be authenticated Whenever a resource is accessed.
`Some conventional systems attempt to reduce the number
`of authentications a user must perform. For example, the
`Macintosh operating system, available from Apple
`Computer, Inc., provides What is referred to as a “keychain.”
`Here, the operating system enables a user to manually enter
`all of its passWords on a single keychain that resides Within
`the operating system. Akeychain passWord is then used by
`the user to gain access and run all of the netWork services at
`the time the Workstation is booted.
`One draWback to this approach is that there is only one
`keychain per operating system (i.e., per Workstation),
`thereby limiting the availability of a user’s keychain to
`solely the single Workstation. In other Words, the localiZed
`nature of the keychain prevents the user from utiliZing other
`Workstations or systems throughout the distributed netWork
`system. Additionally, the use of a single keychain provides
`a single level of access control to all application programs in
`the system for a given Workstation; that is, different access
`rights cannot be associated With different programs for a
`user.
`Another draWback to the “Macintosh” Keychain approach
`is that it only stores user names and passWords for netWork
`based services, as opposed to application programs. That is,
`although single passWord access is provided to all services,
`a user must continue to authenticate itself to each program
`that is accessed.
`An alternate approach to reducing the number of authen
`tications performed by a user is provided by the WindoWs 95
`(Win95) operating system available from Microsoft Corpo
`ration. Win95 provides a method of alloWing users to enter
`only one passWord (at start-up time) When logging into the
`netWork. A draWback of this approach is that, like the
`Macintosh keychain technique, the service is only available
`
`VMware Exhibit 1006 Page 8
`
`

`

`3
`on each local Workstation as part of its operating system, and
`is not available on the network in a distributed form.
`More troubling, hoWever, is that the service does not
`alloW passwords of choice for application programs or
`netWork logins, thus requiring all services accessed by the
`Workstation to synchroniZe their passWords With the Win95
`passWord for that platform. Security concerns arise When a
`user assigns the same value to all of its passWords. Under
`such circumstances, the user’s rights to all applications,
`rather than to just a single system, are given aWay if the
`passWord is compromised. This may further compromise
`portions of the netWork system as Well as the con?dentiality
`of the user’s information.
`It can thus be seen from the foregoing that each of the
`conventional approaches to simplifying the authentication
`process have limited capabilities and ?exibility. What is
`needed, therefore, is a means for easily and ef?ciently
`authenticating a user to various application programs or
`systems in a distributed netWork Without compromising the
`security of the netWork or the con?dentiality of the users’
`information.
`
`10
`
`15
`
`SUMMARY OF THE INVENTION
`
`The present invention relates to a distributed authentica
`tion service that automates an authentication exchange
`betWeen a user and an application program of a distributed
`netWork system. The novel distributed authentication ser
`vice comprises an exchange controller coupled to an authen
`tication database containing a group of encrypted applica
`tion secrets associated With the user. Each application secret
`is, in turn, associated With a particular program resident in
`the system. According to the present invention, the control
`ler cooperates With the database to automate the exchange
`procedure by
`receiving an authentication inquiry gener
`ated by the particular program in response to the user’s
`request to access that program and (ii) providing that pro
`gram With the proper application secret retrieved from the
`database.
`The group of encrypted application secrets associated
`With the user is referred to as a “keychain.” Each keychain
`is assigned a public/private key pair, With all secrets in the
`keychain being encrypted With the public key. The user may
`be associated With one or more keychains, each of Which
`may be further associated With different secrets. Since these
`secrets correspond to application programs, the association
`of programs to keychains may be based upon various
`characteristics, such as the user’s rights With respect to the
`programs. Furthermore, each application program may be
`accessible by the same or different users so that, e.g., those
`users having the same access rights for a program may
`utiliZe the same keychain containing each user’s secrets for
`the programs.
`In the illustrative embodiment, the exchange controller
`comprises an application program interface (API) that is
`distributed among user Workstations (i.e., Workstation APIs)
`and the authentication database (i.e., the database API) ;
`preferably, both the database API and authentication data
`base reside in a netWork directory services (NDS) system.
`When the authentication inquiry is received from the pro
`gram at the controller, the Workstation API veri?es that the
`user is a valid netWork client (i.e., has successfully logged
`on and has been authenticated to the NDS) by requesting the
`proper application secret for that particular program. In
`response to this request, the database API accesses the
`authentication database and provides the Workstation With
`an encrypted application secret along With the private key
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,818,936
`
`4
`for decrypting that secret. The Workstation API then
`decrypts and forWards the proper secret (and user identity)
`to the particular application program.
`Advantageously, authentication of a valid netWork client
`is performed automatically by the distributed authentication
`service for all desired local or netWork-based applications in
`the user’s associated keychains. That is, authentication is
`performed transparently (Without any further user
`intervention) and Without degradation of netWork security.
`Thus, a valid netWork client does not have to authenticate
`itself each time it attempts to access an application program.
`Furthermore, the distributed nature of the authentication
`service provides the user With access to application pro
`grams from any connected Workstation in the distributed
`netWork. In other Words, the inventive service is available
`throughout the entire netWork rather than being localiZed on
`an individual Workstation. The authentication service is also
`available to all applications and services alike, and is not
`limited to netWork-based applications.
`The ?exible association of users, keychains and applica
`tion secrets enables each user to have its oWn unique user
`identity and application secret for every application on the
`netWork. Thus, knoWledge of one application secret does not
`compromise the security of all remaining application secrets
`associated With the user.
`Further features and advantages of the present invention
`as Well as the structure and operation of various embodi
`ments of the present invention are described in detail beloW
`With reference to the accompanying draWings. In the
`draWings, like reference numbers indicate identical or func
`tionally similar elements. Additionally, the left-most digit of
`a reference number identi?es the draWing in Which the
`reference number ?rst appears.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`For a fuller understanding of the nature of the invention,
`reference should be made to the folloWing detailed descrip
`tion taken in connection With the accompanying draWings,
`in Which:
`FIG. 1 is a diagram of a distributed data processing
`netWork system in Which the apparatus and protocol of the
`invention may be used;
`FIG. 2 is an exemplary embodiment of an authentication
`arrangement including a Workstation node, a key generator
`(KG) node, a certi?cate authority (CA), a certi?cate storage
`server (CSS) node and a revocation service (RS) node in
`accordance With the invention;
`FIG. 3 is a schematiZed block diagram of the secure
`authentication database residing on netWork directory ser
`vices;
`FIGS. 4A and 4B are a ?oWchart of the functions per
`formed by a Workstation applications program interface
`(API) of the present invention; and
`FIG. 5 is a ?oWchart of the functions performed by a
`database API of the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`Referring to FIG. 1, a distributed data processing netWork
`system 100 includes a plurality of computer nodes, such as
`user nodes 102a—n and various server nodes 104a—n, inter
`connected by a communications medium 106. The user
`node, e.g., a Workstation 102a, is a computer generally
`con?gured for use by one user at a time, Whereas each server
`104 is a computer resource running specialiZed softWare
`
`VMware Exhibit 1006 Page 9
`
`

`

`5,818,936
`
`5
`applications and services, typically for use by many users. In
`general, each of the computer nodes includes memory
`means 108 for storing softWare programs and data structures
`associated With the cryptographic methods and techniques
`described herein. In addition, the nodes further include
`processor means 110 for executing the softWare programs,
`including various algorithms for generating numbers and
`codes associated With, e.g., passWords, and for manipulating
`the stored data structures. It Will be apparent to those skilled
`in the art that other processor and memory means, such as
`encoding and decoding devices, may be used Within the
`teachings of the invention to implement cryptographic
`authentication methods and techniques described herein.
`To access resources of the netWork 100, a user typically
`“logs in” With a server node 104 con?gured as a directory
`service (DS) through the local Workstation 102a, and then
`remotely authenticates itself to the DS to acquire access to
`those resources. Speci?cally, the user provides an authoriZed
`user identity (e.g., a user name) and a user secret (e.g., a
`passWord) to an input/output device 112 of the Workstation
`102a and the Workstation authenticates the log-in attempt
`using a log-in authentication exchange With the DS. Once
`authenticated, the user receives its private key, Which the
`Workstation 102a uses in subsequent authentication
`exchanges With remote principals, such as server nodes 104.
`As noted, these subsequent authentication exchanges con
`sume considerable bandWidth and are burdensome to the
`user When accessing resources that require authentication.
`The present invention is directed to an arrangement for
`easily and ef?ciently authenticating a user to various appli
`cation programs or systems in a distributed netWork Without
`compromising the security of the netWork or the con?den
`tiality of the user’s information.
`An illustrative embodiment of an authentication arrange
`ment 200 of the present invention is shoWn in FIG. 2. The
`arrangement includes server nodes 202, a Workstation node
`210, a key generator (KG) server 218 and a certi?cation
`authority (CA) 220. In general, the Workstation node 210
`provides an interface to a user When accessing specialiZed
`applications executing on the server nodes 202. The KG 218
`is an example of a specialiZed server application used to
`register a user in the distributed system 200 by creating an
`account that includes the user’s identity and secret
`(passWord). The KG 218 also creates a private/public key
`pair for aspects of the present invention described beloW
`and, thus, must operate in a trustWorthy fashion. That is, the
`KG must choose private/public key pairs at random and
`must either generate or accept from the users the keys or the
`passWords used to encrypt or decrypt data. Further, in most
`implementations, the KG must reliably communicate the
`generated public key to certi?cation authority 220, so that
`the CA (e.g., another specialiZed server application) may
`cryptographically bind the public key and the user name in
`a signed “certi?cate”. Then the certi?cate and the private
`key Will be returned to the directory service to be saved With
`user information.
`In accordance With the invention, the Workstation and
`server nodes may be con?gured as a distributed authentica
`tion service 201 that automates an authentication exchange
`betWeen a user interface 112 200. The novel distributed
`service 201 comprises an exchange controller 207 coupled
`to an authentication database 204 containing a group of
`encrypted application secrets associated With the user. The
`controller 207, in turn, comprises an application program
`interface (API) that is distributed among user Workstations
`(i.e., Workstation API 214) and the authentication database
`(i.e., the database API 206). Illustratively, both the database
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`API and authentication database reside in a netWork direc
`tory services (NDS) system.
`The authentication database 204 is preferably a novel
`secure database containing groups of application secrets for
`predetermined application programs. Each group of appli
`cation secrets, referred to as a “keychain”, is assigned a
`public/private key pair by the KG 218 When the keychain is
`created. The database 204 also contains user objects Which
`associate a given user With one or more keychains. The
`database API 206 manages the authentication database 204
`in response to queries generated by Workstation API 214.
`FIG. 3 is a schematiZed block diagram of the authentica
`tion database 204 of the present invention. The database 204
`contains three types of associated data elements con?gured
`as objects: a user object 302, one or more keychain objects
`304a—n associated With user object 302, and application
`objects 306a—n, one or more of Which is associated With
`each keychain object 304. Each object contains a number of
`attributes in accordance With the present invention as
`described beloW.
`For every valid netWork user, the attributes of user object
`302 include a login public/private key pair and a secret (e. g.,
`the hash of the passWord). The user object 302 is accessed
`by the NDS to initially authenticate the user When the user
`logs on to the netWork. An application object 306 includes,
`for an associated application program, a program name, a
`list of users that have authority to access the program, and
`an application program identi?er (ID). The program name
`attribute is a unique descriptive term that identi?es the
`application program.
`The ID is a unique character string typically supplied by
`the application manufacturer that identi?es the application
`program. HoWever, the present invention reserves a pre
`assigned range of IDs for programs that have no IDs
`assigned to them by their manufacturer. In the preferred
`embodiment of the present invention, the ID is an ASN.1
`(abstract syntax notation; a CCITT/ISO standard) compliant
`identi?er de?ned as a “Free Form Identi?er.” HoWever, as
`those skilled in the art Would ?nd apparent, the ID may take
`on other forms appropriate for the applicable netWork envi
`ronment.
`Keychain objects, or simply “keychains”, are associated
`With one or more application objects based upon character
`istics of the application programs. As noted, a keychain has
`as attributes at least one application secret and a public/
`private key pair. The application secret contains data used by
`the particular program to authenticate the user. Application
`secrets may be grouped according to, e.g., the access control
`level (ACL) for each application program. For example, a
`group of applications on one keychain may require admin
`istrative rights for modi?cation, While another group of
`applications on a different keychain may alloW user modi
`?cations. In the illustrative embodiment, the application
`secret is the user’s passWord for that program; hoWever, it
`Will be understood by those skilled in the art that the secret
`may be any type of secure identi?cation mechanism. The
`key pair encrypts/decrypts the application secrets associated
`With a keychain object.
`As noted, in the illustrative embodiment, the exchange
`controller 207 comprises an API that is distributed among
`user Workstations (i.e., Workstation APIs 214) and the
`authentication database (i.e., the database API 206). A
`particular program, e.g., program 236, issues an authentica
`tion inquiry to user 112 in response to an attempt by that user
`to access the program’s processes or data. When the authen
`tication inquiry is received at the controller, the Workstation
`
`VMware Exhibit 1006 Page 10
`
`

`

`5,818,936
`
`7
`API 214 veri?es that the user is a valid network client (i.e.,
`has successively logged-on and has been authenticated to the
`NDS) by requesting the proper application secret for pro
`gram 236. In response to this latter request, the database API
`206 accesses the authentication database 204 and provides
`an encrypted application secret along With the private key
`for decrypting the secret. The Workstation API then decrypts
`and forWards the proper application secret (and user
`identity) to the particular application program.
`FIGS. 4A and 4B are a How chart of the function
`performed by Workstation API 214 in response to the
`authentication request generated by a particular program. As
`noted, When a user 201 attempts to access a particular
`application program, such as a local application 240 or
`netWork-based application program 236, the particular
`application program requires that the user be authenticated
`prior to accessing its processes or data. The function begins
`at block 400 and proceeds to block 402 Where Workstation
`API 214 receives this authentication inquiry from the appli
`cation program. Upon receipt, the Workstation API 214
`determines Whether the user is a valid netWork client at
`block 404. If the user is not a valid netWork client, Work
`station API 214 denies the user access to the distributed
`authentication service at block 406. HoWever, if the user is
`a valid netWork client, then the Workstation API 214 requests
`the proper application secret for the particular application
`program at block 410. For example, the Workstation API 214
`calls a “Retrieve Application Secret” API for retrieving the
`user’s identity and proper application secrets. Workstation
`API 214 provides the application identi?er of the particular
`application as part of the API call. The request to the
`database API 206 is preferably encoded in a netWork pro
`tocol element in a matter that is Well-knoWn in the art. The
`database API 206, in a matter described beloW With refer
`ence to FIG. 5, returns encrypted data and a keychain private
`key to the Workstation API 214. At block 414, the Worksta
`tion API 214 receives the encrypted data and keychain
`private key.
`At block 418, the Workstation API 214 determines
`Whether it successfully received the encrypted data and a
`public key from the database API 206. If not, access to the
`distributed authentication service 201 is denied at block 420.
`If the information is successfully received, the Workstation
`API 214 uses the keychain private key to decrypt the data on
`the Workstation 210 at block 422. After decrypting the data,
`Workstation API 214 returns the resulting user identity and
`application secret to the particular application program for it
`to perform its authentication in block 424. The function then
`ends at block 426.
`FIG. 5 is a ?oWchart of the function performed by the
`database API of the exchange controller in response to a
`Workstation API’s request for an application secret. The
`function begins at block 500 and proceeds to block 502
`Where the request is received at the database API 206. At
`block 504, the database API 206 attempts to locate the
`application object for the application ID received from the
`Workstation in its request. If the application object cannot be
`found, the database API 206 returns a service failure indi
`cation to the Workstation API 214 at block 506. If the
`application object is found, the database API 206 attempts to
`locate the user’s keychain that contains the application
`secret for the user at block 508. If there are no keychains or
`if no such application secret is located in the user’s
`keychain, a failure indication is returned to the Workstation
`API at block 510. OtherWise, at block 512, the encrypted
`application secret and the keychain private key are returned
`to the Workstation API 214.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`8
`Once the user keychain is located, the database API 206
`retrieves the encrypted application secret, encrypted user
`identity, and keychain private key from the authentication
`database 204 and, at block 514, the database API 206 returns
`this information to the Workstation API. The function then
`ends at block 516. As noted, at the time of installation the
`application secret is encrypted by using the keychain private
`key. Thus, the exchange controller 207 insures secure trans
`fer of the application secret and keychain private key from
`the database API 206 to the Workstation API 214.
`The present invention supports intra-node as Well as
`inter-node, server-to-server communications. For example,
`application 228 or service 230 on server 202c may attempt
`to access applications 236 or services 234 on server node
`202b. Under such circumstances, the above process is per
`formed by server API 216 rather than Workstation API 214