||||||||||||l||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`U5005875296A
`
`UnIted States Patent
`[19]
`[11] Patent Number:
`5,875,296
`
`Shi et al.
`[45] Date of Patent:
`Feb. 23, 1999
`
`[54} DISTRIBUTED FILE SYSTEM WEB SERVER
`USER AUTHEN'I‘ICATION WITH COOKIES
`
`5.134331
`5.106.952
`
`31-1093 Sanders
`8t1998 Davis et ail.
`
`3951201153
`395,200.54
`
`[75]
`
`Inventors: Shaw-Ben Shi; Michael Bradford
`Ault, both of Austin; Ernst Robert
`Plassntnnn. l’flugerville; Bruce Ariand
`Rich, Round Rock; Miekella Ann
`Rosiles. Austin; Theodore Jack
`London Shruder, Cedar Park, :11] of
`"I'ex.
`
`[73] Assignee:
`
`International Business Machines
`Corporation. Armonk, NY.
`
`I
`
`21
`
`I
`
`..
`”’7
`-
`I‘ll
`[5.1
`
`I58l
`
`[56]
`
`.l
`
`,
`28 1997
`
`A LN .:790041
`pp
`0
`9
`'Ie :
`an.
`I"I d
`, o
`Int: ('l'
`1.1.5. Ll.
`.
`395t186, 18701.
`Flcld or Search
`395M880], 20051 20033 200-54: 20041
`200-481 200-49; 38034, 34, 49
`
`,
`"""""""""""""""""""""""""""""" G06? 111")"
`................................ 3953,1881”; 3951I88-Il-l;
`393200.34
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`.......................... 3803521
`
`EVCTIIZIII El HI.
`3,31986
`45185.1”
`21993 F3351 3‘ a" '
`5181??“
`3'401‘?’2 MW" haufman Ct at. """"""""""""" 330,311
`5,497,463
`3ft‘t91‘) Stein et at.
`........
`2::11.t2(1o.33
`
`5.530.862
`631990 Meske. Jr. ct al.
`.. 395.1’20035
`5 572 (:43 “”995 Judson
`”jam,“
`
`5',s44.?11 men-1 Murphy
`3951133111
`,,,,,,,,,
`5,678,041
`”3:199? Baker Ct al.
`BOSHSSHI
`5.708.780
`”1998 Irvergood et at. .
`
`10
`
`N
`
`12\
`
`SERVER
`
`Primary Exmniner—Rohen W. Beausoliel, Jr.
`Assismnr EJmminer—Pierre Ii. Elise-a
`Attorney, Agent, or firm—Jeffrey S. Lat-law; David H.
`mm“
`[57]
`
`ABSTRACT
`,
`,
`,
`‘
`A method 01' authenticating a Web client to a Web server
`conneetable to a distributed file system of a distributed
`computing. environment: The (IISII'ihUlCd computing Cfl‘fi‘
`renment Includes a security some: for relurmng a eredential
`to a user authenticated to access the distributed file system.
`In res onse to recei
`t b
`the Web server 01' a user id and
`P
`P
`Y
`password from the Web client, a login protocol is executed
`\vIt
`t e securltv servtce.
`t e user can e not entIcate ,a
`‘h h
`‘_
`’
`11' h
`b
`It
`'
`d
`credential is stored in a database of credentials associated
`with authenticated users. The Web server then returns to the
`WEI) CIICI‘II a pCTSISTCTIl CIICI‘II state ObjECl having a lll'lquIC
`identifier therein. This object, sometimes referred to as a
`cookie, is then used to enable the Web client to browse Web
`documents in the distributed Iile system. In particular, when
`the Web client desires to make a subsequest request to the
`distributed Iile system,
`the persistent client state object
`including the idenlilier is used in lieu of the user‘s id and
`password, WhICI'I makes ll'lC SCSS‘BIOIT much more SCCUI’C. In
`this operation, the cookie identifier is used as a pointer into
`lhc credential sloragc labIc‘ and the credential
`is than
`retrieved and used to facilitate multiple file accesses-as from
`the distributed file system. At the same time, the Web client
`b:
`.
`..
`.
`t W h -
`.
`I"IT. H 'b td
`mayo 3111 access 0
`I:
`server (as Uppt Hut C(15) l'] u I:
`file system) documents via conventional user id and pass-
`word In an H ”1’ ”quest-
`
`20 Claims, 3 Drawing Sheets
`
`WEB SERVER
`
`DCE SECURITY SERVICE
`
`DISTRIBUTED
`FILE SYSTEM
`
`0001
`000‘
`
`Apple/Twitter
`Apple/Twitter
`Ex. 1013
`Ex. 101 3
`IPR2 of U.S. Pat. No. 8,612,515
`IPR2 of US. Pat. No. 8,612,515
`
`

`

`US. Patent
`
`Feb. 23, 1999
`
`Sheet 1 of 3
`
`5,875,296
`
`12
`'/
`
`WEB SERVER PLATFORM
`
`—
`BROWSER
`
`16
`
`
`
`WEB SERVER
`(7 SOFTWARE
`
`25/-
`
`COMPUTER
`
`14
`
`[5°
`52
`
`DCE
`SECURITY
`
`SESSION
`
`MANAGER
`
`27
`
`18
`
`FIG.
`
`1 0
`
`002
`0002
`
`

`

`US. Patent
`
`Feb. 23, 1999
`
`Sheet 2 of 3
`
`5,875,296
`
`\‘
`
`12
`
`\
`
`SERVER
`
`(a)
`
`DISTRIBUTED
`FILE SYSTEM
`
`DCE SECURITY SERVICE
`
`wow R
`
`15
`
`FIG. 3
`
`0003
`0003
`
`

`

`US. Patent
`
`Feb. 23, 1999
`
`Sheet 3 of 3
`
`5,875,296
`
`START
`
`62
`
`
`WAS REQUEST
`NO
`SENT BY BROWSER THAT
`
`
`SUPPORTS HTTP
`
`
`COOKIES?
`
`
`
`
`66
`
`USE BASIC
`AUTHENTICATION
`
`
`
`ANY EXISTING
`
`
`COOKIES [N REQUEST
`HEADER?
`
`Z O
`
`68
`
`70
`
`SERVER SENOS BACK
`LOGIN HTML FORM AND COOKIE
`
`USER FILLS IN THE USER
`[D AND PASSWORD IN HTML FORM
`
`72
`
`CLIENT RETURNS FORM AND COOKIE
`
`74
`
`RUN "DCLLOGW
`
`76
`
`@NO
`
`YES
`CREATE DCE UUID
`
`STORE OFS CREDENTIAL
`
`SERVER RETURNS NEW COOKIE
`
`DESTROY FIRST COOKIE
`
`SERVER RECEIVES NEW
`REQUEST WITH NEW COOKIE
`
`‘h-J “ml
`
`'h-nJCO
`
`CDIN.)
`
`CD (Jul
`
`84
`
`FIG. 4
`
`0004
`0004
`
`GENERATE CUSTOM
`R
`E ROR MESSAGE
`
`DESTROY
`FIRST COOKIE
`
`USE NEW COOKIE
`
`TO OBTAIN
`CREDENTIAL
`
`
`
`
`
`WEB SERVER USES
`CREDENTIAL TO
`RETRIEVE
`WEB DOCUMENT
`
`
`
`
`
`64
`
`8
`
`0
`
`81
`
`85
`
`88
`
`

`

`5,875,296
`
`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 file system.
`BACKGROUND 01" THE INVENTION
`'Ihe 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 files (cg, text, graphics, images, sound, video,
`etc.) using a standard page description language known as
`Hypertext Markup Language (HTML).
`l-I’I‘ML provides
`basic document
`formatting and alloWs the developer to
`specify “links" to other servers and files. In the Internet
`paradigm, a network path to a server is identified by a
`soAcalled Uniform Resource locator (URL) having a special
`syntax for defining a network connection. Use ofan HTML-
`compatible browser (cg, Netscape Navigator) at a client
`machine involves specification of a link via the URL. In
`response, the client makes a request to the server identified
`in the link and receives in return a document formatted
`according to HTML.
`Many organizations use multiple computcrs 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 (USE). 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 file system, called Distributed File
`Services (DFS), for use in these environments.
`DI-‘S provides many advantages over a standalone file
`server, such as higher availability ol'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 files highly
`available through replication, making it possible to access a
`copy of a file if one of the machines where the file is located
`goes down. DFS also brings together all of the files stored
`in various file systems in a global namespace. Multiple
`servers can export their file system to this naniespace. All
`DFS users, in the meantime, share this namespace, making
`all DFS files 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, file availability and
`security features of DES (or other similar distributed file
`systems). As a by-product, users with an ofi-the-shelf
`browser would be able to easily access the Web information
`stored in the DPS 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
`
`It]
`
`IS
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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 specific server and the id and password will be attached to
`every I-I'l'I‘P request sent to that server. If a mechanism is
`provided for having the Web server access the distributed
`file system, the Web server will maintain both the documents
`stored on the server local directory (protected by Web server
`security) and DFS (protected by UFS 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, be or she will be prompted for userid
`and password every time there is a switch from Dl-‘S
`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 THIS. INVENTION
`
`invention to
`is thus a primary goal of the present
`It
`authenticate users accessing a distributed file system through
`an Internet World Wide Web server.
`
`It is a further object of the invention to provide a distrib-
`uted file system authentication scheme for Web browsing
`that only requires passing of a user id and password when
`the user initially logs in to the file system through a Web
`server. On subsequent requests, a secret handle stored in a
`“cookie” is passed from the Web broWscr to the Web server.
`It is thus another object of the invention to use a persistent
`client state HTI‘P cookie authentication scheme to facilitate
`secure Web document access from a distributed file 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 UPS 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 oflhe invention to integrate the
`security mechanism provided by the Web Server with con-
`ventional DPS 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, tile
`availability and security features of DFS (or other similar
`distributed file systems). As a by-product, users with an
`off-the-shelf browser will be able to easily access the Web
`information stored in the DPS namespaoe with no additional
`software on the client machine.
`
`These and other objects of the invention are provider] in
`a method of authenticating a Web client to a Web server
`connectable to a distributed file 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 tile 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
`0005
`
`

`

`4
`FIG. 3 is a process flow diagram illustrating a Web
`transaction implemented according to the teachings of the
`present invention; and
`FIG. 4 is a detailed flowchart showing the process flow of
`the invention.
`
`DETAILED DESCRIPTION
`
`A representative system in which the present invention is
`implemented is illustrated in FIG. 1.Aclient 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 “olf-the-shelf‘ or downloadable software pro-
`grams. 'I‘he Web server platform (sometimes referred to as a
`“Web” site) supports files in the form of hypertext docu-
`ments and objects. In the Internet paradigm, a network path
`to a server is identified 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
`files using Hypertext Markup Language (HTML).
`A representative Web Server platform 12 comprises an
`IBM RISC SystemifiOOU computer 18 (a reduced instruction
`set of so-called RISC-based workstation} running the MK
`(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. 'Ihe 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 SystemifiOOO, T013 and 7016 POWERstatiort and
`POWERset-ver Hardware Technical Reference, Order No.
`SA23-2644-00. AIX OS is described in AIX Operating
`System it‘ecltnicni Reference, published by IBM Corporation,
`First Edition (November 1985), and other publications.
`While the above platform is useful, any other suitable
`hardwarei‘operating systemlweb 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 configured to execute in a certain step of a
`sequence. This sequence, illustrated in FIG. 2, begins with
`authorization translation (Auth'l'rans) 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 URI.
`associated with the request may be kept intact or it can be
`translated into a system-dependent file 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
`(DbjectType), MIME (Multipurpose Internet Mail
`Extension} type information (e.g., texti'html. imageigif, etc.)
`
`According to a preferred method of the present invention,
`and responsive to an initial HTTP request. a determination
`is first 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 first cookie including a URI. identified 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 first
`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 file
`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 identifier is generated for the
`authenticated user and used as a pointer to the credentials
`database. This identifier 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 file accesses to the distributed
`file 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 file access from the Web server
`(as opposed to the distributed file system).
`’Ihe 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 beneficial 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
`
`35
`
`40
`
`45
`
`50
`
`55
`
`5,875,296
`
`3
`with the security service. Ifthe 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 identifier 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 file
`system. In panicular, when the Web client desires to make
`a subsequest
`request
`to the distributed file system,
`the
`persistent client state object including the identifier is used
`in lieu of the user's id and password, which makes the
`session much more secure.
`In this operation,
`the cookie
`identifier is used as a pointer into the in-memory credential
`database, and the credential is then retrieved and used to
`facilitate multiple file accessess from the distributed file
`system.
`At the same time, the Web client may still obtain access
`to Web server (as opposed to distributed file 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.
`
`It]
`
`15
`
`an
`
`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 flowchart 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
`0006
`
`

`

`5,875,296
`
`5
`for the given document is identified. 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 (Addlog), 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 Sewer
`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 configuration data of the server as
`input and return a response to the server as output. Referring
`back to FIG. I, the Web server 18 also includes an Appli-
`cation Programming lnterface (API) 24 that provides exten-
`sions to enable application developers to extend andior
`customire the core functionality thereof (namely, the SAPS)
`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 file 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 file system 50.
`One such file system 50 is Distributed File Services (DFS),
`which is a known distributed file system implemented in a
`networked environment called the Distributed Computing
`Environment (DCE). DCE has been implemented using
`software available from the Open Systems Foundation
`(08F). In a distributed computing environment, a group of
`machines is typically referred to as a “domain." An OSI‘
`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 copcnd-
`ing application Serial No. xxixxx,xxx, assigned to the
`assignee of this invention. In addition to its use of DCE
`Services, DFS itself is rich in features. [1 provides a uniform
`global Ii lespace which allows all DFS client users to see the
`same view of the [ilespace, and it caches Iilesystem data at
`the client
`for
`improved scalability and performance by
`reducing network traffic to file servers. DFS also supports
`advisory file locking. and one of its features in the ability to
`export
`the operating system's native filesystern. For
`example, in the case of the MK Operating System, the native
`filesystem is the Journaled File System (Jl'iS). In addition,
`0115 also provides its own physical
`tilesystern,
`the DCE
`Iocal File System (II-S). The DCE LFS provides supports
`for DCE Access Control Lists (ACL’s) on files 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 Kerbcros-based authentica-
`tion. A unix "credential" is associated with each file opera-
`tion and holds the local authentication information for that
`operation.
`In particular, a credential
`is a data structure
`defining 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
`
`it]
`
`IS
`
`_
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`of operating system privileges, and an authentication iden-
`tifier known as a FAG (Process Authentication Group). The
`PAC: acts as a tag for associating "tickets” between DFS 50
`and the DCE Security Server 52. When DFS users authen-
`ticate via the DCE [.ogin facility, known as dce.
`login, the
`DCE Seeu rity Service interacts with DFS (across the
`network) through a setpago] interface to establish the PAGE
`ticket relationship in the process‘s credential. On filesystem
`requests. DFS extracts the PAC: from the credential structure
`to establish the DC E user’s authentication for RPC requests
`to the D178 Iileserver.
`
`The control flow associated with the invention is illus-
`
`trated in the process flow diagram of FIG. 3. This figures
`illustrates the basic system of FIG. 1, with the inclusion of
`an account manager 56 having an associated database 58.
`Session manager 2'7 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
`SAP 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 SAM" 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 SAP 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 AP] plug~in]{step i) to
`save appropriate usage information into the database 58
`(step i).
`
`The session manager 27 is thus invoked by the Web
`Server when a user attempts to access a DFS file. 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
`DPS pages.
`
`the
`Instead of using the basic authentication scheme,
`present invention uses Persistent Client State I-ITTP 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 ofthe range of URLs for which that state is valid.
`According to the Persistent Client State I-ITTP Cookies
`Preliminary Specification, which may be viewed at
`netseapecom at the path "inewrefr‘stdicookie_spcc_html,"
`a cookie is introduced to the client by including a Set-Cookie
`header as part of an H'l'l'P response, usually through a C61
`script. Known cookie syntax is set forth below:
`Syntax of the Set-cookie IITTP Response [leader
`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
`0007
`
`

`

`5,875,296
`
`Set-Cookie: NAME-VALUE: expires-DATE:
`path=[-’:‘\'1‘H: domain=DOMAlN_NAMii: 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 defined or required.
`This is the only required attribute on the Set-Cookie
`header.
`
`cxpircs=DKlli
`
`'Ihe expires attribute specifies a date string that defines the
`valid life lime 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
`
`Wd)’, DD—MDn-Y'YY HHIMMZSS UNIT
`domain-=DOMAIN NAME
`
`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
`UR[.will be fetched. 11. 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 qualified domain name of the
`host. A domain attribute of “acmecom” would match host
`
`names “anvil.acme.com” as well as “shipping.crate.acme-
`.com".
`Only hosts within the specified 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 “vans”. 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 “TINT
`The default value of domain is the host name of the server
`which generated the cookie response.
`
`
`path=PAITI
`
`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 pathnamc 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 “it‘oo” would match
`“tfoobar” and "r’fooflaarhtml".
`'l'hc path “2’"
`is the most
`general path.
`If the path is not specified, it as assumed to be the same
`path as the document being described by the header which
`contain the cookie.
`
`SUCH [C
`
`If a cookie is marked secure, it will only be transmitted it'
`the communications channel with the host is a secure one.
`Currently this means that secure cookies will only be sent to
`HTTPS (HTTP over SST.) servers.
`
`ll]
`
`15
`
`3o
`
`35
`
`4t]
`
`45
`
`50
`
`-
`
`60
`
`05
`
`8
`lfsecure is not specified, a cookie is considered sa [e to be
`sent in the clear over unsecured channels.
`Syntax of the Cookie HTTP Request Header
`the
`When requesting a URI.
`from an HTTP server,
`browser will match the URL against all cookies and if any
`ot‘them match. a line containing the nameivalue pairs of all
`matching cookies will be included in the HTTP request.
`Here is the format of that line:
`
`Cookie: NA ME1=OPAQU E_S’l‘RING l:
`NAM E3=O]’AQUE_STRINGZ
`
`A flowchart showing the inventive authentication flow,
`which makes use of the l-l'l'l‘P cookies, is shown in FIG. 4.
`The routine starts at step 60 for each I-l‘l’I‘lJ 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 {c.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
`erWser 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 sewer 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 7|], the user lills 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 dce_
`login mechanism. As is known in the art, running dce_login
`generates a “credential" for use by the user in obtaining
`access to DFS. If the authentication is not successliil, 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 test at step 76, the routine
`continues at step 77 to create a unique id (e.g., DCE UUID)
`for the user. At step 78, the DPS credential generated by the
`login {to the DCE Security Server) is stored in a database
`(preferably an in—memory storage) associated with the ses
`sion manager and indexed by the unique id.
`The routine continues at step 82 by sending back to the
`browser a new cookie, which includes the unique id created
`in step 76. Then, at step 83, the cookie created in step 68 is
`destroyed. The unique id, in effect, is a secret