as) United States
`a2) Patent Application Publication (10) Pub. No.: US 2005/0138362 Al
`(43) Pub. Date: Jun. 23, 2005
`
`Kelly et al.
`
`US 20050138362A1
`
`(54) AUTHENTICATION SYSTEM FOR
`NETWORKED COMPUTER APPLICATIONS
`
`Related U.S. Application Data
`
`(75)
`
`Inventors: Edward R. Kelly, Rock Hill, SC (US);
`Christopher Wayne Howser, Concord,
`NC (US); Jonathan Francis Savage,
`Charlotte, NC (US); Yuliang Zheng,
`Charlotte, NC (US)
`
`Correspondence Address:
`KENNEDY COVINGTON LOBDELL &
`HICKMAN, LLP
`214 N. TRYON STREET
`HEARST TOWER,47TH FLOOR
`CHARLOTTE, NC 28202 (US)
`
`(73) Assignee: Wachovia Corporation, Charlotte, NC
`
`(21) Appl. No.:
`
`11/022,534
`
`(22)
`
`Filed:
`
`Dec. 22, 2004
`
`START
`
`(60) Provisional application No. 60/531,695, filed on Dec.
`23, 2003.
`
`Publication Classification
`
`Ente C07 caccccsscsssssssssnsssssesnstsnssnsssevee HO4L 9/32
`(SL)
`(52) US. Ch.
`cecesscssssssssstsessstsstnstvasnesnstnnevesve 713/156
`
`ABSTRACT
`(57)
`Asystem such as in a networked computer system compris-
`ing a user, an application server, a gatekeeper server and an
`authentication server. Communication within the system is
`managed by the gatekeeper server, wherein the user com-
`municates with the authentication server and the application
`server through the gatekeeper server. Once the user has been
`initially authenticated by the authentication server, the user
`may request application services from a plurality of appli-
`cation servers within the networked computer system with-
`out having to be re-authenticated.
`
`405 -
`
`415
`
`420
`
`
`
`LOGIN SERVER RECEIVES
`CREDENTIALS FROM WEB
`SERVER
`
`
`
`
`
`OGIN SERVERAUTH-
`ENTICATE USER UTILIZING
`PREDETERMINED
`
`METHOD?
`
`
`LOGIN SERVER PRODUCES
`INNER TOKEN
`
`LOGIN SERVER SIGNS INNER
`TOKEN
`
`| LOGIN SERVER ENCRYPTS
`INNER TOKEN .
`
`LOGIN SERVER SENDS
`ERROR MESSAGE TO WEB
`
`SERVER
`
`LOGIN SERVER SENDS
`SIGNED, ENCRYPTED INNER
`TOKEN AND TOKENID TO
`WEB SERVER
`
`428
`
`430
`
`435
`
`440
`
`APPLE 1010
`
`APPLE 1010
`
`1
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 1 of 12
`
`US 2005/0138362 Al
`
`28
`
`_32 Fig.1
`
`
`
`2
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 2 of 12
`
`US 2005/0138362 Al
`
`3
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 3 of 12
`
`US 2005/0138362 Al
`
`4
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 4 of 12
`
`US 2005/0138362 A1
`
`-SCb-
`
`“Ocr.
`
`-Sep
`
`Ory
`
`
`
`
`
`SA9NNGOddYSAANASNIDO1
`
`
`
`NAxOLYANNI
`
`QavLS)
`
`
`
`GSMWOddSTIVILNS0AY9
`
`4aANaS
`
`
`
`
`
`SAAIZOSYYAAMASNIDO1
`
`
`
`YANNISNOISYSAYASNIDOT
`
`
`
`
`
`NAxOL
`
`
`
`
`
`SLdAYONAYSANASNIDOT
`
`
`
`
`
`~NSMOLYANNI
`
`
`
`
`
`SGN3SYSAURSNIDOT
`
`
`
`
`
`YANNIGALdAYONS‘GANOIS
`
`
`|YSAYaS
`
` gamOlGINSNO.LONYNAXOL|
`
`
`
`
`
`“HLNWYAANASNIDSO
`
`
`
`ONIZIMLNYSSNALVOILNA
`
`QANINYSLAGSYd
`
`éCOHLAW
`
`N
`
`
`
`
`
`SONSYSANSNIDSO1
`
`
`
`G4MOLJDVSSAWYOUNS
`
`‘YAANaS
`
`-SOP
`
`SLY
`
`02r
`
`5
`
`
`
`
`
`
`
`
`

`

`US 2005/0138362 Al
`
`Fig.5
`
`[ENCRYPTED]
`
`-&
`
`Os>=L
`
`u
`
`TOKENID
`
`Patent Application Publication Jun. 23,2005 Sheet 5 of 12
`
`Lu
`ow
`
`—K
`
`k<=O
`
`o”
`
`6
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 6 of 12
`
`US 2005/0138362 A1
`
`(Lav)
`
`
`WOUCINSXO.LONVNAXOL
`
`
`
`‘UMANNISAAIZO3YYAAYAS‘ddV|S09
`
`
`
`
`
`
`
`-MAAYaS4am
`
`
`
`SILdANOAGYSANAS‘ddVO19
`
`
`
`
`
`
`
`NAXOLYANNI
`
`NIGINAHOLSVAWVS
`
`éYydQVSH
`
`
`NSAXOLYANNINICI
`|SLO
`
`NaAyOLSI7
`
`
`
`
`
`YyOudsSONASozoYAAYAS‘ddV
`
`
`
`
`
`YAAUSSG4MOLJOVSSSW
`
`v9‘bly
`
`7
`
`
`
`
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 7 of 12
`
`US 2005/0138362 A1
`
`Sv9
`
`SS9
`
`099
`
`
`
`
`
`‘NOISSASYASNLYVLS
`
`ALV3YDATIVWNOILEO.CNY)-ASNOdS3UY
`
`
`|(NAYOL‘dd
`‘ddVALVAYD
`
`
`
`
`
`SALVINDIW9OYAANAS‘ddV
`
`.ASNAYNLNAYOS
`
`
`
`QSLdAYONAJOANTIVWAHSVH
`
`
`
`SAYOLSGNVNSXOLYANNI
`
`
`
`
`
`‘ddVGNVASNOdS3yGNAS
`
`
`
`YSAYASSSMOLNAWOL
`
`GNA
`
`
`
`SYNLVNOISIWLISIG
`
`
`
`dIW3aAATINASSADSON
`
`éNaxXOl
`
`éYAgldoOSENnsVYgsnsl
`
`—~_SWH
`
`
`
`GAWILNOISSAS
`
`éLNO
`
`Sz9
`
`
`
`YAAUAS4AMOLSOVSSAW:
`
`
`
`YOuYsSGN3SYSANAS‘ddV|Or9
`
`
`
`
`
`GNAg9‘Bl4-
`
`8
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 8 of 12
`
`US 2005/0138362 A1
`
`SOL
`
`OLZ
`
`StL
`
`0Z2
`
`—
`
`Gel
`
`
`
`‘SAAIB03¥YYSAMSSFAM
`
`
`
`
`
`
`
`YSAAYASNOILVOMddV
`
`ASNOdSAN
`
`
`
`
`
`NAMOLYALNOALWAYS
`
`
`
`YALNO/MNSXOLYANNIdVYM
`
`
`
`
`
`
`
`GANIGWO9SALV3YDOLNAXYOL
`
`NAxOL
`
`G3NISINOD4OOVWALVINOWO
`
`OLHOVLLVGNVNSYOL
`
`
`
`NaxOLGANISWOO
`
`
`
`
`
`NSXOLGANISWOOLdAYONA
`
`QN&S
`
`2‘Bi4
`
`9
`
`
`
`
`
`
`

`

`US 2005/0138362 A1
`
`Patent Application Publication Jun. 23,2005 Sheet 9 of 12
`
`10
`
`10
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 10 of 12
`
`US 2005/0138362 Al
`
`11
`
`11
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 11 of 12
`
`US 2005/0138362 A1
`
`
`
`GAWILNOISSSS
`
`éLNO
`
`SVH
`
`OcOL
`
`
`
`‘NOISSHSYSSNLYVLS
`
`
`
`AISNOdS43u‘ddV3LVANO
`
`
`
`3iV3SYOATIVNOLLdOONY)
`
`
`
`(NAMOL‘'ddV¥
`
`OvOL
`
`
`
`‘ddONVSSNOdS3uCNS
`
`-
`YaAYsSGSMOLNAXOL
`
`
`
`
`
`
`
`
`
`_|NSXOLYANNISSAISO34YYAANRS‘ddV
`
`avis)
`
`YAAUaSGSMWONCINANOLGNV
`
`
`
`
`
`SSALVINDIVSYSANAS‘ddV
`
`
`
`Q3A1LdAYONAAOANTIVWAHSVH
`
`
`
`NAXOLYANNI
`
`
`_ONTHNGG3LVaYOANWAHSVHVSWVS
`SNIVAHSV
`
`-VOISINSATWILINT
`
`SLOL
`
`12
`
`
`
`YyOYYsSONASYAAYSS‘ddV
`
`
`
`
`
`
`
`.YaAYSS84MOLSOVSSAW.
`
`QNS
`
`OL‘Bl
`
`OLOL
`
`GOOL
`
`0zOl
`
`12
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Jun. 23,2005 Sheet 12 of 12
`
`US 2005/0138362 Al
`
`13
`
`

`

`US 2005/0138362 Al
`
`Jun. 23, 2005
`
`AUTHENTICATION SYSTEM FOR NETWORKED
`COMPUTER APPLICATIONS
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This application is entitled to the benefit of, and
`claims priority to provisional U.S. patent application Ser.
`No. 60/531,695, filed on Dec. 23, 2003, which is incorpo-
`rated herein by reference in its entirety.
`FIELD OF THE INVENTION
`
`[0002] The present invention relates to a system and a
`methodfor protecting applications within a networked com-
`puter system.
`
`BACKGROUND OF THE INVENTION
`
`[0003] Businesses and individuals are increasingly depen-
`dent on computers and computer-based electronic commu-
`nication. More and more businesses are moving toward
`“paperless” modes of operation, and the convenience of the
`Internet has resulted in individuals using electronic media
`for various activities, such as communicating via email,
`banking, paying bills, investing money and shopping,
`to
`namebut a few. While businesses and individuals desire the
`convenience of electronic transactions, these entities also
`want to maintain at least the same level of security that more
`traditional transactional methods provide. However, in some
`ways, more traditional
`transactions are inherently more
`secure than electronic transactions because computers may
`easily be used to intercept the information being communi-
`cated between two or more computers. Accordingly, tech-
`niques have been created to secure information being com-
`municated electronically.
`
`[0004] Many of these techniques make use of various
`aspects of cryptography. Cryptographyis the study of send-
`ing and/or receiving a message in a secret form so that only
`those authorized to receive the message are able to read it.
`Cryptography may be used for any form of communication,
`but for the purposes of this application, cryptography for
`electronic communication will be discussed. Examples of
`cryptographic techniques include symmetric encryption,
`asymmetric encryption and hashing. For electronic commu-
`nication, an encrypted message may be transformed into a
`secret form using an encryption key and then may be
`transformed back into its original or clear form with a
`decryption key.
`
`In addition to cryptographic functions for securing
`[0005]
`information, entities desiring to protect information that is
`stored electronically may also create defined communication
`relationships between components within a networked com-
`puter system and a user wishing to access services within the
`system. For example, a networked computer system may
`require that a user be authenticated before being able to
`receive services from an application within the networked
`computer system.
`
`It is desirable to provide a more efficient, flexible
`[0007]
`and secure authentication system and methodfor receiving
`services from an application server in a networked computer
`system.
`
`SUMMARYOF THE INVENTION
`
`invention relates to a system and
`[0008] The present
`method for authenticating a user within a networked com-
`puter system. The system comprises a user, an application
`server, a gatekeeper server and an authentication server,
`wherein communication within the system is managed by
`the gatekeeper server.
`
`[0009] According to the method of the present invention,
`the user presents credentials to the gatekeeperserver, and the
`gatekeeper server provides the presented user credentials to
`the authentication server. The authentication server authen-
`ticates the user. The authentication server creates an authen-
`
`tication token upon authentication of the user and transmits
`the authentication token to the application server. Transmis-
`sion of the authentication token to the application server
`from the authentication server may comprise transmitting
`the authentication token to the gatekeeper server and then
`the application server. The authentication server may
`encrypt the authentication token after it has been created.It
`is preferred that an encryption key used by the authentica-
`tion server to encrypt the authentication token is shared by
`the authentication server and application server, but not
`shared with the gatekeeper server. The authentication server
`may also digitally sign the authentication token after it has
`been created. It is preferred that the authentication server
`sign the authentication token with a key pair, whereinat least
`a portion of the key pair is shared with the authentication
`server and application server.
`
`{0010] Further areas of applicability of the present inven-
`tion will become apparent from the detailed description
`provided hereinafter.
`It should be understood that
`the
`detailed description and specific examples, while indicating
`the preferred embodimentof the invention, are intended for
`purposesofillustration only and are not intended to limit the
`scope of the invention.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`invention will become more fully
`[0011] The present
`understood from the detailed description and the accompa-
`nying drawings, wherein:
`
`(0012] FIG. 1 is a depiction of a conventional authenti-
`cation system for networked computer applications.
`
`[0013] FIG. 2 is a depiction of the networked computer
`system of the present invention.
`
`[0014] FIG. 3 is a depiction of the authentication process
`for a user beginning a login session and initially accessing
`an application server within the authentication zone of the
`networked computer system of FIG. 2.
`
`[0015] FIG. 4 is a flowchart depicting the process of a
`login server authenticating a user.
`
`Ina conventional networked computer system, user
`[0006]
`authentication may occur at each application server indi-
`vidually,
`i.e., each application server is responsible for
`authenticating a user when the user requests services from
`
`that application server. This conventional authentication [0017] FIG. 6A isafirst flowchart illustrating the verifi-
`process requires a user to be authenticated for each appli-
`cation process that an application server performs whenit
`cation server that it wishes to access within the networked
`receives an encrypted inner token and token ID from a web
`server for the first time.
`computer system.
`
`[0016] FIG.5 isa depiction of the structure and content of
`the inner token created in FIG.4.
`
`14
`
`14
`
`

`

`US 2005/0138362 Al
`
`Jun. 23, 2005
`
`illustrating the
`[0018] FIG. 6B is a second flowchart
`verification process that an application server performs
`whenit receives an encrypted inner token and token ID from
`a web serverfor the first time.
`
`[0019] FIG. 7 is a flowchartillustrating the processing of
`the inner token by the web server after receiving the inner
`token back from the application server.
`
`[0020] FIG. 8A is a depiction of the structure and content
`of the outer token created in FIG.7.
`
`[0021] FIG. 8B is a depiction of a combined token includ-
`ing the contents of the outer token and the inner token of
`FIGS. 5 and 8A.
`
`[0022] FIG. 9 is a depiction of the process of a subsequent
`visit by a user to a previously accessed application server.
`
`[0023] FIG. 10 is a flowchart illustrating the verification
`process that an application server performs upon the subse-
`quent receipt of an encrypted inner token and token ID from
`a web server.
`
`[0024] FIG. 11 is a depiction of the process by which a
`user accesses a second application serverafter being initially
`authenticated by the login server.
`
`DESCRIPTION OF EMBODIMENTS
`
`[0025] The following description of the embodiments of
`the present invention is merely exemplary in nature andis in
`no way intended to limit the invention, its application, or
`uses. The present invention has broad potential application
`and utility, which is contemplated to be adaptable to a wide
`range of entities for securing and limiting access to appli-
`cations and information within a networked computer sys-
`tem. For example, it is contemplated that the authentication
`system and method for networked computer applications
`would be beneficial for use by any bank that provides online
`banking, investment and/or mortgage services. Additionally,
`it is contemplated that the system and methodof the present
`invention would be equally beneficial for user authentication
`by any retail business that provides online retail services.
`Further, the system and method of the present invention
`would be beneficial to any entity maintaining secure appli-
`cations and information that are accessed by third-party
`computers or users. The following description is provided
`herein solely by way of example for purposes of providing
`an enabling disclosure of the invention, but does not limit
`the scope or substance of the invention.
`
`[0026] Anetworked computer system comprises an appli-
`cation server, a database system, a gatekeeper server, and a
`user such as a person, computer, or software application. In
`a networked computer system that
`includes application
`servers capable of accessing sensitive information, protec-
`tive relationships may be implemented to limit access to the
`sensitive information.
`
`[0027] Referring now to the accompanying drawings,
`FIG. 1 depicts an embodiment of a conventional networked
`computer system 10. The conventional system 10 may
`comprise one or more protected application servers 32, 36,
`a protected database system 28, a gatekeeper server 30 and
`a user 12. One of ordinary skill will understand that an
`application server 32, 36 may comprise a plurality of appli-
`cation functions (not shown). Similarly, a database system
`28 may comprise a plurality of databases (not shown). The
`
`gatekeeper server 30 communicatively connects the appli-
`cation servers 32, 36 and the user 12. In fact, the user 12 may
`not communicate with the application servers 32, 36 except
`through the gatekeeper server 30.
`
`In order to receive services from an application
`[0028]
`server 32 within the system 10, a user 12 may contact the
`gatekeeper server 30 and request services from the applica-
`tion server 32 by offering user credentials to the gatekeeper
`server 30 (step 101). The gatekeeper server 30 forwards the
`user credentials to the application server 32 (step 102),
`which comprises an authentication application 33. The
`authentication application 33 compares the given user cre-
`dentials with the user credentials stored in the database
`system 28 or the mainframe of the operating entity (not
`shown). If the user 12 is authenticated,the application server
`32 creates an authentication token, which comprises the user
`credentials. If the user 12 is not authenticated, communica-
`tion ends.
`
`[0029] The application server 32 encrypts the authentica-
`tion token with an encryption key shared amongall servers
`in the networked computer system. The application server
`32 then sends the encrypted authentication token and appli-
`cation response to the gatekeeper server 30 (step 103). The
`gatekeeper server 30 creates another token, namely an outer
`token, to be wrapped around the authentication token. The
`outer token comprises a time stamp that is used to ensure
`that the outer token has not becomestale. The outer token
`and authentication token together comprise a combined
`token, which is encrypted by the gatekeeper server 30 with
`the same encryption key used by the application server 32.
`The gatekeeper server 30 forwards the encrypted combined
`token and a responsebythe application server to the user 12
`(step 104).
`
`If the user 12 wishes to access the application
`[0030]
`server 32 again, the user 12 presents the encrypted combined
`token to the gatekeeper server 30 and requests access to the
`application server 32 again. The gatekeeper server 30
`decrypts the outer token to ensure that the communication
`has not timed out. Assuming the outer token has not timed-
`out, the gatekeeper server 30 presents the encrypted authen-
`tication token and the request by the user 12 to the appli-
`cation server 32 (step 102). The application server 32
`decrypts the inner token and, using the authentication appli-
`cation 33, compares the information contained in the inner
`token against the information stored in the database system.
`If the user 12 is authenticated again, the application server
`32 creates a new authentication token, encrypts the authen-
`tication token and sendsthe authentication token, along with
`the application server 32 response, to the gatekeeper server
`30 (step 103). The gatekeeper server 30 creates a new outer
`token with a new time stamp, combines the authentication
`token and outer token, encrypts the combined token with the
`shared encryption key and sends the encrypted combined
`token and the application server responseto the user 12 (step
`104). Subsequent requests by the user 12 for services may
`follow the procedure set forth above.
`
`Ifa user 12 wishes to access a second application
`[0031]
`server 36 within the networked computer system 10, the
`second application server 36 has to perform the same
`process that the first application server 32 performed to
`authenticate the user 12. This duplicative process is indi-
`cated by dotted flow lines
`indicating communication
`
`15
`
`15
`
`

`

`US 2005/0138362 Al
`
`Jun. 23, 2005
`
`between the gatekeeper server 30 and application server 36
`in FIG. 1. In a system. 10, a second application server 36
`does not receive the benefit of the user authentication
`
`previously performed by another application server 32
`within the system 10. Rather, each subsequent application
`server 36 has to repeat the same process for authenticating
`a user 12 that the first application server 32 has already
`performed.
`
`[0032] The system 10 is relatively easily compromised
`because it utilizes a single encryption key that is shared by
`each of the servers in the system 10. In this system 10, a user
`12 may be limited to utilizing a usemame and password for
`authentication because of the limited functionality of the
`authentication application 33, 35 in the application servers
`32, 36. Additionally, requiring each subsequent application
`server within the system 10 to authenticate a user 12 that has
`already been authenticated by a first application server is
`unnecessarily time consuming for the system 10 and for the
`user 12. Furthermore, because the inner token of this system
`10 has no time-out function, an inner token could theoreti-
`cally be valid for an indefinite period of time. The avail-
`ability of valid inner tokens for an indefinite period of time
`is a further disadvantage of this system 10.
`
`[0033] FIG. 2 depicts an exemplary networked computer
`system 110 in accordance with the present invention. The
`networked computer system 110 of FIG. 2 comprises appli-
`cation servers 32, 36, a database system 28, a gatekeeper
`server 30, an authentication server 16 and a user 12. In this
`embodiment, a login server is the authentication server 16
`and a webserveris the gatekeeper server 30. The web server
`30 acts as a communication hub for the networked computer
`system 110. Specifically, the user 12, the login server 16 and
`the application servers 32, 36 all communicate with the web
`server 30 and with one another through the web server 30.
`In addition to being the communication hub for the net-
`worked computer system 110, the web server 30 also pro-
`vides a protective gatekeeper function, i.e., the web server
`30 will not forward a user request to an application server
`32, 36 unless the user 12 making the request has been
`authenticated by the login server 16. In this manner, the
`application servers 32, 36 are protected from a user 12 that
`has not been authenticated. As a short-hand wayto designate
`the communication relationship between the user 12,
`the
`web server 30,
`the application servers 32, 36 and the
`database system 28, with which the application servers 32,
`36 communicate, the application servers 32, 36 and database
`system 28 are said to be in an authentication zone 20. Only
`a request made by an authenticated user 24 (best shown in
`FIGS. 9 & 11) will be forwarded by the web server 30 into
`the authentication zone 20. However, once a user 12 has
`been authenticated, he or she will be allowed to request
`application services from any application server 32, 36
`within the authentication zone 20 without having to be
`re-authenticated by the login server 16. One of ordinary skill
`will appreciate that a plurality of application servers may be
`located within the authentication zone and further that a
`plurality of application servers may be needed to provide
`application services for a single application. For purposes of
`this application, the reference numeral 12 will be utilized to
`designate a user that has not been authenticated by the login
`server, and the reference numeral 24 will be utilized to
`designate a user that has been authenticated by the login
`server 16.
`
`[0034] The web server 30 also provides a protective
`function for the login server 16 by prohibiting a user 12 from
`directly communicating with the login server 16. The login
`server 16 does not receive direct communication from the
`
`user 12, the application servers 32, 36 or the database system
`28. Since a user 12 must be authenticated in order for
`communication from the user 12 to be forwarded into the
`
`authentication zone 20, the login server 16 is not located in
`the authentication zone 20. In order to further secure the
`
`login server 16, an additional security measure 26 that
`prevents unauthorized communication, such as a firewall,
`may be disposed between the login server 16 and the other
`components of the system 110.
`
`[0035] FIG.3 depicts the authentication process for a user
`12 beginning a login session and initially accessing an
`application server 32 within the authentication zone 20 of
`the networked computer system 110 of FIG. 2. For exem-
`plary purposes,
`the user 12 in this example may be an
`individual trying to access his or her account information
`(application server 32) on a bank web site (web server 30).
`A user 12 will begin by presenting his or her credentials,
`whichin this example may be a user name and password,to
`the web server 30 (step 301). User credentials may also
`include a digitalcertificate, a portable hardware device such
`as a secure identification card or any combination of cre-
`dentials. The security protocol of the entity operating the
`networked computer system 110 will determine the nature of
`the credentials which will be accepted. Additionally, the
`system and methodof the present invention assumesa user’s
`initial registration with the entity operating the networked
`computer system 110, whereby the user 12 provides iden-
`tification information to the entity and the entity stores this
`identification information with the user’s credentials for
`later authentication. Registration methods of this type are
`conventional and thus further explanation is not provided
`herein. The web server 30 then presents the user’s creden-
`tials to the login server 16 (step 302).
`
`[0036] FIG. 4 is a flowchart depicting the login server 16
`authenticating a user 12. When the login server 16 receives
`user credentials from the web server 30 (step 405),the login
`server 16 compares the presented credentials with the cre-
`dentials stored for the registered user 12 (step 415). If the
`values match, the user 12 is authenticated. However, if the
`values do not match, then the login server 16 sends an error
`message back to the web server 30 (step 420). The web
`server 30 then may determine whether to end communica-
`tion or to allow the user 12 to reenter his or her credentials.
`Oneof ordinary skill will appreciate that comparing stored
`credentials to presented credentials is only one method of
`authenticating a user 12. Other methods mayinclude algo-
`rithmic verification through message exchange between the
`login server 16 and a user 12 presenting a digital certificate
`or a challenge response protocol implemented when a user
`12 utilizes a hardware token as his or her credentials.
`Regardless of the authentication method utilized, once the
`user 24 is authenticated, the login server 16 begins a login
`session by creating a token 50, in this example an inner
`token 50, that identifies the authenticated user 24 and the
`login session (step 425).
`
`invention to
`is an advantage of the present
`It
`[0037]
`separate the login function from the application function as
`it providesflexibility to the networked computer system 110.
`In a conventional system, a user 12 is limited to certain
`
`16
`
`16
`
`

`

`US 2005/0138362 Al
`
`Jun. 23, 2005
`
`credentials because of the limited functionality of the
`authentication application 33 within the application server
`32. Typically, a user 12 is required to have a user name and
`password for authentication. In the context of a user 12 that
`is a computer or software application, this requirementis a
`limitation. In contrast, the system of the present invention
`can authenticate any user 12 having a credential recognized
`by the web server 30 and login server 16.
`
`[0038] The login server 16 of the present invention creates
`an inner token 50 with a defined format, which is indepen-
`dent of the credential presented by a user 12 for authenti-
`cation. Application servers 32, 36 within the authentication
`zone 20 will accept the inner token 50 created by the login
`server 16 regardless of the credential type that a user 12
`utilized for authentication. The advantage of the login server
`16 authenticating a user 12 and creating an inner token 50
`that is recognizedby all application servers 32, 36 within the
`authentication zone 20 is that these application servers 32,
`36 are assured that the user 24 requesting services from them
`has been authenticated already. Application servers 32, 36
`rely on authentication of the login server 16, specifically the
`inner token 50 created by the login server 16, rather than
`having to re-authenticate a user 24 for each new application
`server 32, 36 within a single login session.
`
`[0039] FIG. 5 depicts the structure and content of the
`inner token 50 created in FIG.4. The inner token 50 is a data
`structure that comprises a plurality of data nodes that store
`information that may be used to identify the authenticated
`user 24 and the token 50 itself The inner token 50 comprises
`a token ID 51, which is a unique identifier for each inner
`token 50 created. One of ordinary skill
`in the art will
`understand that a networked computer system 110 may
`contain multiple login servers 16 and multiple users 12.
`Accordingly, the number of inner tokens 50 created may
`easily numberinto the millions. As such,the task of creating
`a unique token ID 51 for every inner token 50 in a networked
`computer system 110 is not inconsequential. In order to
`ensure uniqueness of the token ID 51, data values such as
`time of token creation or login server ID may be used in
`creating the token ID 51. The inner token 50 also comprises
`a token time 52, which represents the time when the login
`session begins and the inner token 50 is created or issued.
`The token time 52 is the official time for the inner token 50
`
`and may be used to determine whether an inner token 50 has
`timed-out. The purpose and use of a time-out function will
`be explained in greater detail below.
`
`[0040] The inner token 50 also comprises a user ID 53,
`which is a unique identifier for each authenticated user 24.
`The user ID 53 may be a user name or someotheridentifier
`inserted into the inner token 50 by the login server 16.
`However, the user ID 53 is not necessarily the user name or
`user value entered by a user 12 whenrequesting application
`services. The inner token 50 may also comprise an emulator
`data space 54. The emulator space 54 may notbefilled with
`data every time an inner token 50 is created. Rather, the
`emulator data space 54 is used in the instance when an
`authenticated user 24 requests that a third-party access an
`application server 32 in the authentication zone 20 on behalf
`of the authenticated user 24. In the present example, the
`emulator data space 54 may be used when a bank customer
`having difficulty accessing his or her account balance
`requests that a bank service representative access his or her
`account
`information to determine where the problem is
`
`occurring. In this example, the service representative’s iden-
`tification information will be entered into the emulator space
`54 of the inner token 50. If emulation is not occurring, the
`emulation space 54 may beset to void.
`
`[0041] As is depicted in FIG. 4, once the inner token 50
`has beencreated, the login server 16 digitally signs the inner
`token 50 (step 430). The token 50 may be digitally signed
`using an algorithm known as asymmetric encryption. Asym-
`metric encryption involves using a cryptographic keypair to
`secure information,
`in this instance, an inner token 50.
`Asymmetric key pairs may be used to encrypt a message or
`to verify the integrity of a message. A key pair used to
`encrypt a message is comprised of a private key or decryp-
`tion key, which is known only to a single user or a small
`group of users, and a public key or encryption key, which
`may be knownby anyone. In order to encrypt and decrypt
`a message, both the private key and public key of the key
`pair must be used. For example, a message may be encrypted
`by a sender using the public key of the intended recipient of
`the message. Once the recipient receives the encrypted
`message, his or her private key may be used to decrypt the
`message. Additionally, as used herein for digital signature,
`key pairs may be used to verify the integrity of a message.
`For this function, the key pair comprises a private key or
`digital signature key and a public key or signature verifica-
`tion key. The private key may be utilized to sign a message
`or, in this instance, a token 50. The public key then may be
`utilized to verify the integrity of the token 50.
`In this
`embodiment, the private signature key is stored in the login
`server 16, and an application server 32, 36 mayuse the login
`server’s public verification key to verify the integrity of the
`signed inner token 50 by checking the signature 55. Any
`asymmetric encryption function and asymmetric digital sig-
`nature function may be utilized. Asymmetric encryption
`functions include, but are not limited to, RSA, ElGamal and
`variants thereof, and Elliptic Curve ElGamal and variants
`thereof. Asymmetric digital signature functions include, but
`are not limited to, RSA, DSA or DSS (US Digital Signature
`Algorithm/Standard) and ECDSA(Elliptic Curve DSA).
`
`[0042] After the inner token 50 has been digitally signed,
`the login server 16 encrypts the inner token 50 (step 435).
`While the inner token 50 has no size limitation,
`it
`is
`preferable that the token 50 be as compact as possible. It is
`morepreferable that the inner token 50 be less than or equal
`to 2 kilobytes. One of ordinary skill in the art, however, will
`recognize that the degree of compaction depends upon the
`encryption method employed. In the present embodiment,
`the login server 16 encrypts the signed inner token 50 with
`a symmetric encryption key. Symmetric encryption involves
`using a single key that is shared amongall users commu-
`nicating with one another. A message is locked (encrypted)
`with a key and then the same keyis used to unlock (decrypt)
`the message. In order to protect a message when using
`symmetric encryption, it is vital to have a secure method to
`exchangethe secret key to all users. Any symmetric encryp-
`tion function may be used. Symmetric encryption functions
`include, but are not limited to, AES, DES, 3DES, IDEA,
`RC5, RC6.
`
`Inthe present embodiment, the symmetric key used
`[0043]
`to encrypt the signed inner token 50 is shared by the login
`servers 16 in the networked computer system 110 and
`application servers 32, 36 within the authentication zone 20.
`The symmetric key is not shared with the web server 30.
`
`17
`
`17
`
`

`

`US 2005/0138362 Al
`
`Jun. 23, 2005
`
`This aspect of the system of the present invention is an
`advantage over conventional systems 10 because the web
`server 30 is unable