Note: Descriptions are shown in the official language in which they were submitted.
E'~'V.PAR:S&B F&CO ;11-25-97 ; 6:16PM : 1000DELAGAUCt~TIERFy 650 W. GEORGIA
VCR;# 2/40
1
TITLE: HTIP DISTR18UTE'D REMdTE USER AUTNENTICATtON SYSTEM
Field of the Invention
The presr~nt invention relates to the field of data and
computer network secuxity. This large field can further be
divided into three security-related layers: privacy,
authentication, and access control. Privacy is the protection of
transmitted data from eavesdropping or wiretapping. It requires
that the contents of any message be disguised in such a way that
only the intended recipient can recover the original message.
file, document, or othex collection of data is said to be
authentic when it is genuine and came from its alleged source.
Message authentication is a procedure that allows eommunicatinc~
parties to verify that zeceived messages are authentic. The two
important aspects are to verify that the contents of the message
have not been altered and that the source is authentic. A
message's timeliness (it has not been artificially delayed and
replayed) and sequence relative to other messages flowing
between two parties may also bQ verified. un the context of
network managemEnt, the purpose of acnPss Control is to ensure
2G that only authorised users have aCcesS to a particular
management information base and that access to and modification
of a particular part~.on of data are limited to authorised
individuals and programs. This invention relates more
speCifiGally to a data network featuring an improved
authentication and access control functions.
Background o~ the Inventia~n
A general in~raduction to data and computer network
security is prcsvidec~ below. Ear more information on this topic,
?0 the reader is invited to consult the publications "Data and
c:amputer communications", 4th edition, New Xork, NY: Macmillan
Publishing, 1994 and "Operating Systems", 2nd edition, Engle~aood
CA 02222259 1997-11-25
CA 02222259 2002-11-04
2
Cliffs, NJ . Prentice Hall, 1995, both by William Stallings.
The following paragraphs give definitions of terms used
throughout this document.
HyperText Transfer Protocol (HTTP (from RFC 2068) : It is an
application-level protocol for distributed, collaborative,
hypermedia information systems. It is a generic, stateless,
object-oriented protocol which can be used for many tasks, such
as name servers and distributed object management systems,
through extension of its request methods. A feature of HTTP is
the typing and negotiation of data representation, allowing
systems to be built independently of the data being transferred.
302 redirect (from RFC 2068) : It is an HTTP status code. It
signifies that the requested resource resides temporarily under a
different Universal Resource Identifier (URI).
401 authenticate challenge (from RFC 2068): It is an HTTP
status code. It signifies that the request requires user
authentication. The response to the request must include a World
Wide Web-Authentication header field containing a challenge
applicable to the requested resource.
Hypertext Markup Language (HTML): It is a markup language
for hypertext that is used with World Wide Web client browsers.
Examples of uses of HTML are: publishing online documents with
headings, text, tables, lists, photos, etc., retrieving online
information via hypertext links, designing forms for conducting
transactions with remote services (for use in searching for
information, making reservations, ordering products, etc.), and
~VV.PAR:S&B F&C~ :11-25-97 ; 6:19PM ; 1000DF1.AGAUCHEI'IFRE-~ 65D W. GIrURGIA
VCR;# 4/40
3
including spreadsheets, video clips, sound clips, and other
applications directly in documents.
Traa~ssxon Control Protocol (TC°): It is a library of
routines that applications can use when they need reliable
network co~r~nunicativns with another computer. Tc:P is responsible
for verifying the correct delivery of data from client to
server. It adds support to detect errors or lust data and to
tr~.gger reconstruction until. the data is correctly and
completely received.
Intarn4t Protocol (IP): A library of routines that TCP calls
on, but which is also available t0 applieatian that do not use
TCP. IP is responsible for transporting packets ~f data from
1.5 nade to node. It forwards each packet based en a four-byte
destination address (the IP number).
Socket: Name given to the package of subroutines that
provide access to TCP/ZP on most systems.
zo
cookie: It is a tool, used to maintain state variables
concerning the World Wide Web. A cookie can take the form of an
'riTT'P header that consists of a string of information about the
visit thin is entered into the memory of the browsex. This
25 string may captain the domain, path, lifetime, and value of a
variable, among other type of information.
Uuoncad~e: It is a Unax operating system program for encoding
binary data in the American Standard Code for information
30 Interchange (ASGIIf format.
ilnifo~cm Raaource Locator (URL? : It is a standard that was
de~relaped to specify the location of a resource available
electronically. Examples of protocols that use uRLs are HTTP,
CA 02222259 1997-11-25
tnv.t'AK:S~rt3 F&CO .1l-25-97 ; 6:19P!1~ ; lOOODELAGAUCHE'fIERE~ 650 W.
GEORGIA VCR:# 5/40
4
File Transfer Fratocal (FTP), Gopher, Telnet sessions to remote
hosts on the Tnternet, and Internet e-mail addresses. The
uniform ~tesource Locator describes the location and access
method of a resource on the Internet, for examplo, the C3RI.
http://www.nortel.com describes the type of access method being
used ;http) and the server location which hosts the Web site
(www. nortel.com).
Ccm~mon Gateway Iatvrfaao (CGI) : It is a standard
fcrr.
interfacing external applications with information servers,
such
as FITTP or Web servers. A plain HTM1 document that the
Web
daemon (see definition below) retrieves is static, which
means
it exists i re a constant state. An example of this is
a text
Bile. A CGI program, on the other hand, is executed in
real-
time, so
that it can
output dynamic
information.
An example
of
the use of such
a gateway is
when a database
is hooked up
to the
World Wide Web. In l.his case, a CGI program, which the
web
daemon will execute to transmit information to the database
engine, receive
results back
and display
them to the
client,
needs to created.
be
Daaattvn: It is a program that is not invoked explicitly, but
lzes dormant, waiting for some condition to occur. It is a
process that has detached itself from a parent process and that
may either live indefinitely or be regenerated at intervals.
Typically, the program waits in the background and runs when a
request is made an the port that it is watching. It normally
w4rks out of sight of the user. On the Internet, it is most
likely encountered when e-mail is not delivered to the
recipient. The message originator receives then the original
message plus a message from a "mailer daemon."
Fc~r secure communications, it is essential to identify
specifically a source and a destination for any exchange.
CA 02222259 1997-11-25
FEV-16-98 15:48 DE: FETHERSTONHAlIGH CO ID:I 514 954 1396 PAGE 2/2
J
Authentication depends on tt-Ie source. ~.t is the responsibility
of the source to include information in any message that assures
that the origin is authentic, and it is the responsibility of
the destination to perform the required functions to insure
message integrity. However, message privacy, which is achieved
by encryption, depends on destination. That is, encryption must
be done in such a way that only the intended destination can
perform the decryption. Finally, access control depends on both
source and destination. That is, each destination may have a
distinct access policy for each potential source_
The measures taken to control access in a data processing
system fall into two categories. those associated with the user
and those associated with the data.
The control of access by user is sometimes referred to as
authentication. The most common technique for user access
control on a server is the user J.og on procedure, which z~equires
both a user identifier (ID) and a password. The system will
allow a user to log on only if that user's ID is known to the
system and if the user has entered the correct password
associated by the system with that ID_ This ID/password
combination is a notor~.ously unreliable method of user access
control_ Lasers can forget their passwords, and they can
accidentally or intentionally reveal theix password_ Hackers
have became very skilful at guessing ZDs for special users, such
as system control and systsms management personnel. Finally, the
zD/password files are subject to unauthorised access or
tampering. _
The problem of user access control is compounded over a
communication network. The log on dialogue must take place over
the communication medium, and eavesdropping is a potential
threat.
CA 02222259 1997-11-25
ENV.PAR:S,f~B F&CO ;11-25-97 ; 6:19PM , lODODEIrAGAUCHETIERE; 650 f. GEORGIA
VCR;# 6/4L1
6
User access control in a distributed environment can be
either centralised or decentralised. In a centralised approach,
the network provides a log on service to determine who is
allowed to use the network arid to whom the user is allowed to
connect.
Decentralised user access control treats the network as a
collection of transparent communication links, and the usual 7_og
on procedure is carried out by the destination host. In this
situation, the security concerns for transmitting passwords over
the network are real.
In many networks, two levels of access conl.rol may be used.
i5 Individual hosts rna~r be provided with a log on facility to
protect host-specific resou.rc~a and applications. Ira addition,
the network as a whole may provide protection to restrict
network access to authorised users. This two-level facility is
desirable for the common case in which the network connects
disparate hosts and simply provides a convenient means Of
terminal/host access. In a more uniform network ~f hosts, a
Centralised access policy can be enforced.
ThP following is a brief description of the data-oriented
access control procedures, as they are presently known in the
art.
E"oll owing successful a log on procedure in a data network,
the user is normally granted access tc one or to a set of_ hosts
and applications. This is generally not sufficient for a system
that includes sensitive data in its database. Through the
procedure for user access control, the u9Pr can be identified to
the system. Associated with Gach user, there can be a user
profile that specifies permissible operations and file accesses.
CA 02222259 1997-11-25
ENV.PAR:S&B F&CQ ;11-25-97 ; 6:19PM ; 1DOODEL9GAt~CHETIERE-~ 65D W. GEGRGIA
VCR;# 7I4D
7
The operating system carr then enforce rules based on the usex
profile. The databasr~ management system, however, must control
access to specific records or even poxtions of records, For
example, it may be permissible for anyone in administration to
obtain a Iist of company personnel, but only selected
individuals may have access Lo salary information. The issue is
more than just one of level of detail. Whereas the operating
system may grant a user permission to access a file or use an
aYplication, after which there are no further security checks,
1G the database management system must make a decision on each
individual access attempt. That decision will depend not only on
the user's identity but also on the specific parts of the data
being accessed and even an the information already divulged to
the user.
Thus, there exist in the industry a need to provide an
improved user authentication system particularly for use on a
data network, permitting to establish a strict, yet user
friendly function to control access to network resourccas or
data.
ObJectives and summary of fhe Invention
An object of the present invention is to provide a novel
a.uthenti.cation server for use in a data network
Another object of this invention is to provide an improved
customer server for supporting resources that can be released to
a user through data exchange in a data network.
Another object of Lhe invention is to provide a data network
implementing an improved user access control protocol.
CA 02222259 1997-11-25
ENV,PAR:S&B F3~C0 ~11-25-97 , 6:2UP~li : 1000DELAGAUCH~,~t'IERE-' 65U W.
GEORGIA VCR.# 8/40
B
Yet, another object or the invention is to provide a novel
data network with an improved access contxol system.
Yet, another method is to provide a novel access control
method for a data network.
As embodied and braadly described herein the invention
provides an authentication server for use in a data network that
includes a plurality of nodes connected to one another by data
1p transmission pathways, corilprising:
- a database for holding user identification data do a
plurality of users that may potentially seek access to a
resource at a first node accessibze through the data
network;
- access challenge means ~or issuing a message in the data
network for prompting a user residing ø~ a second node of
the data network to enter at the second node a user
identification data eJ.ement:
verification means operable in response to the user
identification data element entered by the user at the
second node and susceptible to grant an access right in
dependence of a contents of the user identification data
element;
- maans for issuing in the data network a communication
containing data suitable for retention try the first node
to form an access grant mark, the access grant mark being
subsequently recognizable by the first node as indication
of past occurrence of access grant by said verification
means.
In a most preferred embodiment of_ this invention, the data
network that can be defined a5 a collection of nodes connected
to one another by data transmission pathways implements a secure
access control protocol featuring a central authentication
CA 02222259 1997-11-25
ENV.PAR:S8c6 F3~C0 ;11-25-97 : B:20PM ; 1000DEL.9GAUCHE'1'IERE~ G50 W. GEORGIA
VCK;~ ~~4u
9
server. When a user is desirous to access a resource on a given
Customer server, say through HTTP data exchange session, the
browser vn the user's machine makes a first contact with the
customer server. Access to the resource that is being sought is
not permitted by the customer server since an acccse grant
control transaction has nit yet been completed, in other words,
the customer server does not know if the request made by the
user is legit~.mate. The customer server then causes initiation
of t~w access grant control transaction. The first step is to
~.0 generate a transaction TD that uniquely identifies the session
with the user. That transaction ID is Stored in a specidl URL
along with the client IP address, expiry time, check sum etc.,
its fundamental purpose being to create a unique identifier for
the session. The transaction ZD is stored in a database in the
Customer server and it is aJ.so encoded and sent t4 the uqer
along with a redirect request to the central authentication
serve.x, Most preferably, the transmission of the transaction ID
to the client is protected by any suitable encryption method,
such as by private key encryption. A suitable vehicle to
1U transmit the transaction ID is to append it to the URL string
providing the address of the authentication server, as a
parameter. That parameter, which in the usual URL nomenclature
may designate a certain file, is used here to transport the
transaction ID information.
The redirect command is received by the user's browser that
then makes contact with the central authentication server,
ca7Crying the transaction ID in one of the parameter fields of
the URL string. The authentication server receives the request
3U and determines that this user has not yet prop~:r~.y logged on the
network. The central authentication server then initiates the
access grant control procedure in the form of an authenti~atzon
cha~.lenge. In other words, the authentication server issues
control data to the user's machine to invoke on the display
CA 02222259 1997-11-25
ENV.PAR:S&B F&CO ;11-25-97 ; 6~20PM , 1000DELAGAUCHETIERE-' 850 f. GEORGIA
VCR.#10/40
screen a dialog box with user ID and password fields that must
be completed by the user. Zn addir_ion tea these two user
identification data elements, other information may also be
reouested from the user, without departing from the spiri~ of
5 the in~rention. At this paint, the user's browser will, retain in
memory the authent~i.cation data that is supplied to the
authentication server, namely the user ID, password or any other
authentication information. This function does not need to be
descrl.bed in detail since it is already provided by Commercially
i0 available browsers such as those available from ~letscape, USA.
When the authentication server receives the response to thp
authenticata.on challenge the data is compared against entries in
a database holding user Ids and passwords of authorized users.
If a match i.s found, indicating that the user is legitimate, the
authentication server extracts from ttm URL string the
transaction ID information originally generated by the customer
server holding the resource that the user seeks and that is
carried with the messe~ges the usex's machine sends to the
autheraticati~~n server. The transaction ID is then stored in the
authentication server for future reference.
At this point the authentication server issues a redirect
request to the usor's browser passing the transaction ID as
parameter in the C7RL string. Note that the transaction ID data
that is passed here may nit necessarily be identical to the
transaction ID received earlier by the authentication server as
additional data may be added to it. It should contain, however
enough information common with the transaction ID received by
the authentication server to enable the customer server holding
the resdurce sought by the client to check it against the
transaction Ip data held in the customer server's memory.
CA 02222259 1997-11-25
CA 02222259 2002-11-04
11
The redirect request points toward the customer server that
holds the resource sought by the user. When the user's browser
reconnects to the customer server, the customer server will
extract the transaction ID and compare it with the transaction
ID held in memory. If a match is found, the customer server
then determines that the session is the same than the one
corresponding to the transaction ID stored in the customer
server's memory. At this state the customer server can only
establish that session continuity has been maintained. It has
no information yet about the legitimacy of the user. To resolve
this question, the customer server establishes a communication
with the central authentication server, passing the transaction
ID data. Note that in this case the communication is not passed
through the user's machine, and it is made directly form the
customer server to the authentication server using solely a
TCP/IP protocol.
The central authentication server receives the transaction
ID and determines by comparing it to the transaction ID stored
in memory that a match exists. A status code is then sent to
the customer server to indicate that the user has been
validated. Along with the status code is passed the user ID and
authentication server user information. The customer server
then constructs a new transaction ID that is locally stored and
it is also embedded in a cookie. That cook is then passed
along with a redirect request to the user's machine, the
redirect pointing to the URL originally requested by the user.
That cookie provides a mark on the user's browser indicating
that the user is authentic. It should be noted, however that
this mark is customer server specific. In other words, it will
authorize the user's browser to connect only the customer server
that issued the cookie. If the user attempt to connect to
another customer server on the network, a new authentication
procedure will be initiated.
E'~V.PAR:S~B F&CO :11-25-97 ; 6:21PM ; 1000DF1AGAUCtiE:TtERE-~ fi50 1i.
GEORGIA VCR;~l~t4u
12
In accordance with thp redirect procedure, the user's
browser reconnects to the customer server. The presence of_ the
cookie 7.s noted and L:he Cookie data checked against the
transaction ID held ~.n memory. If a match is found then td'-ye
customer server assumes that the user is valid.
Tree next step of the verification procedure is to determine
if the user, now verified as being valid, is authorized to
access the resource he is seeking. This is effected by
retrieving the user ID from r_he memory table on the customex
server and passing it to the authentication server along with
the original URL requested by the user. That server holds a
database of user ID Codes associated with access privileges. Tf
in this particular instance the user. can have access to the
requested URL the authentication server issues a status code to
the customer server permitting release of the resource, that
would typically be a file holding information.
One advantage that results from the access control procedure
dese:ribed above is that once the user has l:~~en validated and the
cookie holding the user ID and the authentication server user
information placed in the user's browser, the interaction user/
authentication server, where the user is required to input a
2~ user III and a password is no longer necessary in instances where
the user connects wi.t.h a different customer server. During the
connection with the different customer server the exact same
access control procedure described above will take place,
however it will be transparent to the user since the step that
Consists of entering the user ID and password will be eliminated
since this data is cached on the user's browser. More
specifically, when a user attempts to connect to a different
customer server on the network, that customer server will
redirect the user°s bxowser to the authentication server, as per
CA 02222259 1997-11-25
-___.-.- _- ENV. B.F&CO ;11-25-97 : 8:21PM ; 100UDELAGAUCHEI'IERE-' 850 w.
GEORGIA VCK;~m ~u
13
the procedure described earlier. When the user's browser
accesses the authentication server, it wiT.l automatically
release the authentication information (user ID, password and
any other authentication information . This function is
inherent to Gornmercially available browsers, such as those from
Netscape, USA. This function is triggered when the browser
connects with an URA to which it has connected in the past.
Thus, when the browser recognises the URL of the authentication
server it will release the authetltieation information, that in
turn will be accepted as by the authentication server for
processing and ~~erifiaation in its tables. Therefore, this
procedure avoids the necessity for the user Gf supplying the
authentication information a second time. The redirect
procedure is an important component of this method since it
establishes a central site to whic~~? requests made by user
browsers are redirected to take advantage of the inherent
storage and release function of authent~.cation information build
in commercially available browser software.
As embodied and broadly described herein the invention also
provides a data network, comprising:
- a plurality of nodes connected to one another by data
transmission pathways;
- an authentication server residing at one of said nodes;
- a customer server residing at another one of said nodes,
said customer server supporting a certain resource;
- said customer server being responsive to a first message
from a user at. a cent-ain node of said network requesting
access to the certain resource to issue a response
message to 'the certain node, said response message
causing the certain node to initiate an access grant
contr~al transaction with said authentication server, said
access grant cantz~ol transaction chat'acterz.sed by
CA 02222259 1997-11-25
ENV.PAR:S&g P&C0 :11-25-97 ; 6~21PM ; 1GQODELAGAUCHET1ERE~ 650 W. GEORGIA
VGK;rim%4u
14
requesting the user to provide a user identification data
element.
~.s embodied and broadly described herein the invention also
provides a customer server for use in a network including an
authenticaticn server.', said customer server providing means for
supporting a certain resource potentially sought by a user from
a certain node of a network, said customer server being
responsive to a message issued from the certain rode requesting
release of the certain resource to generate a control message to
the certain node prompting i.he certain node to initiate an
aCCess grant control transaction with the authentication server.
A custr~mer server for use in a network including an
authenticatior: server, said customer server pr,widing means for
supporting a cextain resource potentially sought by a user from
a certain node of a network, said customer server being
responsive at least in part to a first message issued from the
authentication server to issue a second message to the certain
~0 node, said second message including data suitable for retention
by the certain node to form an access grant mark, the access
grant mark being reGOgnizable by the customer server as
indication of ocCUrrenCe of an access grant control transaction
between the authentication server and Lhe certain node.
As embodied and broadly described herein, the invention also
provides a method for access control in a data network
including:
- a plurality of nodes connected to one another by data
transmission pathways.
- an authentication server residing at one of ~aa.d nodes:
- a customer sewer residing at another one of said nodes,
said customer server supporting a certain resource, said
method comprising the steps of:
CA 02222259 1997-11-25
ENV.PAR:S&B F&CO ;11-25-97 , 6:22P!~ ; 1000DELAGAUCHE.~('IERE~ 650 W. GEORGIA
VCR,#15~'4U
receiving at said customer server a request for access by
a user residing at a Certain node of the data network to
the certain resource;
issuing a control message toward the. certain node to
5 cause initiation of an access grant control transaction
with said authentication server, said access grant
control transaction characterised by requesting the user
to provide a user identification data element.
l0 Brief description of the drawings
Figure 1 is a block diagram showing a general overview of a
client/server network constructed in acedrdanre with the present
in venti.on;
15 Figure 2 is a flowchart ilJ.ustrating thQ steps of a method
for authenticating a user for the purpose of releasing a certain
resource, in acCOrdance with the invention.
Descripfion of a preferred embodiment
An overall view 4f a client/server data and computer
communications network is shown in figure 1. Web browser/clients
200 to 1U8, residing on individual. computers using HTTP 1.X, are
corneeted to the digital network 16Q. Also connected to the
digital network 160, ~.s an authentication server 1I0. Most
prefereably, a single authentication server 110 p.s provided for
the entire network, rather than two or more of those servers.
The advantage of this arrangement is that passwords and user rDs
data needs to be stored and maintained in a single location in
the network. Evidently, the invention is not limited to this
particular feature. The authentication server 110 includes are
Authentication Daemon (Al7p verification daemon 112, a A17 CGI
program Iln, a table 115 held i:~ the memory of the server, a URL
CA 02222259 1997-11-25
;11-25-97 ; 6:22PM ; 1000DEL.AGAUCHETIERE~ 650 f. GEORGIA VCK;arm 4u
16
security server 116, a ORL access list 11'7, an authentication
HTTP servex 11$ and an authentication database 11,9. Thp
authentication database 119 is a simply table which may hold
usernames, personal identification numbers and passwords. The
storage and update of this information is an administrative
fur~ct:ion. Finally, a number cf customer servers 120 to i50 are
connected to the digital network 160. Each r_ustomer server, such
as 120, includes a memory table 122, a AD 124 and a customer
H'fTP server 126. The interactions between each of the components
of the network are detailed below. A point to note is that. all
communications between the client browser 100 arid the
authentication server 110, or a customer HTTP server 120 to 250,
are performed using HTTp 1.X. On the ocher hand, communications
between servers are made directly over the TCP/IP format with no
higher protocol required.
mote that a complete description of the various data
structures for the memory tables, the spocial URLs and cookie
can be found at the end of this section. Also note that the AD
verification daemon 1,12, the AD CGI prcgram 114, the URI,
security server 116 and the authentication HTTP server 11$
functional blocks are programs and are axecuted by the CPU of
the authentication server 11a. furthermore, the AD 124 is a
program that is executed Y~y the CPU of the customer server 120.
Figure 2 is a detailed flowchart of the events taking place
when a user desires to a4cess a resource, such a certain file
that is located on a customer server of the digital network.
Firstly, a client 100 makes a request (step 200) for a ,
connection to a secure customer HTTF server such as 126 by
specifying .a URL. The URh contains the address of the
Authentication Daemon 124 located on the customer server 120,
and therefore connects to the AD (step 202) tc establish the
CA 02222259 1997-11-25
E'VV.PAR~S&B F&CO ;11-25-07 ; 6:22PM ; 1000DELAG4UCtiETtERE-~ 650 ~. GEORGIA
V(,~;#17~4u
17
connection through the digital network 1~0. The purpose of the
Authentication Daemon 124 involvement is to determine if the
request made by the client can be authorized. More
specifically, the Authentication 1?aemon 124 will inspect the
HTTP header of the data sent by the browser of the client for a
special URL (step 244). This information, to be generated and
embedded later in the header, is not available at this point.
The AD wi7.1 also look for a specific cookie !step 206) in the
HTTP header and, at this point, will not find it either. The
Authentication Daemon 124 then concludes that the request made
by the client has not boen authenticated and it will initiate an
authentication procedure involving the authentication server
110. At step 208 the Authentication Daemon 124 will generate a
unique 4 byte olient ID and a 15 byte random transaction ID and
store them (step 210) in a row of the memory table 122 along
with the client's IP address and the special URL expiry time. At
step 212, a special URL is constructed from the row ID,~client
ID, transaction ID and a checksum of these three values. This
inFormation is then enczypted using a simple private key
encryption algorithm, uuencoded and URL encoded to facilitate
transmission tstep 214y. At step 216, the AD issues, to the
client browsex 100, a 302 redirect to the A1~ CGI prograr.~ 114 on
the authentication sorver 110, passing the special URL as a
parameter. Morc specifically, the redirect command includes an
URL string that points to the AD CGI 119, a parameter of the
string conveying the transar_.tion ID constructed earlier.
A point to note is that all these steps are transparent to
the user. Instances when the usex is prompted will be anrmtated
accordingly.
The authentication server 110 receives the request for trie
automatic redirect and an attempt to run the AD CGI program 114
is made. The authentication server 110 will determine whether
CA 02222259 1997-11-25
ENV.PAR:S&B P&CO ;11-25-97 , 8:23PM ; 100UDEL.AGAUCHE'fIfRE-' 65U ~. GEORGIA
VCR;#18140
18
this browses has ever attempted to log on to it before. This is
done through the use of an HTTP header from the client's browses
100 (step 218). The authentication sever 110 looks for the
proper authentication information present in the HTTP header,
does not find it, and, therefore, sends a 401 authentication
challenge back to the client s browses (step 220). At this point
(strip 222), tl~~e browses 100 will prompt the user for the
authenticateon log~.n information.
The client now sees a dialog window on the screen that
requests him to login, He enters his authentication lagin
information, such as his user ID, password and any other
authentication data. A.s discussed earlier, the browse' will
store this data internally sa it can be released again when the
browses reconnects to the authentication server. This function
will he described later. For the time being suffice it to Say
that the Function is useful when an authentication procedure
must be completed when the user washes to access a different
resource located on another customer server in th~ network.
The browses reconnects to the authentication HTTP server 11B
supplying Lhe authentication information. contrary to the
previous request (step 219?, the client browsPr now sends the
proper HTTP header to the authentication HTxg server 118,
compares, at step 224, the authentication information to the
authentication database 119 and if the information is correct,
launches an instance oL the AD CGI program (step 228) and
8xecutes it. The AD CGI decodes tre passed special URh (step
230), allocates a row in the memory table 115 and stores the row
ID, the client ID, transaction ID, user ID and time out value in
the row (step 232). At step 234, another special URT., containing
the AD authentication table row ID, client ID, transactipn ID
and checksum of these three values ~.s constructed. The Al~ CGI
program 114 then issues (step 236?. to the client browses, a 302
CA 02222259 1997-11-25
CA 02222259 2002-11-04
19
redirect to the AD 124 on the customer server 120 passing, in
the HTTP header, the special URL as a parameter. The special URL
points, in fact, to the AD 124, passing as a parameter the
transaction ID data.
The scheme then returns to step 200, where the client's
browser 100 makes a request, through the AD 124, for a
connection to the secure customer HTTP server 126. The AD 124
on the customer HTTP server 120 will detect the special URL
containing the transaction ID. The row ID, client ID,
transaction ID and authentication row ID are extracted from the
special URL (step 238). At step 240, the client ID, transaction
ID, time out value and client IP address are verified against
those stored in the memory table 122. If the verification is
successful (step 242), the scheme will proceed to step 244.
In the next few steps, the AD 24 will verify that the
client 100 did in fact logon to the authentication server 110
thereby eliminating intruders. At step 244, the AD 124 on the
customer server 120 establishes a direct connection to the AD
verification daemon 112 on the authentication server 110 passing
along the client ID, transaction ID and authentication row ID
(step 246). This connection is made by using the TCP/IP
protocol, without involving HTTP. The AD verification daemon 112
authenticates the client ID and transaction ID by comparing
them, at step 248, to the values in the memory table 115. At
step 250, it deletes the row and, at step 252, passes back, to
the AD 124, a status code, the user ID, the authentication
server user information, the maximum number of accesses allowed
and the cookie expiry time limit. If the authentication has
been successful the status code will typically indicate this by
using any suitable nomenclature. The AD 124 on the customer
server 120 then checks the status code (step 254), at step 256,
generates a new 16 byte transaction ID and constructs a cookie
CA 02222259 2002-11-04
out of memory table 122 row ID, client ID and the new transaction
ID. This information is then encrypted (step 258) using the same
method as for the first special URL, that is, using a simple
private key encryption algorithm, UU encoding and URL encoding
5 the data. At step 260, the AD 124 on the customer server 120
issues, to the client browser 100, a 302 redirect to the original
URL requested in step 200 and, this time, includes the cookie in
the HTTP response header. That cookie, in accordance with well-
know HTTP communication protocols, will provide a session-
10 persistent mark on the client browser that allows the server onto
which he was just logged on to verify that this user has
performed the procedure described above. It is important to note
that the cookie allows the customer server to determine that the
user has been authenticated. That cookie, however, is only valid
15 for that particular customer server. If the user wishes to
access a resource located on another customer server, a new
cookie must be constructed for the new customer server, by
following the procedure describe above.
20 In accordance with the 302-redirect procedure, the client
browser 100 reconnects to the AD 124 on the customer server 120
(step 200), requesting the original URL (customer HTTP server
126). This time, the AD 124 detects the presence of the AD
cookie embedded earlier and extracts the correct AD cookie from
others that may be present. The row ID, client ID and
transaction ID are determined from the cookie and, at steps 262
and 264, are verified against the memory table 122. In addition,
the number of transactions completed is checked (step 266) and
the number of transactions left is decremented by one (step 268).
One last verification now needs to be performed, which is to
ensure that the user has access to the URL requested (customer
HTTP server 126). In order to do this, the user ID is retrieved
CA 02222259 2002-11-04
21
(step 270) from the memory table 122. At step 272, the user ID
and URL requested are forwarded to the URL security server 116
on the authentication server 110, which verifies (step 274) that
the user has access to this URL (customer HTTP server 126) and
that the URL is enabled, by comparing the information to the URL
access list 117. This communication is effected from server to
server by using solely the TCP/IP protocol. At step 276, the
URL security server 116 returns a status indicating whether the
verification procedure was successful or not (true or false
status) to the AD 124 on the customer server 12. At step 278,
the AD 124 checks the status then, at step 280, forwards the
request to the customer HTTP server 126 requested (i.e. the
original URL requested) including the user ID, user information
and basic authentication information in the HTTP request
headers. At step 282, the customer HTTP server 126 performs
basic authentication as it normally would (i.e. without this
invention embodied) and then responds to the AD 124, which
generates a new cookie (as described in step 256) and forwards
it along with the customer HTTP server 126 response back to the
client browser 100 where it will be cached in memory (step 284).
Note that basic authentication is part of the established HTTP
and is well known to those skilled in the art and therefore will
not be described in detail here. The connection is now
established (step 286) and the user has access to the requested
information.
Once the user has finished viewing the information, he will
do one of three things: 1- exit the browser; 2- exit this site
and request the same site later on; or 3- exit this site and
request a different site.
If the user exits the browser (step 290), the scheme will
be initiated from the start box the next time he needs access to
a secure HTTP server.
E~iV.P.~1R:5&B F&CQ ;11-25-97 : 6:24PM ; 1000DELrIGAUCHETIERE~ 650 W. GEORGIA
VCR;#22/40
22
If the user further accesses the same customer HTTE~ server
126 (step 292) before exiting his browses, the procedure will. go
to step 200, but when he reaches step 206 ("Correct AD cookie
present?"), he will jump directly to step 2&2 to compare the
cookie to the memory table 122 and carry on from there.
If the user exits this site and requests aCCeSS to a new
customer server, say 150 tstep 294), the whole procedure must be
completed again with the exception that when step 216 is reached
(verification of authentication information) it w~.ll go directly
to step 224 since the client has already provided his user ID
and password in has initial request and ti;is information is
cached on his brawler. More specifically, the new customer
server will examine the information supplied by the user's
browses and it will determine that the proper cookie required to
access the resource held en the new customer server is not
present. The new customer server will then issue a redirect
command causing the user's browses tp connect with the
authentication server. Dur:.ng the reconnect procedure, the
user's browses will recognize the URL 4f the authentication
server and will xelease the authentication information that it
holds, namely the user ID and password. That authentication
information is processed by the authentication server and the
new cookie suitable to allow the user's browses to access the
new customer server is generated.
The ir.fc.rmation provided below is a complete description of
the various data structures for the memory tables, the special
tJRl,s and cookie .
Ds~ta structure of memory t~rble 122 on cuotorioer aexwer 120:
- 16 byte transaction ID
CA 02222259 1997-11-25
E~VV.P~R:S~B F&CO :11-25-:l7 ; 6:24PM ; 1000DELAGAUCt~TIERE-~ 650 1~. GEORGIA
vC:K:~z~~~u
23
- 128 byte character string for user specific data
-- 9 byte signed client ID
- 4 byte unsigned access count
- d byte signed expiry time
- 4 byte signed last accessed time
- 9 byte uns~.gned peer address
- E byte random number generator seed
- 9 byte character string user IU
Data structure of memory table 115 on authentication sarvox
110:
- 26 byte transaction ID
-- 12$ byte character string for user specific data
- 4 byte signed client ID
- 4 byte unsigned access count
- 4 byte signed expiry time
9 byre character string user ID
Data structure o~ special ORL produced by AD X24 on customer
server 120:
- Special URA ~aersion strzng
byte unsigned row ID stored as a string
- 4 byte signed client ID stored as a string
- 16 byte transaction iD stored as a string
- HUSt name or IP address of customer server her stored as
a string
- ariginal requested TJRI, string
T 4 byte unsigned CRC stored as a string
Data structure o~ special URL produced by AD CGI 119 vn
authonticatiorr aorwr ilp
- special URL version string
CA 02222259 1997-11-25
ENV. PAR: S&B P&Ca ;11-25-97 ; 6 ~ 24PM , 1 UOODFIAGAUCHET' 1 ERE- 65U w .
(itVKV i R vm ~ w.=~r =~
29
- 4 byte unsigned row ID stored as a string
- 4 byte signed r.l.ient ID stored as a string
- 16 byte transaction TD stored as a string
- Orir~inal requested URL suing
- 4 byte unsigned rdw ID of table row on the authentication
server
4 byte unsigned CRC stored as a string
Data structure of cookio producod by AD 124 on austom~rr
eorva~r 120:
- c:nr~kie version string
- 4 byte unsigned row ID stored as a str~.rg
-- Q byte signed client ID stored as a suing
16 byte transaction ID stored as a string
5 - 4 byte unsigned CRC stored as a suing
CA 02222259 1997-11-25
