I|||||||||||l||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`UStlO5875296A
`
`United SHITZBS Patent
`
`[19]
`
`[11] Patent Number:
`
`5,875,296
`
`Shi et al.
`
`[45] Date of Patent:
`
`Feb. 23, 1999
`
`|)1s'rRmu'n:n 1:11.11 svsmm win; si-;i:v1«;R
`U515]; AUTH[.;N1‘]CA1'](_)N WITH C()()K1E5
`
`534,331 M1098 Sanders ............................. . 3951201153
`5_.T9(n.952
`$1998 Davis et ail.
`39:'n*20fJ.54
`
`Primary l’}xaniiner-—Roben W. Reausoliel, Jr.
`Assisiiirii Ex:mii‘m=r—I’ierre E. tjlisea
`Attorriey, Agent, or i"'i‘mi—Jel‘frey S. Lal-law; David H.
`J"d“"“
`[57]
`
`ABSTRACT
`,
`,
`,
`‘
`A method 01' authenticating :1 Web client to a Web server
`conneetable to a distributed file system of a dfstriluutecl
`C0ml?“11"_E. CNVIFONWCII1:
`1719 d_131|'|h'11¢d ¢0}"P“1|“3 ¢"‘_”‘
`ronment mcluties a security S0['V1I.'CfOl'-l‘Cllll‘t‘ll.t'lg a credential
`to a user authenticated to access the rlistributed file system.
`In response to receipt by the Web server 01 a user id and
`password from the Web client, a login protocol is executed
`with the security service. If the user can be authenticated, a
`credential is stored in a database of credentials associated
`with authenticated users. The Web server then returns to the
`wcl) chem a persistent client Slam Objccl having a unique
`identifier therein. This object, sometimes referred to as a
`cookie, is then used to enable the Web client in lumwss; Welt
`documents in the distributed lile system. In particular, when
`the Web client desires to make at sttbsequest request to the
`distributed tile system,
`the persistent client state object
`including the identilier is used in lieu oi‘ the user's id and
`password, vvhieh makes lltf: session much more secure. In
`this operation, the I.‘.()Dklt3 identifier is used as a pointer ll']lO
`‘he credential 510]-agc 1ab1¢_ and thc Q.-c(]cm[a|
`jg 1|-wn
`retrieved and used to facilitate multiple file acccssess from
`the distritiuted tile system. At the same time, the \\i’e11_c]ient
`l't'l¢'ly obtain access to Weir server (as, opposed tr-1 distributed
`tile system) drtetiments via eonvenitonal user id and pass-
`Word In an 11111’ M10051-
`
`20 Claims, 3 Drawing Sheets
`
`[541
`
`[75]
`
`Inventors: Sliaw—B-en Shi; Michael Bradford
`Anlt, both of Austin; Ernst Robert
`Plassninnn. Fflugerville; Bruce Arland
`Rich, Round Rock; Mickella Ann
`Rosiles, Austin; Tlieudure Jack
`Ltindtin Shruder, Cedar Park, all of
`"I-ex,
`
`[73] Assignee:
`
`International Business Machines
`Cm-pm-afium Armonk’ NY‘
`
`I
`
`21
`
`I
`[22
`-
`
`A L N _: 790 041
`pp
`0
`’
`Filed:
`Jan. 28, 1997
`,
`,
`Int: (‘F0 """""""""""""""""""""""""""""" G06,‘ “mu
`[5._i U.b. Ll.
`................................ 395;"188.0l.; 3’35S:fl‘)808(.|(i-l4;.
`-
`I‘! _.
`.3
`.
`l53l
`F1°1d of Search
`3953135: 187vU1-
`395/i188-U1: 2“0~59- 201133 200-54: 20041
`200-48w 200-493 38014: 34» 49
`
`1561
`
`Refemnces Cited
`U_S_ PATENT DOCUMENTS
`
`4.5?8_.53l
`3‘l8T=-‘HA1
`5.4‘«‘],?52
`5_.4¥t7,4fi3
`5.53(t.8c's2
`5__572’fi43
`:'i,fi44.'r’tt
`5,6?‘8,tt4l
`:‘s.‘i'ti.‘i,78(t
`
`........................ .. 380,521
`3,4986 Everliart et ul.
`2-”9(’3 has‘ 3‘ 31'
`'
`....................... ._ 3tttZt,i'3tJ
`2,e’l‘J0t'a Kaufman et al.
`3.-’l‘J9I‘; Stein at al.
`...... ..
`Znwzmfi
`I’Ji'l91.tt') Mcske. Jr. at al.
`H 39j'J,2m|‘:3"b
`
`3q5l.,2m‘48
`“H9.-,5 Judson
`1119.07 Miirphy
`39:'v't88.fIl
`.......
`|(L’t9¢J7 Baker et al.
`............ . 3KJSfl88.t.I1
`H1998 lrvergood et al. .
`
`1°
`N
`
`12
`
`\
`
`SERVER
`
`WEB SERVER
`
`DISTRIBUTED
`FILE SYSTEM
`
`DCE SECURITY SERVICE
`
`0001
`0001
`
`Apple/Twitter
`Apple/Twitter
`Ex. 1013
`EX. 1013
`IPR1 of U.S. Pat. No. 7,765,482
`IPR1 of U.S. Pat. No. 7,765,482
`
`

`
`U.S. Patent
`
`Feb. 23, 1999
`
`Sheet 1 0f 3
`
`5,875,296
`
`10
`\
`CLIENT
`
`BROWSER
`/
`16
`
`12
`'/
`
`WEB SERVER PLATFORM
`
`20~
`\ 0s
`
`GUI f24
`
`WEB SERVER
`K’ SOFTWARE
`14
`/
`22
`
`26/
`COMPUTER
`
`API
`
`DFS f50
`
`DCE /52
`SECURITY
`
`SESSION
`MANAGER \27
`
`\
`18
`
`F I G .
`
`1
`
`AUTH TRANS
`
`NAME TRANS
`
`PATH CHECK
`
`0002
`
`

`
`U.S. Patent
`
`Feb. 23, 1999
`
`Sheet 2 of3
`
`5,875,296
`
`\,
`
`12\_
`
`SERVER
`
`CLIENT
`
`BROWSER
`/
`16
`
`(9) _
`‘—(d)
`(c) _
`
`_/22
`
`WEB SERVER
`
`A
`
`(h)
`
`25/
`
`SAF PLUG-IN
`
`:| (b-C)
`
`DISTRIBUTED
`FILE SYSTEM
`
`go
`
`(W1
`
`(I)
`
`'
`27/ SESSION MANAGER CV29
`(‘)l
`ACCOUNT MANAGER
`/ DCE SECURITY SERVICE
`\
`52
`56
`
`FIG. 3
`
`(1)
`
`58
`
`0003
`
`

`
`U.S. Patent
`
`Feb. 23, 1999
`
`Sheet 3 0f 3
`
`5,875,296
`
`WAS REQUEST
`SENT BY BROWSER THAT
`SUPPORTS HTTP
`
`USE BASIC
`AUTHENTICATION
`
`/64
`
`58\
`
`70\
`
`SERVER SENDS BACK
`LOGlN HTML FORM AND COOKIE
`TI
`USER FILLS IN THE USER
`[D AND PASSWORD IN HTML FORM
`TI
`72\ CLIENT RETURNS FORM AND COOKIE
`T
`RUN “DCE_LOGIN"
`
`74\
`
`78\
`
`83/
`
`TI
`81
`DESTROY
`FIRST COOKIE /
`STORE DFS CREDENTIAL
`__T
`T
`USE NEW COOKIE
`82/ SERVER RETURNS NEw COOKIE
`To OBTAIN
`T
`CREDENTIAL
`DESTROY FIRST COOKIE
`T
`I
`wEcEégEEFil‘?zLuéEs
`sERvER RECEIVES NEw
`RETRIEVE
`84/ REQUEST wITH NEw COOKIE
`‘_ wEB DOCUMENT
`FIG. 4
`
`\86
`
`\88
`
`0004
`
`

`
`1
`DISTRIBUTED FILE SYSTEM WEB SERVER
`USER AUTHENTICATION WITH COOKIES
`
`TECHNICAL FIELD
`The present invention relates generally to Web transaction
`processing and more particularly to enabling access to Web
`documents stored in a secure distributed ?le system.
`
`BACKGROUND OF THE INVENTION
`The World Wide Web of the Internet is the most success
`ful distributed application in the history of computing. In the
`Web environment, client machines effect transactions to
`Web servers use the Hypertext Transfer Protocol (HTTP),
`Which is a knoWn application protocol providing users
`access to ?les (e.g., text, graphics, images, sound, video,
`etc.) using a standard page description language knoWn as
`Hypertext Markup Language (HTML). HTML provides
`basic document formatting and alloWs the developer to
`specify “links” to other servers and ?les. In the Internet
`paradigm, a netWork path to a server is identi?ed by a
`so-called Uniform Resource Locator (URL) having a special
`syntax for de?ning a netWork connection. Use of an HTML
`compatible broWser (e.g., Netscape Navigator) at a client
`machine involves speci?cation of a link via the URL. In
`response, the client makes a request to the server identi?ed
`in the link and receives in return a document formatted
`according to HTML.
`Many organiZations use multiple computers intercon
`nected into a distributed computing environment in Which
`users access distributed resources and process applications.
`A knoWn distributed computing environment, called DCE,
`has been implemented using softWare available from the
`Open Systems Foundation (OSF). As DCE environments
`become the enterprise solution of choice, many applications
`may be utiliZed to provide distributed services such as data
`sharing, printing services and database access. OSF DCE
`includes a distributed ?le system, called Distributed File
`Services (DFS), for use in these environments.
`DFS provides many advantages over a standalone ?le
`server, such as higher availability of data and resources, the
`ability to share information throughout a very large-scale
`system, and protection of information by the robust DCE
`security mechanism. In particular, DFS makes ?les highly
`available through replication, making it possible to access a
`copy of a ?le if one of the machines Where the ?le is located
`goes doWn. DFS also brings together all of the ?les stored
`in various ?le systems in a global namespace. Multiple
`servers can export their ?le system to this namespace. All
`DFS users, in the meantime, share this namespace, making
`all DFS ?les readily available from any DFS client machine.
`It Would be highly desirable to extend the functionality of
`existing standalone Web servers in the enterprise environ
`ment to take advantage of the scalability, ?le availability and
`security features of DFS (or other similar distributed ?le
`systems). As a by-product, users With an off-the-shelf
`broWser Would be able to easily access the Web information
`stored in the DFS namespace With no additional softWare on
`the client machine. Before this goal can be achieved,
`hoWever, it is necessary to integratethe security mechanism
`provided by the Web Server With conventional DFS security.
`One of the alternatives is to use the Basic Authentication
`scheme (provided by the Web server) to obtain the userid
`and passWord for each HTTP request. HoWever, using the
`knoWn basic authentication scheme in the context of DFS
`has several problesm.
`In particular, user ids and passWords are passed on every
`request. Thus, they are more likely to be attacked by
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,875,296
`
`2
`intruders even if passWords are protected by some encryp
`tion mechanism (for example, SSL). Secondly, it is difficult
`for the DFS and Web server security mechanisms to coexist.
`The broWsers Will memoriZe the userid and passWord sent to
`a speci?c server and the id and passWord Will be attached to
`every HTTP request sent to that server. If a mechanism is
`provided for having the Web server access the distributed
`?le system, the Web server Will maintain both the documents
`stored on the server local directory (protected by Web server
`security) and DFS (protected by DFS security). From the
`broWser’s perspective, the Web server is a single server and
`Will only remember one pair of userid and passWord for the
`Web server. If a user is broWsing both DFS documents and
`Web server documents, he or she Will be prompted for userid
`and passWord every time there is a sWitch from DFS
`document to Web server document, and vice versa. Finally,
`only limited error information can be returned to the user
`When DFS authentication fails.
`These problems make the knoWn basic authentication
`scheme ill-suited for integrating Web server and DFS secu
`rity mechanisms.
`The present invention solves this problem.
`
`BRIEF SUMMARY OF THE INVENTION
`
`It is thus a primary goal of the present invention to
`authenticate users accessing a distributed ?le system through
`an Internet World Wide Web server.
`It is a further object of the invention to provide a distrib
`uted ?le system authentication scheme for Web broWsing
`that only requires passing of a user id and passWord When
`the user initially logs in to the ?le system through a Web
`server. On subsequent requests, a secret handle stored in a
`“cookie” is passed from the Web broWser to the Web server.
`It is thus another object of the invention to use a persistent
`client state HTTP cookie authentication scheme to facilitate
`secure Web document access from a distributed ?le system.
`It is yet another object of the invention to implement a
`cookie-based authentication scheme for DFS Web server
`applications that coexists With the basic authentication secu
`rity scheme knoWn in the art such that When a user sWitches
`from a DFS document to a Web server document, he or she
`Will not be prompted for user id and passWord if alreadly
`logged into DFS.
`It is still another object of the invention to provide for
`customiZed error messages to be passed from the Web server
`to the broWser instead of the error messages provided by the
`knoWn basic authentication scheme.
`It is a more general object of the invention to integrate the
`security mechanism provided by the Web Server With con
`ventional DFS security. This Will enable the functionality of
`existing standalone Web servers to be enhance in the enter
`prise environment to take advantage of the scalability, ?le
`availability and security features of DFS (or other similar
`distributed ?le systems). As a by-product, users With an
`off-the-shelf broWser Will be able to easily access the Web
`information stored in the DFS namespace With no additional
`softWare on the client machine.
`These and other objects of the invention are provided in
`a method of authenticating a Web client to a Web server
`connectable to a distributed ?le system of a distributed
`computing environment. The distributed computing envi
`ronment includes a security service for returning a credential
`to a user authenticated to access the distributed ?le system.
`In response to receipt by the Web server of a user id and
`passWord from the Web client, a login protocol is executed
`
`0005
`
`

`
`5,875,296
`
`10
`
`15
`
`3
`With the security service. If the user can be authenticated, a
`credential is stored in an in-memory credential database of
`credentials associated With authenticated users. The Web
`server then returns to the Web client a persistent client state
`object having a unique identi?er therein. This object, some
`times referred to as a cookie, is then used to enable the Web
`client to broWse Web documents in the distributed ?le
`system. In particular, When the Web client desires to make
`a subsequest request to the distributed ?le system, the
`persistent client state object including the identi?er is used
`in lieu of the user’s id and passWord, Which makes the
`session much more secure. In this operation, the cookie
`identi?er is used as a pointer into the in-memory credential
`database, and the credential is then retrieved and used to
`facilitate multiple ?le accessess from the distributed ?le
`system.
`At the same time, the Web client may still obtain access
`to Web server (as opposed to distributed ?le system) docu
`ments via conventional user id and passWord in an HTTP
`request. Thus, the inventive authentication scheme may
`coexist With basic authentication noW in common use.
`According to a preferred method of the present invention,
`and responsive to an initial HTTP request, a determination
`is ?rst made regarding Whether the Web client has a broWser
`that supports persistent client state objects or “cookies”. If
`so, the Web server sends the Web client a login HTML form
`and a ?rst cookie including a URL identi?ed by the HTTP
`request. The user is then prompted to complete the HTML
`form With his or her user id and passWord. Thereafter, the
`Web client transmits the completed form along With the ?rst
`cookie (including the URL entry) back to the Web server. At
`the server, information from the completed form is extracted
`and supplied to a login protocol for the distributed ?le
`system. If the login is successful, a user credential is created
`and stored, preferably in an in-memory credentials database.
`If the login is not successful, an error message is returned to
`the Web client. Then, a unique identi?er is generated for the
`authenticated user and used as a pointer to the credentials
`database. This identi?er is then placed in a neW cookie that
`is sent to the Web client. The neW cookie is then used by the
`Web client for any subsequent ?le accesses to the distributed
`?le system. By using the neW cookie, the Web client need
`not transfer repeatedly the user’s id and passWord over the
`netWork. HoWever, the client can still use the user id and
`passWord to obtain simple ?le access from the Web server
`(as opposed to the distributed ?le system).
`The foregoing has outlined some of the more pertinent
`objects and features 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.
`
`4
`FIG. 3 is a process How diagram illustrating a Web
`transaction implemented according to the teachings of the
`present invention; and
`FIG. 4 is a detailed ?oWchart shoWing the process How of
`the invention.
`
`DETAILED DESCRIPTION
`
`A representative system in Which the present invention is
`implemented is illustrated in FIG. 1. A client machine 10 is
`connected to a Web server platform 12 via a communication
`channel 14. For illustrative purposes, channel 14 is the
`Internet, an Intranet or other knoWn connection. In the case
`of the Internet, Web server platform 12 is one of a plurality
`of servers Which are accessible by clients, one of Which is
`illustrated by machine 10. A client machine includes a
`broWser 16, Which is a knoWn softWare tool used to access
`the servers of the netWork. By Way of example only, a client
`machine is a personal computer. Representative broWsers
`include, among others, Netscape Navigator (all versions),
`Microsoft Internet Explorer (all versions) or the like, each of
`Which are “off-the-shelf” or doWnloadable softWare pro
`grams. The Web server platform (sometimes referred to as a
`“Web” site) supports ?les in the form of hypertext docu
`ments and objects. In the Internet paradigm, a netWork path
`to a server is identi?ed by a so-called Uniform Resource
`Locator (URL). The World Wide Web is the Internet’s
`multimedia information retrieval system. In particular, it is
`a collection of servers of the Internet that use the Hypertext
`Transfer Protocol (HTTP), Which provides users access to
`?les using Hypertext Markup Language (HTML).
`A representative Web Server platform 12 comprises an
`IBM RISC System/6000 computer 18 (a reduced instruction
`set of so-called RISC-based Workstation) running the AIX
`(Advanced Interactive Executive Version 4.1 and above)
`Operating System 20 and a Web server program 22, such as
`Netscape Enterprise Version 2.0, that supports interface
`extensions. The platform 12 also includes a graphical user
`interface (GUI) 24 for management and administration. The
`various models of the RISC-based computers are described
`in many publications of the IBM Corporation, for example,
`RISC System/6000, 7013 and 7016 POWERstation and
`POWERserver Hardware Technical Reference, Order No.
`SA23-2644-00. AIX OS is described in AIX Operating
`System Technical Reference, published by IBM Corporation,
`First Edition (November 1985), and other publications.
`While the above platform is useful, any other suitable
`hardWare/operating system/Web server combinations may be
`used.
`The Web Server accepts a client request and returns a
`response. The operation of the server 18 is governed by a
`number of server application functions (SAFs), each of
`Which is con?gured to execute in a certain step of a
`sequence. This sequence, illustrated in FIG. 2, begins With
`authoriZation translation (AuthTrans) 30, during Which the
`server translates any authoriZation information sent by the
`client into a user and a group. If necessary, the AuthTrans
`step may decode a message to get the actual client request.
`At step 32, called name translation (NameTrans), the URL
`associated With the request may be kept intact or it can be
`translated into a system-dependent ?le name, a redirection
`URL or a mirror site URL. At step 34, called path checks
`(PathCheck), the server performs various tests on the result
`ing path to ensure that the given client may retrieve the
`document. At step 36, sometimes referred to as object types
`(ObjectType), MIME (Multipurpose Internet Mail
`Extension) type information (e.g., text/html, image/gif, etc.)
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`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 representative system in Which the plug-in of
`the present invention is implemented;
`FIG. 2 is a ?oWchart of server side operations of a
`conventional Web transaction in response to receipt of a
`request from a broWser of a client machine;
`
`60
`
`65
`
`0006
`
`

`
`5,875,296
`
`5
`for the given document is identi?ed. At step 38, called
`Service (Service), the Web server routine selects an internal
`server function to send the result back to the client via a
`normal server-service routine. The particular function
`selected depends on the nature of the request. At step 40,
`called Add Log (AddIJog), information about the transaction
`is recorded. At step 42, called Error, the server responds to
`the client When it encounters an error. Further details of
`these operations may be found in the Netscape Web Server
`Programmer’s Guide, Chapter 5, Which is incorporated
`herein by reference.
`Thus, the Web server 18 includes a knoWn set of server
`application functions (SAFs). These functions take the cli
`ent’s request and other con?guration data of the server as
`input and return a response to the server as output. Referring
`back to FIG. 1, the Web server 18 also includes an Appli
`cation Programming Interface (API) 24 that provides exten
`sions to enable application developers to extend and/or
`customiZe the core functionality thereof (namely, the SAFS)
`through softWare programs commonly referred to as “plug
`ins.” The present invention makes use of the server API 20
`to provide for a plug-in that facilitates user authentication so
`that users of client machines may use broWsers to enable
`Web access to documents on a distributed ?le system 50.
`In particular, according to a general object of the present
`invention, it is desired to enable the user of the client
`machine 10 (intentionally or unknoWingly) to use the
`(preferably) off-the-shelf broWser 16 to access, broWse and
`retrieve documents located in the distributed ?le system 50.
`One such ?le system 50 is Distributed File Services (DFS),
`Which is a knoWn distributed ?le system implemented in a
`netWorked environment called the Distributed Computing
`Environment (DCE). DCE has been implemented using
`softWare available from the Open Systems Foundation
`(OSF). In a distributed computing environment, a group of
`machines is typically referred to as a “domain.” An OSF
`DCE domain is called a “cell.” A DCE cell may be a
`complex environment involving hundreds of machines in
`many locations.
`DCE DFS 50 provides data sharing services by making
`use of remote procedure calls (RPC’s) for naming, and a
`DCE Security Service 52 for authentication services. DFS
`50 interfaces to the DCE Security Service 52 via the session
`manager process 27, as described in more detail in copend
`ing application Serial No. xx/xxx,xxx, assigned to the
`assignee of this invention. In addition to its use of DCE
`Services, DFS itself is rich in features. It provides a uniform
`global ?lespace Which alloWs all DFS client users to see the
`same vieW of the ?lespace, and it caches ?lesystem data at
`the client for improved scalability and performance by
`reducing netWork traf?c to ?le servers. DFS also supports
`advisory ?le locking, and one of its features in the ability to
`export the operating system’s native ?lesystem. For
`example, in the case of the AIX Operating System, the native
`?lesystem is the Journaled File System (JFS). In addition,
`DFS also provides its oWn physical ?lesystem, the DCE
`Local File System (LFS). The DCE LFS provides supports
`for DCE Access Control Lists (ACL’s) on ?les and direc
`tories for securing access to data and advanced data man
`agement capabilities such as replication and load balancing.
`DFS 16 uses so-called DCE Kerberos-based authentica
`tion. A unix “credential” is associated With each ?le opera
`tion and holds the local authentication information for that
`operation. In particular, a credential is a data structure
`de?ning a particular machine (or a user on a multi-user
`machine). From the local operating system’s point-of-vieW,
`the credential includes a user id, a group id, optionally a list
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`of operating system privileges, and an authentication iden
`ti?er knoWn as a PAG (Process Authentication Group). The
`PAG acts as a tag for associating “tickets” betWeen DFS 50
`and the DCE Security Server 52. When DFS users authen
`ticate via the DCE Login facility, knoWn as dceilogin, the
`DCE Security Service interacts With DFS (across the
`netWork) through a setpago) interface to establish the PAG/
`ticket relationship in the process’s credential. On ?lesystem
`requests, DFS extracts the PAG from the credential structure
`to establish the DCE user’s authentication for RPC requests
`to the DFS ?leserver.
`
`The control How associated With the invention is illus
`trated in the process How diagram of FIG. 3. This ?gures
`illustrates the basic system of FIG. 1, With the inclusion of
`an account manager 56 having an associated database 58.
`Session manager 27 starts up upon initialiZation of the Web
`server and is preferably run by the Workstation computer 18.
`It includes its oWn storage area 29. When the client 10
`(through the broWser 16) requests a DFS document (step a),
`the Web server 18 invokes a server path check (using the
`SAF plug-in 25)(step b). The PathCheck checks With the
`session manager 27 to determine Whether the user has
`appropriate DCE credentials. If not (step c), the SAF plug-in
`25 Will return an error message (e.g., “401; Unauthorized”)
`to the broWser 16 (step d) and prompt the user for user id and
`passWord. After getting the userid and passWord from the
`user (step e), the SAF plug-in invokes the session manager
`27 (step f) to obtain the DCE credential for the user. Session
`manager 27 returns the DCE credential to the Web server
`(step g). The server then uses this user credential to represent
`the user to retrieve documents stored in DFS 50 (step h).
`After retrieving the documents, the account manager 56 is
`invoked (preferably using another API plug-in)(step i) to
`save appropriate usage information into the database 58
`(step 1")
`The session manager 27 is thus invoked by the Web
`Server When a user attempts to access a DFS ?le. If a user
`has already been authenticated by DCE, the Session Man
`ager 54 returns the user credential to the server, Which uses
`this credential to retrieve DFS documents on behalf of the
`user. If not, the Session Manager 54 Will login for the user
`and obtain the credential from DCE Security. The Session
`Manager maintains an in-memory database to keep track of
`Which user has logged in so that a user may access multiple
`DFS pages.
`
`Instead of using the basic authentication scheme, the
`present invention uses Persistent Client State HTTP cookies.
`Cookies are a knoWn Internet mechanism Which server-side
`connections (such as CGI scripts) can use to both store and
`retrieve information on the client side of the connection. A
`server, When returning an HTTP object to a client, may also
`send a piece of state information Which the client Will store.
`Typically, the state object, called a “cookie,” may include a
`description of the range of URLs for Which that state is valid.
`According to the Persistent Client State HTTP Cookies
`Preliminary Speci?cation, Which may be vieWed at
`netscape.com at the path "/neWref/std/cookieispecihtml,"
`a cookie is introduced to the client by including a Set-Cookie
`header as part of an HTTP response, usually through a CGI
`script. KnoWn cookie syntax is set forth beloW:
`Syntax of the Set-cookie HTTP Response Header
`This is the format a CGI script to add to the HTTP headers
`a neW piece of data Which is to be stored by the client for
`later retrieval.
`
`0007
`
`

`
`5,875,296
`
`8
`If secure is not speci?ed, a cookie is considered safe to be
`sent in the clear over unsecured channels.
`Syntax of the Cookie HTTP Request Header
`When requesting a URL from an HTTP server, the
`broWser Will match the URL against all cookies and if any
`of them match, a line containing the name/value pairs of all
`matching cookies Will be included in the HTTP request.
`Here is the format of that line:
`
`Set-Cookie: NAME-VALUE; expires=DATE;
`path=PATH; domain=DOMAINiNAME; secure
`NAME=VALUE
`
`This string is a sequence of characters excluding semi
`colon, comma and White space. If there is a need to place
`such data in the name or value, some encoding method such
`as URL style%XX encoding is recommended, though no
`encoding is de?ned or required.
`This is the only required attribute on the Set-Cookie
`header.
`
`expires=DATE
`
`The expires attribute speci?es a date string that de?nes the
`valid life time of that cookie. Once the expiration date has
`been reached, the cookie Will no longer be stored or given
`out.
`The date string is formatted as
`
`Wdy, DD-Mon-YYY HH:MM:SS GMT
`domain=DOMAINiNAME
`
`When searching the cookie list for a valid cookie, a
`comparison of the domain attributes of the cookie is made
`With the Internet domain name of the host from Which the
`URL Will be fetched. If there is a tail match, then the cookie
`Will go through path matching to see if it should be sent.
`“Tail matching” means that domain attribute is matched
`against the tail of the fully quali?ed domain name of the
`host. A domain attribute of “acme.com” Would match host
`names “anvil.acme.com” as Well as “shipping.crate.acme
`.com”.
`Only hosts Within the speci?ed domain can set a cookie
`for a domain and domains must have at least tWo (2) or three
`(3) periods in them to prevent domains of the form: “.com”,
`“.edu”, and “va.us”. Any domain that falls Within one of the
`seven special top level domains listed beloW only require
`tWo periods. Any other domain requires at least three. The
`seven special top level domains are: “COM”, “EDU”,
`“NET”, “ORG”, “GOV”, “MIL”, AND “INT”.
`The default value of domain is the host name of the server
`Which generated the cookie response.
`
`p ath=PATH
`
`The path attribute is used to specify the subset of URLs
`in a domain for Which the cookie is valid. If a cookie has
`already passed domain matching, then the pathname com
`ponent of the URL is compared With the path attribute, and
`if there is a match, the cookie is considered valid and is sent
`along With the URL request. The path “/foo” Would match
`“/foobar” and “/foo/bar.html”. The path “/” is the most
`general path.
`If the path is not speci?ed, it as assumed to be the same
`path as the document being described by the header Which
`contain the cookie.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`secure
`
`If a cookie is marked secure, it Will only be transmitted if
`the communications channel With the host is a secure one.
`Currently this means that secure cookies Will only be sent to
`HTTPS (HTTP over SSL) servers.
`
`65
`
`Cookie: NAME1=OPAQUELSTRING 1;
`NAME2=OPAQUEiSTRING2
`
`A ?oWchart shoWing the inventive authentication ?oW,
`Which makes use of the HTTP cookies, is shoWn in FIG. 4.
`The routine starts at step 60 for each HTTP request received
`by the server. At step 62, a test is made to determine Whether
`the request is sent by a broWser that supports HTTP cookies.
`For example, the Netscape broWser (e.g., Navigator (all
`versions)) and the Microsoft broWser (e.g., Microsoft Inter
`net Explorer (all versions) both support cookies, although
`other commercially-available broWser programs do not. If
`the outcome of the test at step 62 is negative, basic authen
`tication is then used to authenticate the user at step 64. If the
`outcome of the test at step 62 is positive (namely, that the
`broWser supports cookies), the method continues at step 66
`to test Whether there are any existing cookies contained in
`the request header. If the outcome of the test at step 66 is
`positive, then the user has already been authenticated and
`basic authentication can be used. If the outcome of the test
`at step 66 is negative, the broWser supports cookies but one
`does not yet exist.
`At step 68, the server sends back a login HTML form to
`prompt the user for a user id and passWord. The server also
`sends back a cookie Which includes as an entry the URL of
`the document requested by the user. In particular, as noted
`above, after the user if is authenticated by the DCE Security
`Server (via the session manager), the Web server needs to
`retrieve the document for the user. In this case, the Web
`server needs the original URL to retrieve the document.
`Since the Web server is stateless, the broWser must be
`provided With the original URL. This is achieved by pro
`viding the cookie. At step 70, the user ?lls in the user id and
`passWord in the HTML form. The form itself is generated
`using a CGI script in a knoWn manner. At step 72, the user
`id and passWord provided in the form are sent back to the
`server along With the cookie that the broWser received in
`step 68.
`Using the user id and passWord, the routine continues at
`step 74 to authenticate the user via the conventional dcei
`login mechanism. As is knoWn in the art, running dceilogin
`generates a “credential” for use by the user in obtaining
`access to DFS. If the authentication is not successful, as
`determined by a negative outcome at step 76, the server
`sends back a customized HTML document to the broWser at
`step 80 describing the particular failure. Then, at step 81, the
`cookie created in step 68 is destroyed. If the authentication
`is successful, as determined by the t