(12) United States Patent
`Fang et al.
`
`US006243816B1
`US 6,243,816 B1
`Jun. 5, 2001
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`(54) SINGLE SIGN-ON (SSO) MECHANISM
`PERSONAL KEY MANAGER
`
`-
`~
`(75) Inventors: Y1 Fang, Austm; I-Lung Kao, Round
`Rock; Ivan Matthew Milman; George
`Conerly Wilson, both of Austin, all of
`
`TX (Us)
`.
`(73) Assrgnee: International Business Machines
`Corporation, Armonk, NY (US)
`
`.
`
`_
`
`.
`
`5,768,504 * 6/1998 Kells et a1. ........................ .. 713/201
`5,864,665 * 1/1999
`~
`5,944,s24 * 8/1999
`6 O00 O33 * 12/1999
`6’006’333 * 12 1999 N. 1
`,
`,
`/
`1e sen .............................. ..
`FOREIGN PATENT DOCUMENTS
`
`.
`
`713 202
`/
`
`.
`
`0751453
`2281645
`
`5/1996 (EP) ............................... .. G06F/1/00
`3 1993 GB ............................ .. GO6F 12 14
`/
`(
`)
`/
`/
`OTHER PUBLICATIONS
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U S C 154(k)) by 0 days
`'
`'
`'
`'
`
`(21) Appl- NO? 09/ 070,512
`-
`_
`Apr‘ 30’ 1998
`(22) Flled'
`(51) Int. Cl.7 ...................................................... .. H04L 9/00
`
`‘121C829 “Si? g1 t0étrgamliilggffcurity’1 Jollfnali Data
`manon’ V . n
`’
`ep'
`.
`' “
`.
`IBM Technical Disclosure Bulletm, Network Signon Coor
`d1nat1on Con?guration,” vol. 36, No. 12, Dec. 1993 (pp.
`389—396).
`IBM Technical Disclosure Bulletin, “Lo on Assist for Mul
`g
`tiple Logons,” vol. 32, No. 8A, Jan. 1990 (pp. 303—305).
`IBM Technical Disclosure Bulletin, “Temporary Global
`Passwords,” VOL 36, N0~ 3, Mai 1993 (PP- 451—453)~
`
`(52) US. Cl. ........................ .. 713/202; 7137/€(9)/12;279137/(1)€7§/39;
`
`* Cited by examiner
`
`(58) Field of Search ................................... .. 713/201, 153,
`713/155, 183, 202; 709/229; 707/9
`
`(56)
`
`References Cited
`
`Primary Examin@r—R9b@rt Beausoleil
`Assistant Examiner—Scott T. Baderman
`74A
`yAg
`F' JffySLB D'd
`ttorne ,
`ent, 0r zrm— e re
`.
`a aW; av1
`Judson; Joseph R. BurWell
`
`U.S. PATENT DOCUMENTS
`
`(57)
`
`ABSTRACT
`
`4,604,686
`
`,
`
`,
`
`5 021 949
`5’047’923
`5:226j172
`
`8/1986 Reiter et a1. ----------------------- -- 395/500
`getard ett a11-
`~~
`6/1991 Morten et a1‘
`9/1991 Elstner et aL
`7/1993 Seymour et a1_
`
`e ers e a .
`
`.... ..
`
`364/200
`364/200
`395 /800
`
`Amethod of managing passwords of users desiring access to
`multiple target resources in a computer enterprise environ
`ment. For each given user, each of a set of 1d/passWord pairs
`is associated to each of a set of one or more respective
`targets. Each id/passWord pair is normally required to access
`
`-
`
`-
`
`-
`
`5,241,594
`
`8/1993 Kung . . . . . . . . . . . . . . . . .
`
`5,329,619
`5,347,632
`
`7/1994 Pegé et a1
`9/1994 FllePP et fil
`'
`1;;
`2111531216 et a '
`5:442:342
`8/1995 Kung _____
`___________ "
`5,442,771
`8/1995 F?epp et a1_ __
`5,564,043
`10/1996 Seifert . . . . . . . . . . .
`5,579,479 * 11/1996 Plum
`~~~~~~~~~~~~~ ~~
`girlzgewzlqéllr. et al. .
`I. 713/201
`5,655,077 * 8/1997 .longspet 211.‘... """"" "
`5,684,950 * 11/1997 Dare et al. ......................... .. 713/201
`
`. . . . . . .. 380/4
`-- 395/200-09
`" 39502009
`
`glib/92534
`__ 395/20008
`. . . . . . .. 695/614
`395/18801
`
`a respective target resource. The targets of each given user
`are stored in a globally-accessible database. In response to
`entry by a given user at a client machine of a single-sign on
`(SSO) id/passWord, the globally-accessible database is
`accessed from a personal‘ key manager (PKM) server to
`retrieve the targets of the given user. The targets are returned
`to the PKM server, Which then uses data therein to access the
`respective target resources on behalf of the given user at the
`client machine'
`
`31 Claims, 8 Drawing Sheets
`
`|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ . _ _ _ _ _ _ _ _ _ _ _ _ _
`
`I
`I
`I
`I
`I
`l
`,
`I
`:
`I
`I
`:
`
`I
`I
`
`Almiggtljiéno'i
`
`/21
`
`I
`CONFIGURATION
`INFORMAHON MODULE
`22/
`(LOCAL)
`l
`1-
`
`26
`
`(GLOBAL)
`
`\24
`
`COORDINATOR
`
`25
`
`l
`l
`l
`l
`l
`l
`'
`I
`:
`|
`l
`l
`
`I
`I
`
`_
`
`-
`
`Plaid Technologies Inc.
`Exhibit 1020
`
`Ex. 1020 Page 1
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 1 of 8
`
`US 6,243,816 B1
`
`WORKSTATION
`
`WORKSTATION
`FIG. 7
`
`WORKSTATION
`
`I
`I
`I
`l
`|
`I
`I
`I
`I
`I
`I
`I
`l
`I
`I
`I
`I
`I
`I
`L
`
`21
`AUTHENTICATION /
`MODULE
`
`CONFIGURATION '
`INFORMATION MODULE
`(LOCAL)
`22/
`
`I
`II
`
`LOGON
`COORDINATOR
`
`PERSONAL KEY
`MANAGER
`(GLOBAL)
`
`26\
`
`\24
`
`FIG. 2
`
`Ex. 1018 Page 2
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 2 of 8
`
`US 6,243,816 B1
`
`moEzEmooo
`
`8351
`“5%
`
`mogwmm
`
`ZQEQFEICE
`
`Ex. 1018 Page 3
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 3 of 8
`
`US 6,243,816 B1
`
`Global Sign-0n
`
`EEE
`
`User Name
`
`Password
`
`I Sign On
`
`Cancel
`
`Help
`
`I
`
`FIG. 4
`
`@IBM Global Sign-0n Launcher — ann
`£80 largets ?elp
`
`E
`
`Targets
`@Austin VM
`
`User ID
`ssoguiO
`ssoguiQ
`@NT Apps Sewer koleary
`
`Target State
`Logged 0n
`Logged 0n
`Logged Off
`
`Current Action Current Status
`Logon
`Complete
`Logon
`Complete
`Logon
`Pending
`
`EW
`IBM Global Sign—0n Target Launcher
`FIG. 5
`
`Ex. 1018 Page 4
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 4 of 8
`
`US 6,243,816 B1
`
`FIG. 6
`
`SSO LOGON
`TARGET 1
`
`LOGON COORDINATION
`I
`GET PROGRAM
`TYPE = APP1
`
`I
`GET TARGET 1
`TYPE = APPL1
`
`/26
`
`LOGON TO
`"TARGET 1
`
`24/ PKM 221$ TARGET 1 \33
`
`f44
`
`f4s
`
`USER REQuEsTs LOGON f40
`T
`LC ISSUES QUERY TO PKM /42
`T
`PKM RETURNS
`REQUESTED INFORMATION
`4
`LC ISSUES QUERY To CIM /46
`T
`CW RETURNS
`REQUESTED INFORMATION
`4
`SUBSTITUTION (BIND ENTRIES) \52
`T
`LOGON COORDINATOR
`INVOKES METHODS
`
`\54
`
`i>
`
`FIG. 7
`
`Ex. 1018 Page 5
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 5 of 8
`
`US 6,243,816 B1
`
`USER: ARTHUR
`
`PROGRAM
`
`1YPE:[ Lggo?iiRvERx
`
`L
`CAPABILITY = cu \ TARGEF
`INTERFACE= LOGON.exe
`‘U =KINGART “TYPE: LAN SERVER
`su
`USERID: KINGART
`<
`AND
`DOMAIN: CAMELOT
`‘ SD = CAMELOT
`/P:‘P
`“P = EXCALIBUR} PASSWORD: {EXCALIBUR}
`
`sso CLIENT
`
`sso SERVER
`
`[ SCHEMA 1
`LAN SERVER
`D : DOMAIN
`u = USERID
`
`FIG. 8
`
`USER REQUESTS CHANGE [6O
`PASSWORD ON TARGET 1
`
`GET TARGET 1 FROM PKM ,52
`TYPE = APP1
`4
`GET PROGRAM FROM CIM [54
`TYPE=APP1
`
`LOGON
`COORDINATION
`
`|
`|
`|
`|
`|
`|
`|
`|
`|
`:
`|
`|
`|
`|
`|
`|
`1
`
`T
`CHANGE USER PASSWORD
`ON TARGET 1
`\68
`
`FIG. 9
`
`Ex. 1018 Page 6
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 6 6f 8
`
`US 6,243,816 B1
`
`CLIENT
`MACHINES
`
`sso
`REQUEST
`
`sso
`sso
`PKM
`sso
`SERVER
`SERVER
`FRAMEWORK SERVER
`,_“ ____ -4. ____________ __*_,
`I
`v
`v | V PROTECTED
`L _____________ _ 5P2 _§ERMIQE_ _ J
`SERVER
`
`_
`
`_
`
`_
`
`( "
`
`;
`
`USERS
`
`\_\\a‘_ _ _ _ _|
`
`REGISTRY USER A J1. :::*§:::J_, r_____1
`v
`LI REGISTRY USER xl |PASSTICKET.
`-- ------ ---I |SECRET KEY I-1
`| @ |
`.
`L_|_.___.l :-1 l
`L__®__J .
`l @ |
`L_____._l
`
`sso USER A INFO
`\\
`\
`\
`\
`
`sso USER A
`
`TARGET 1 sso USER A \
`TARGET 2
`\
`-
`\
`sso USER A
`TARGET N
`
`1_00
`
`DCE SECURITY REGISTRY
`
`FIG. 10
`
`Ex. 1018 Page 7
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 7 of 8
`
`US 6,243,816 B1
`
`DEFINE “GROUP"
`
`f1“)
`
`GIVEN FIRST SS0
`SERVER IS CONFIGURED
`
`/112
`
`114
`
`FIRST SERVER
`HAVE THE MASTER KEY
`AND DOES GROUP HAVE
`ANY MEMBERS
`?
`
`YES
`
`N0
`FIRST SERVER
`GENERATES MASTER KEY
`T
`NOTIFY GROUP TO INCLUDE f118
`FIRST SERVER As A MEMBER
`
`fIIs
`
`ISSUE RPC TO SERVER [126
`IDENTIFIED IN THE GROUP
`T
`REIIIRN MASTER KEY
`I
`
`/128
`
`f130
`
`STORE LOCALLY
`
`I‘
`USE MASTER KEY
`I ————————————— ——
`To ENCRYPT PASSWORDS \I20
`|— I
`'
`UNCONFIGURE SERVER /132
`T
`DESTROY LOCAL COPY [134
`OF MASTER KEY
`T
`REMOVE ITsELF FRoM GROUP \136
`
`FIG. 11
`
`Ex. 1018 Page 8
`
`

`
`U.S. Patent
`
`Jun. 5, 2001
`
`Sheet 8 0f 8
`
`US 6,243,816 B1
`
`/142
`
`[145
`
`f14g
`
`MASTER KEY CHANGE REQUIRED /14°
`4
`STOP ALL sso sERvERs
`l
`DECRYPT ALL TARGET PASSWORDS /144
`m ERA WITH OLD MASTER KEY
`@
`GENERATE NEW MASTER
`KEY AT sERvER
`l
`REENCRYPT TARGET
`PASSWORDS AT SERVER
`1r
`REMovE ALL MEMBERS OF GROUP \150
`J
`PLACE ITSELF IN GROUP
`As A NEW MEMBER
`FIG. 7 2
`
`\152
`
`215 <
`CLIENTS
`
`SERVERS
`
`NAMING /214
`
`SECURITY
`
`216
`/
`
`REGISTRY
`/
`230
`
`ACL
`PS
`AS
`/
`/
`/
`232 234 236
`
`LOGIN
`\
`238
`
`TIME \220 AUDIT \224
`
`FIG. 73
`
`Ex. 1018 Page 9
`
`

`
`US 6,243,816 B1
`
`1
`SINGLE SIGN-ON (SSO) MECHANISM
`PERSONAL KEY MANAGER
`
`BACKGROUND OF THE INVENTION
`
`1. Technical Field
`The present invention relates generally to accessing het
`erogeneous networks and reducing costs by increasing pro
`ductivity for end-users and system administrators in an
`enterprise computer environment.
`2. Description of the Related Art
`With sprawling client-server systems growing daily,
`applications and information are spread across many PC
`networks, mainframes and minicomputers. In a distributed
`system environment connected by networks, a user must
`access many database systems, network systems, operating
`systems and mainframe applications. To use these systems
`and applications, the user must issue separate sign-on com
`mands for each speci?c system or application. Indeed, it is
`not unusual for a user to encounter ten or more different
`login sessions during a working shift, and these often are
`different interfaces with different user id and authentication
`information, usually passwords. This places the user under
`a signi?cant burden to remember and maintain this infor
`mation.
`It would be quite bene?cial to provide a single sign-on
`(SSO) tool to enable authoriZed users to perform one initial
`sign-on to access a variety of networks, systems and appli
`cations. A single sign-on system should provide secure
`storage of user passwords, support for more than one user
`password, as well as support for multiple target logon
`methods. Each of these issues present varying design con
`siderations.
`With respect to the ?rst issue, there are multiple
`approaches to storing and managing passwords. One
`approach is to use the same password for all accessible
`systems/applications. This technique may weaken system
`security, however, because a compromised password in any
`of the systems or applications compromises the user’s
`privileges on these systems and applications at the same
`time. Further, different sign-on mechanisms may have their
`own distinctive password requirements and, thus, it is prob
`lematic to use the same password for multiple targets.
`Another approach to storing and managing passwords is
`password-mapping, which refers to using the user’s primary
`password to encrypt all the user’s secondary passwords. The
`encrypted passwords are stored in a local storage space
`accessible to the user (e.g., a local ?le, a readable/writable
`smartcard, and the like). Once the primary password is
`veri?ed, the local system authentication module obtains the
`passwords for other sign-on systems and applications by
`decrypting the mechanism-speci?c encrypted password with
`the primary password. The security of this password
`mapping scheme assumes that the primary password is the
`user’s strongest password, and it also depends on the secu
`rity of the local storage for the secondary passwords. If
`secondary passwords are stored in an untrusted publicly
`accessible machine, an intruder is provided with opportuni
`ties for potential attacks. Although this approach is simple,
`the password ?le must be moved from machine to machine
`by the user to logon to more than one machine.
`The target logon alternatives also in?uence the single
`sign-on system design. In particular, the method used for
`storing a user password heavily in?uences the design of
`target logon code. It is known to embed passwords in target
`speci?c logon scripts. This is how many “homegrown”
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`2
`single sign-on systems work today. This technique is the
`least eXtendible design because it ties passwords (and logon
`target code) to each machine the user uses. It is also hard to
`maintain passwords in this design because passwords need
`to be changed both in the applications and in the logon
`scripts. For a mobile user, the scripts need to be present on
`all machines the user might use. The overall security of this
`approach is thus very weak.
`Another target logon alternative involves building in all
`the logon methods for every possible target to which any
`user may desire to logon. This “hardcoded” approach
`assumes that all workstations and applications are con?g
`ured similarly and do not change. Because the logon meth
`ods are built into the solution, changes made to the logan
`methods require changes to the actual solution itself. This
`approach is costly and also is not very extensible.
`These known approaches to secure password storage/
`management and target logon have yet to provide an
`adequate single sign-on solution. The present invention
`addresses and solves this problem.
`
`BRIEF SUMMARY OF THE INVENTION
`The present invention implements a single sign-on (SSO)
`mechanism that coordinates logons to local and remote
`resources in a computer enterprise with preferably one ID
`and password.
`More speci?cally, this invention provides a single sign-on
`(SSO) framework that allow users to sign on to a client
`system one time entering one password. The SSO frame
`work then signs on to other applications on the user’s behalf.
`The SSO framework supports storage of all passwords
`and keys belonging to a user in secure storage (e.g., either
`in local storage, a centraliZed password service, a smartcard,
`or the like), so that the user needs to remember only one ID
`and password. Upon authentication, the SSO mechanism
`securely retrieves all the passwords for a user from the
`secure storage and automatically (i.e. without additional user
`intervention) issues sign-ons to each system/application the
`user is authoriZed to access.
`The system framework preferably includes a number of
`modules including a con?guration information manager
`(CIM), which includes information on how to logon to the
`applications con?gured on a given machine, a personal key
`manager (PKM), which includes information about users,
`systems and passwords they use to logon to those systems,
`and a logon coordinator (LC), which retrieves the user’s
`passwords from PKM and uses them in conjunction with
`target-speci?c logon code to log users onto all their systems,
`preferably without any additional user intervention.
`The CIM facilitates adding new logon methods as needed.
`Information is preferably stored in the CIM using “tem
`plates” referred to as program template ?les (PTFs). A given
`PTF thus is used to create entries in the CIM. This template
`mechanism enables an application vendor to specify how to
`log on to a given application. Thus, independent software
`vendors and others can easily plug their applications into the
`SSO framework without writing a large amount of code.
`The SSO framework preferably implements a “data
`model” where information used to sign on to applications is
`kept in the separate PKM and CIM databases. Preferably, the
`PKM is globally accessible and stores user-speci?c
`information, and the CIM is locally accessible and stores
`application-speci?c information derived from PTF ?les. In
`operation, the logon coordinator (LC) accesses the PKM to
`obtain the user’s information (e.g., which target systems and
`applications to which the user can sign-on), as well as the
`
`Ex. 1018 Page 10
`
`

`
`US 6,243,816 B1
`
`3
`passwords and keys for those systems/applications. The LC
`then uses these passWords/keys, together With the target
`logon information found in the CIM, to sign-on to various
`target systems and applications. Sign-on is preferably based
`upon the target’s oWn protocols and mechanisms as de?ned
`in the PTF.
`Another objective of this invention is to alloW applica
`tions to be plugged into the single sign-on (SSO) frameWork.
`According to the invention, the program template ?le (PTF)
`is used to inform the single sign-on mechanism hoW to
`interact With a given application or subsystem to perform
`SSO-related operations. The PTF enables applications to be
`plugged into the SSO mechanism Without changing the SSO
`code itself and Without requiring any programs to be Written
`to plug into the neW application.
`Still another more general objective of this invention is to
`provide a frameWork-type SSO mechanism that enables any
`kind of target to be user-speci?ed.
`The foregoing has outlined some of the more pertinent
`objects of the present invention. These objects should be
`construed to be merely illustrative of some of the more
`prominent features and applications of the invention. Many
`other bene?cial results can be attained by applying the
`disclosed invention in a different manner or modifying the
`invention as Will be described. Accordingly, other objects
`and a fuller understanding of the invention may be had by
`referring to the folloWing Detailed Description of the pre
`ferred embodiment.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`For a more complete understanding of the present inven
`tion and the advantages thereof, reference should be made to
`the folloWing Detailed Description taken in connection With
`the accompanying draWings in Which:
`FIG. 1 is a computer enterprise environment in Which the
`present invention may be implemented;
`FIG. 2 is a block diagram of the main functional compo
`nents of the inventive single sign-on (SSO) mechanism;
`FIG. 3 is a representative single sign-on transaction
`according to the present invention;
`FIG. 4 is a representative logon interface screen for the
`SSO transaction of FIG. 3;
`FIG. 5 is a representative GUI screen identifying the
`systems/applications for a particular user;
`FIG. 6 is a high level illustration of the operation of the
`logon coordinator (LC) of the SSO mechanism;
`FIG. 7 is a ?oWchart illustrating the LC operation;
`FIG. 8 illustrates hoW the logon coordinator performs a
`matching operation betWeen PKM and CIM entries;
`FIG. 9 is a How chart of a change passWord operation;
`FIG. 10 is a block diagram of a representative multiple
`SSO server implementation and a DCE Security Registry for
`supporting the PKM data model;
`FIG. 11 is a ?oWchart of a method for distributing and
`synchroniZing a “master key” in the multiple SSO imple
`mentation of FIG. 10;
`FIG. 12 is a ?oWchart of a method for changing the master
`key; and
`FIG. 13 is a block diagram of a knoWn DCE domain
`implementation.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`FIG. 1 illustrates a portion of a distributed computer
`environment domain 10 in Which the present invention may
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`4
`be implemented. The signal sign-on (SSO) mechanism com
`prises both server 20 and client (runtime services) compo
`nents 14, 16 and 18. For purposes of illustration, each of
`these are illustrated as a computer. It is also assumed that
`system users log onto the domain via client machines in a
`knoWn manner.
`Preferably, the server and client services components of
`the SSO mechanism are implemented in a computer or
`“machine.” For example, each server may be a RISC
`System/6000® (a reduced instruction set or so-called RISC
`based Workstation) running the AIX ((Advanced Interactive
`Executive) operating system, preferably Version 4 or greater.
`Alternative servers include machines running Sun Solaris V
`2.5.1 or Microsoft WindoWs NT 4.0.
`Each client machine in the domain may be a computer
`such as a desktop machine or laptop. A typical client
`machine is an Intel X86 or Pentium®-based computer run
`ning WindoWs ’95 or greater operating system. Alternatives
`include machines running OS/2® Warp 3.x or higher, or a
`Microsoft WindoWs NT Workstation. Each client Worksta
`tion typically supports TCP/IP and may include a netWork
`operating system (NOS). A typical client is a Novell Net
`Ware client (for NetWare logons), an OS/2 LAN Server client
`(for OS/2 LAN Server logons), an OS/2 Warp Server client
`(for OS/2 Warp Server logons), or the like. These examples,
`hoWever, are merely representative and should not be con
`strued to limit the invention in any Way.
`Many different types of target systems/applications are
`accessed using the single sign-on mechanism. These include
`distributed applications, databases, printers, and other
`resources throughout the enterprise. Representative systems
`and applications include, Without limitation: 3270 and 5250
`based applications, IBM OS/2 Lan Server 4.x and OS/2
`Warp Server, Novell NetWare 3.x and 4.x, Microsoft NT 4.0
`Server, Databases (e.g., DB2, Oracle, Sybase, Informix, MS
`SQL Server), Lotus Notes 4.><, PeopleSoft applications,
`DCE applications Written to conform to The Open Group
`(formerly knoWn as the Open SoftWare Foundation), and
`other applications. These examples, again, are merely rep
`resentative.
`FIG. 2 illustrates the main components of the inventive
`single sign-on (SSO) mechanism of the present invention.
`They preferably include an authentication module 21, a
`con?guration information manager (CIM) 22, a personal key
`manager (PKM) 24, and a logon coordinator (LC) 26. In
`general, the authentication module 21 authenticates a given
`user to the remainder of the single sign-on (SSO) mecha
`nism. On systems With local operating system security, the
`authentication mechanism 21 usually is integrated With the
`local OS authentication. The authentication module prefer
`ably supports different authentication mechanisms (e.g.,
`secret key, smartcards, public/private key, and the like).
`The con?guration information manager (CIM) 22
`includes information on hoW to logon to the applications
`con?gured on a given machine. Preferably, a CIM is sup
`ported on each client machine from Which the SSO mecha
`nism is provided. A given CIM typically is not globally
`accessible from other machines on the domain. Information
`in the CIM preferably is formatted according to a program
`template ?le (PTF) 25, as Will be illustrated beloW in more
`detail. The CIM thus stores “con?guration directives” iden
`tifying the given logon process and the methods required to
`access a particular application on the target resource. NeW
`logon methods may be added using the PTF mechanism as
`Will be seen.
`The PKM 24 contains information about users, systems
`and passWords they use to logon to those systems.
`
`Ex. 1018 Page 11
`
`

`
`US 6,243,816 B1
`
`10
`
`25
`
`35
`
`5
`Preferably, PKM 24 is a secure, globally accessible reposi
`tory that facilitates the single sign-on process. Although not
`meant to be limiting, With respect to a given user, the PKM
`(as Will be described) preferably stores such information as
`a username, a set of one or more passWord(s), and any other
`application environment-speci?c information such as
`domain name, hostname, application name, and the like.
`Because this access information preferably is centraliZed in
`the PKM, users can access their target resources With one
`sign-on from any Workstation. They can also manage their
`passWords from this one repository, as Will also be seen.
`To this end, the logon coordinator 26 functions generally
`to retrieve the user’s passWords from the PKM and uses
`them in conjunction With the target speci?c logon code
`(identi?able from the CIM entries) to log users onto all (or
`some subset of) their systems, preferably Without any addi
`tional user intervention. As Will be described in more detail
`beloW, the LC also preferably maintains state information
`for a given user and application, called a “user target”, to
`help coordinate and execute future operations.
`According to the invention, the single sign-on mechanism
`preferably uses a “data model” Where information used to
`sign on to applications is kept in tWo separate databases. The
`?rst database is the PKM 24, Which is preferably a global
`database and is thus accessible from all client machines in a
`given domain. The PKM 24, as noted above, keeps user
`con?guration information. The second database is the CIM
`22, Which is preferably a local database and is thus acces
`sible only from the current client machine. The CIM need
`not be merely a local database, hoWever. Each client
`machine from Which the 550 support is provided runs a
`CIM. Thus, multiple instances of CIM 22 are illustrated in
`FIG. 2. Likewise, each client machine preferably also runs
`an instance of the logon coordinator 26.
`Thus, for example, the PKM 24 contains user-speci?c
`application data Which includes:
`Target name—uniquely identifying a user “target”
`Target type—speci?es What type of “application” this
`target is;
`Domain/Host/Application name—speci?es application
`information, speci?c for this target;
`User ID—speci?es user id on target;
`Key information—speci?es the user’s key (passWord) on
`the target;
`User preferences—speci?es user speci?c information for
`this target; and
`Preferred program name—speci?es a preferred PTF entry
`to use With this target.
`The personal key manager 24 enables a given 550 user to
`manage all the passWords the user possesses in a secure and
`effective manner. According to the invention, each
`application, server, or system to Which a user needs an
`ID/passWord pair to logon is de?ned as a “target”. Using a
`GUI interface, the user creates a target in PKM correspond
`ing to each real target to Which the user can logon, and the
`user may create as many (or as feW) targets as the capability
`of a speci?c PKM implementation alloWs (or that the user
`desires). Independent of any implementation, a generic
`PKM application programming interface (API) preferably is
`used by the S50 frameWork to create a neW target, to update
`a target’s data, to query a target’s information (With or
`Without passWords), and to delete an existing target.
`The second database, the CIM 22, preferably contains
`entries derived from the program template ?les (PTFs). This
`database contains application (i.e. program) speci?c
`information, Which includes (for example):
`
`45
`
`55
`
`65
`
`6
`Target type—speci?es What type of “application” the
`program is;
`Default target—indicates if an entry is the default of a
`given type;
`Speci?c application information—describes interfaces
`needed to perform operations like logon, logoff, and the like;
`Program Preferences—indicates timeouts and retry
`counts; and
`Interface directory—client-speci?c information on hoW to
`locate the application interface code.
`The expected runtime How of a user interacting With the
`single sign-on (SSO) mechanism is illustrated in FIG. 3 and
`described as folloWs. At step 1, a user either logs in to a local
`operating system (if required by the local operating system)
`or logs on via a logon interface (if local logon is not required
`by the operating system). A representative logon interface
`screen is illustrated, for example, in FIG. 4. The user’s local
`logon enables the authentication module (GSO Auth) on the
`local machine (if supported) to authenticate the user (step 2)
`to the authentication service that is integrated With the
`passWord storage service.
`A successful authentication triggers the single sign-on
`graphical user interface (GUI) to display (at step 3) the
`systems/applications the user is able to logon to and the
`status of the logon process. A representative GUI screen
`display is illustrated in FIG. 5. The GUI also calls the logon
`coordinator on the local machine (at step 4) to retrieve the
`user’s con?guration information and target con?guration
`information. As described, the logon coordinator gets the
`user’s information (Which target systems and applications
`the user can signon to) and the passWords and keys for those
`systems/applications from the personal key manager. If the
`personal key manager is implemented as a remote service
`(or if the necessary information is located remotely), the
`personal key manager client (at step 5) gets the information
`in a secure fashion (i.e. the passWords/keys are encrypted for
`transmission). The credentials returned from the authentica
`tion module are used by the personal key manager client to
`ensure that the user Who logged on to the mechanism is the
`user Who retrieves the passWords.
`The logon coordinator (step 6) then uses these passWords/
`keys and the target logon information found in the con?gu
`ration information manager (CIM) to sign-on to various
`target systems and applications, based upon the targets’ oWn
`protocols and mechanisms. The logon coordinator prefer
`ably provides status information about the state of the logons
`and also alloWs some targets to be launched asynchronously
`(after the initial sign-on processing has completed).
`This mechanism alloWs for different passWords for dif
`ferent target systems and applications Without requiring the
`user to remember all such passWords. The user remembers
`only one passWord to log into the mechanism, Which then
`performs the subsequent logging into the different system by
`acquiring the secret keys from the secured key manager
`(local or remote). This 550 mechanism enhances security as
`Well as ease of use. It also enables the user to access existing
`systems Without having to create or to modify existing user
`de?nitions on those systems. As Will be seen, the mechanism
`also alloWs a user to change his or her single sign-on
`passWord Without requiring changes of the target keys/
`passWords or vice versa. Target passWord changes can be
`made to one or more selected target systems.
`FIG. 6 is a high level illustration of the operation of the
`logon coordinator 26. FIG. 7 is a ?oWchart illustrating one
`preferred single sign-on method, Which may be suitably
`implemented in a computer program. The routine begins at
`
`Ex. 1018 Page 12
`
`

`
`US 6,243,816 B1
`
`7
`step 40 When a user 30 (at a Workstation 32) requests a logon
`to a given application (Target 1) 33. In response, the routine
`continues at step 42 With the logon coordinator 26 issuing a
`query to the PKM 24 for the information regarding the user’s
`“key” (Which, as described above, may include the
`username, passWord, and any other application
`environment-speci?c information as described above). At
`step 44, the information is returned to the logon coordinator.
`Then, the routine continues at step 46 With the LC issuing a
`query to the CIM to obtain the target information. At step 48,
`the target information is returned to the LC. The information
`retrieved from the CIM 22 for the particular application
`determines hoW to logon to the application (eg What type
`of invocation to make, What actual invocation, and the like).
`At step 52, the logon coordinator 26 substitutes given data
`received from the PKM into substitution variables in the
`invocation strings returned from the CIM. In particular, the
`logon coordinator performs a matching operation; for each
`PKM target entry, the coordinator determines Whether there
`is a corresponding CIM entry. If so, step 52 binds the tWo
`entries together. This is illustrated in FIG. 8. At step 54, the
`logon coordinator 26 invokes the logon method(s) de?ned
`by and stored in the CIM. This completes the processing.
`Generalizing, the logon coordinator (LC) thus takes the
`data from the personal key manager (PKM) and the direc
`tives in the PTF and interprets the data, together With current
`state information, to perform a given action. Such action is
`carried out With respect to the users’ systems and applica
`tions and includes, for example, a logon operation, a change
`passWord operation, or a logoff operation.
`If the user requests a change passWord operation, the LC
`makes the correct invocation to change the passWord and
`coordinates the passWord update in the PKM. Continuing
`With the above-described example (involving Target 1) a
`representative ?oWchart of this function is illustrated in FIG.
`9. By Way of brief background, the logon coordinator
`preferably maintains state information for a given user and
`application, a “user target”, to help coordinate and execute
`future operations. By looking at the current state of a user
`target and interpreting data in the PKM entry and the PTF,
`the LC can determine Which operations are required to
`satisfy an SSO request. For example, the PTF can specify
`that a user should be logged on to an application before
`performing a change passWord operation. Therefore, the LC
`Would keep track of the logon state of a user target to
`determine What operations are required to satisfy a change
`passWord request. If the user Were not logged on to the
`application, the LC Would perform a logon operation and
`then perform the change passWord operation.
`The ?oWchart of FIG. 9 is illustrative of the process. The
`routine begins at step 60 When the user desires to change a
`passWord for his/her Target 1. At step 62, the routine gets
`Target 1 information from the PKM; here, the target type is
`App1. The routine then gets the corresponding program of
`the given type from the CIM at