Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
WEB-BASED SINGLE-SIGN-ON
AUTHENTICATION MECHANISM
BACKGROUND OF THE INVENTION
The present invention relates to authentication mechanisms
for computer networks, and more specifically, relates to single
sign-on authentication mechanisms for enforcing authorized
access to a plurality of services distributed over a network (for
t 0 example, the Internet).
As an increasing number of services begin to be offered
over the Internet, the ability to provide an effective and secure
single sign-on mechanism for access to such services has become
extremely important. Services offered over the Internet are often
t5 distributed on a plurality of servers that are in remote locations
with respect to each other. Traditionally, each server offering a
service or services would have to implement its own
authentication mechanism for security purposes. Thus, a
consumer of multiple services on the Internet would often have to
20 store and recall a plurality of user names, passwords, and/or digital
certificates. Moreover, each server or service would have to
implement its own authentication protocol. The total sum of
resources, time and expenses required for implementing separate
authentication procedures on each of a plurality of resources is
25 large enough to justify alternate solutions.
One known solution to this problem is to implement a
single sign-on mechanism through which a user can authenticate
his identity and authorization to use a plurality of services
distributed over a plurality of remote servers through an
30 authentication procedure running on one or a small number of
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
2
servers. For example, in one known solution shown in Figure 1 a,
server 185 offering a service passes authentication request 190
received from user 187 to authenticating agent 189.
Authenticating agent 189, if it successfully authenticates the user,
transmits data 192 to server 185 authorizing the provision of the
service to user 187. Then, service 185 provides service 194 to
user 187. In this way, authentication can be performed for a
plurality of servers offering services through a single
authenticating agent, and hence a single sign-on mechanism.
One deficiency of this method is that the authenticating
procedures are not entirely divorced from the service server. In
this method, the service server needs to have functionality
allowing it to recognize a user's request for authentication and
forward this request to the authenticating agent. Further, the
t5 service server has to have functionality allowing it to recognize a
transmission from the authenticating server authorizing or refusing
to authorize the user's request. Thus, each new service added to
the plurality of services secured by the authenticating agent
requires installation and maintenance of this functionality.
Second, in this method, a service server has to initiate an
authentication negotiation with the authentication agent anew each
time the user attempts to use a service on a new server from the
plurality of servers during a session. Consequently, the fact that
the user has already been successfully authenticated during a
session is of no benefit at all for verifying the authorization of a
user to access a new service during the session; the new service
must forward a new user request for authentication to the
authentication agent and wait for a response.
Thus, a single sign-on mechanism for accessing a plurality
of services distributed over a network is needed in which
authentication-related functionality is separated from the services,
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
3
and in which authentication need not be renegotiated for access to
a new service from the plurality of services during a session.
SUMMARY OF THE INVENTION
The deficiency in prior known systems and methods are
overcome by embodiments of the present invention, which
disclose a novel, single sign-on authentication method and system
for accessing a plurality of services distributed over a network. In
accordance with an embodiment of the present invention, a request
is received from a user for authorization to access a service. In
response, a token corresponding to the service is transmitted to the
user. Subsequently, the token corresponding to the service is
received from the user. Then, whether the user is authorized to
receive the service is determined, based on the token.
~5 Subsequently, the user is connected to the service, if the user is
authorized to use the service.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 a is a block diagram of a system in accordance
with a prior, known method.
Figure lb is a block diagram of a system in accordance
with the present invention.
Figure lc is a block diagram of a section of a system in
accordance with an embodiment of the present invention.
Figure 2 illustrates a flow diagram of a first embodiment of
the present invention
Figure 3 illustrates a flow diagram of a second
embodiment of the present invention.
Figure 4 is a block diagram of a system in accordance with
the second embodiment.
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
4
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention disclose a single
sign-on method and system for accessing a plurality of services
distributed over a network in which authentication-related
functionality is separated from the services, and in which
authentication need not be renegotiated for access to a new service
from the plurality of services during a session. Additional benefits
accruing from embodiments of the invention include notification
of the plurality of services when a user has terminated a session,
and the use of secure, short-lived authentication tokens to verify a
user's identity for subsequent access to the plurality of services.
Figure 1 b shows a system in accordance with embodiments
of the present invention. Figure 1 b also shows paths of data flows
in the system that are depicted with dotted lines labeled with
numbers in braces (the dotted lines may signify network
connections between the entities at the end points of the dotted
lines). In Figure 1 b, user 130 is connected to Internet 10. Internet
10 includes a plurality of resources in a network, such as servers
30, 40, 50 and Cloud 20. Cloud 20 comprises a collection of
servers, for example servers 60, 70, 80 and 90, that offer a
plurality of services for authorized Cloud users. In particular,
service 95, which is located on server 90, is one of the services
offered on Cloud 20.
A "remote" connection is said to exist between two
entities, if the entities are connected through one or more network
connections. If two connected entities are not connected through
at least one network connection, a "local" connection may be said
to exist between the two entities. An entity connected to another
entity by a remote connection may be said to be "remote" from the
other entity.
Gateway 100 is responsible for registering users of Cloud
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
20 and authenticating registered users for connection to services
offered on Cloud 20. In Figure 1 b, Gateway 100 is shown to be
connected to user 130, the Internet 10 and Cloud 20. However,
Gateway 100 may be connected to a plurality of users and/or a
5 plurality of networks. Gateway 100 includes a registration proxy
115, an authentication proxy 120 and a data proxy 110.
Registration proxy 115, authentication proxy 120 and data proxy
110 are logical units that may be implemented in hardware or
software. In particular, any or all of the functionality within
Gateway 100, including that of authentication proxy 120, data
proxy 110 and registration proxy 11 S, may be spread over one or
more physical units. For example, data proxy 110 may comprise a
plurality of logical units, each located on a server at a different
node within a network, e.g., the Internet, or on the same unit.
~5 A user of Cloud 20 initially registers with registration
proxy 115 in order to use the web-based authentication mechanism
for access to services available on Cloud 20. The user begins the
registration procedure by connecting to the registration proxy. For
example, the user may use a standard web browser to connect to
20 registration proxy 115 using the Uniform Resource Locator
("URL") of Gateway 100 or registration proxy 115. The
connection may be made using the Secure Sockets Layer ("SSL")
protocol for ensuring data security during the registration
procedure. Alternatively, this connection may be made through
25 any secure communications protocol, e.g., the Transport Layer
Security ("TLS") protocol (e.g., RFC 2246). A secure
communications protocol allows communication in a way that is
designed to prevent eavesdropping, tampering, or message
forgery.
3o The user may register by choosing and communicating to
registration proxy 115 credentials that may be used for
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
6
authentication to Cloud 20. For example, the user may choose a
user name and a password, or a user name and a digital certificate,
e.g., a X.509 standard certificate, as credentials for authentication
purposes. The user must choose at least one credential to
complete the registration procedure. The user, during the
registration process, may additionally be required to specify
billing information, including a credit card number or a bank
account number, for use in paying for Cloud services. The dotted
line labeled "(1)" in Figure lb between user 130 and registration
t0 proxy 115 indicates the data flow in connection with the
registration to Cloud 20. This connection may be made through
Internet 10. Once the registration process has been completed, this
connection may be dropped.
Once user 130 registers with Cloud 20, he may access one
or more services on Cloud 20. However, before user 130 can be
connected to a Cloud service, he may be required to authenticate
his identity to Gateway 100. A user that authenticates his identity
is authorized to access one or more services on Cloud 20. User
130 authenticates his identity by connecting to authentication
2o proxy 120 and presenting his authentication credentials. User 130
may establish a connection to authentication proxy 120 by
specifying the URL of Gateway 100, authentication proxy 120, or
any service within the Cloud to his web browser. User 130 may
then specify his user name and password, or he may specify his
user name and present a digital certificate, in response to a prompt
from authentication proxy 120. The connection between
authentication proxy 120 and user 130 may be made using the SSL
protocol, or any other secure communications protocol, for data
security purposes. The dotted line labeled "(2)" in Figure 1 b
between user 130 and authentication proxy 120 indicates data flow
during authentication (as well as the flow of tokens from
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
7
authentication proxy 120 to user 130, which will be discussed
shortly). This connection, which may be said to establish a
channel between user 130 and authentication proxy 120, may be
made through Internet 10. In one embodiment, once user 130
authenticates his identity to authentication proxy 120, the original
connection between authentication proxy 120 and user 130 is
severed and replaced by a new, secure connection (or channel)
called a network control connection. For example, after user 130
successfully authenticates his identity, authentication proxy 120
t0 may send user 130's browser a web page with a JavaScript
program that contains a unique URL, and then terminate the
connection to user 130. The JavaScript program received by user
130's browser may then reconnect to authentication proxy 120
through the unique URL. This connection may in particular be a
mutually authenticated SSL connection, or a connection using any
other secure communications protocol.
After user 130 authenticates his identity to authentication
proxy 120, he may receive services on Cloud 20 for which he is
authorized without any other authentication procedures that are
apparent to user 130 (i.e., transparently), as long as the network
control connection between authentication proxy 120 and user 130
remains intact. After authentication, authentication proxy 120
may store user 130's identification information in an authenticated
connections table ("ACT"). User 130's identification information
may remain in the ACT until the connection between user 130 and
authentication proxy 120 is severed. Authentication proxy 120
may share the list of active Cloud users stored in the ACT with
data proxy 110.
Additionally, while the network control connection
between authentication proxy 120 and user 130 remains intact,
authentication proxy 120 may continually transmit a plurality of
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
8
tokens to user 130 over the connection. Each token may contain
information specific to one or more services, for example,
identification numbers of the services to which the token
corresponds. Additionally, each token transmitted to user 130
may include identification information specific to user 130 and a
time value indicating the expiration time of the token. Moreover,
each token may be encrypted by authentication proxy 120 using a
secret key that is generated by authentication proxy 120.
Authentication proxy 120 may also store a unique identifier
t0 corresponding to the secret key in the ACT. Authentication proxy
120 may also place the unique identifier in the token that is
encrypted by the corresponding key. Further, each token may be
embedded in a http-protocol cookie.
In one embodiment, a list of registered users together with
the services the registered users are authorized to access may be
stored in a memory in Gateway 100. In that embodiment, once a
user has properly authenticated his identity to access services on
Cloud 20, he may be sent only tokens corresponding to the
services for which he is registered.
Assuming that the network control connection remains
intact, for each token that is about to expire, authentication proxy
120 may transmit a token that is substantially similar to the token
about to expire, but having a new expiration time value, and/or
encrypted with a different key. The length of the interval of time
in which a token is valid may be predetermined and equal to a
multiple of the lifetime of the encryption key. In other
embodiments, the length of time in which a token is valid may be
generated randomly. A token may be invalidated by removing the
unique identifier corresponding to the key used for encrypting the
token from the ACT. This has the effect of invalidating all tokens
corresponding to that key in the system. Additionally, when user
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
9
130 terminates a work session by, for example, closing the
browser, the browser may remove all cookies containing the
tokens stored in user 130's browser. Furthermore, tokens may be
invalidated upon the system comprising Gateway 100 determining
that a security event indicating a possible breach or unauthorized
access has occurred. Gateway 100 may invalidate tokens, for
example, by simply changing keys and distributing the new keys
to data proxy 110, which effectively logs off all users.
Alternatively, if keys are issued on a per user basis, Gateway 100
1o may log off one or more users individually.
In another embodiment, the interruption of the network
connection between authentication proxy 120 and user 130 may
cause authentication proxy 120 to remove user 130's identification
information from the ACT. In this embodiment, authentication
t5 proxy 120 treats any token received from a user whose
identification information does not appear in the ACT as being
invalid. Thus, in this embodiment, a user's tokens are invalidated
upon removal of the user's identification information from the
ACT.
20 After the authentication procedure, user 130 may attempt
to connect to a Cloud service by specifying the URL of the service
on user 130's browser. Alternatively, user 130 may be
automatically redirected to the desired service. The domain name
entered by user 130 in his browser may cause the browser to
25 detect that the requested service is protected by Gateway 100. The
browser may then connect to data proxy 110 and transmit the
cookie containing the token (or tokens) corresponding to the
service requested by user 130. The connection to data proxy 110
(forming a second channel, in addition to the first channel between
30 user 130 and authentication proxy 120) may be made using the
SSL protocol, or any other secure communications protocol, to
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
assure data security. Data proxy 110 may extract an encrypted
token (or tokens) from the cookie, decrypt the token (or tokens),
verify its validity and extract the identification information
contained within. In particular, data proxy 110 may extract the
5 unique key identifier corresponding to the key used to encrypt the
token. Data proxy 110 may verify that connection of user 130 to
the requested service is authorized by checking the ACT for a
match with the extracted unique key identifier. Additionally, data
proxy 110 may check that the extracted identification information
t0 matches one of the users listed in the ACT. Matches between
information stored in the token and information stored in the ACT
may indicate the validity of the token. The dotted line labeled
"(3)" in Figure 1 b between user 130 and data proxy 110 indicates
the data flow for transmission of tokens from user 130 and the
verification of their validity at data proxy 110. This connection
may be made through Internet 10.
If the token is determined to be valid, data proxy 110 may
initiate a proxy connection to the service requested by user 130
using the SSL protocol, or any other secure communications
protocol, on user 130's behalf. Thus, user 130 may begin to use
the requested service through its connection to data proxy 110 and
through data proxy 110's connection to the service, after
completion of the procedure as described above. The dotted line
labeled "(4)" in Figure 1 b between service 95 and data proxy 110
indicates the data flow over the connection between user 130 and
data proxy 110.
Figure lc shows the transmission of cookies among
authentication proxy 120, user 130 and data proxy 110 over
Internet 10, in one embodiment of the present invention. After
user 130 authenticates his identity, he receives a stream of tokens
through a first connection (i.e. a first channel) from authentication
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
proxy 120, wherein each token corresponds to one or more
services on Cloud 20. For example, user 130 may receive cookies
145 and 150. When user 130 attempts to connect to a Cloud
service, his browser will be redirected and connect to data proxy
110 through a second connection (i.e. a second channel). User
130's browser will then transmit the cookie or cookies
corresponding to the requested service to data proxy 110 through
the second connection. For example, user 130's browser may
transmit cookies 160 and 175 to data proxy 110.
Thus, the disclosed system provides authentication
functionality allowing authorized users to access services over a
network. The system comprises a gateway that authenticates users
for access to the services. Moreover, all of the authentication
functionality of the system exists only on the gateway. For
~5 example, a new service added to the services for which the
gateway performs authentication functionality does not require
any augmentation for proper functioning of the authentication
functionality of the system.
An authentication token may be
passed to the user in a the "Set-Cookie" field of a Hypertext
Transfer Protocol ("http") header. In one embodiment, the
structure of this field is given as:Set-Cookie:
<Cookie-Name>=<Cookie-Value>
;EXPIRES=<expiration time>
;DOMAIN=<destination-domain>
;PATH=<destination-path>
[;SECURE]
The following fields appear within
the "Set-cookie" field:
cookie-name - the name of the cookie. This
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
12
value is equal to GeoPlexIdSecure for the cookies used over the
secure connections (https). For regular http connections this name
is set to GeoPlexId.
expiration-time - the date string formatted
as:
Wdy, DD-Mon-YY HH:MM:SS GMT
Wdy - is the day of the week (for example, Mon or Tues); DD is a
two-digit representation of the day of the month; Mon is a three-
letter abbreviation for the month (for example, Jan or Feb); YY is
the last two digits of the year; HH:MM:SS are hours, minutes, and
seconds, respectively. The authentication proxy may set this value
to be the current time plus the cookie validity period. The
expiration of a cookie may be enforced by the authentication
proxy. The presence of an expiration value on the user's side sets
the guidelines for the use of the cookie for the user's browser.
destination-domain - the attributes of a protected domain that may
be accessed using this authentication token;
destination-path - the path in the protected domain for which this
cookie is intended;
SECURE - this specifier denotes authentication tokens that are
sent only over secure connections. The authentication proxy sets
this attribute only for cookies destined to SSL protected domains
(https). The presence of this value on the users's side sets the
guidelines for the use of the cookie for the user's browser.
3o Cookie-Value - base-64 encoded authentication token:
base-64 - encoded struct {
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
13
uint8 TokenMagic[4];
uint32 Version;
uint32 HashType;
opaque HashValue[20];
uint32 WorkKeyId;
uint32 CipherType;
uint32 ContentLength;
encrypted struct {
opaque
TokenContent[AuthenticationToken.ContentLength];
select (CipherType) {
case block:
uint8 padding[Padding.padding-length];
uint8 padding-length;
} Padding;
} EncryptedContent;
} GeoAuthenticationToken;
TokenMagic is a four-byte value that allows the quick recognition
of the structure of AuthenticationToken:
TokenMagic = { 'G', 'E', 'O', 'X' };
Version - the version of the AuthenticationToken structure.
Currently the value of this field is 1.
HashType - the identifier of a hash algorithm used to compute the
cryptographic checksum stored in the HashValue field.
enum {
HashType_md5,
HashType-shal
} HashType;
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
14
HashValue - is the hash value of the following data fields in the
cryptographic token:
WorkKeyId, CipherType, ContentLength, TokenContent
(unencrypted), Padding (unencrypted).
If the md5 hash function is used, the hash value is stored in
first 16 bytes of the HashValue field. The hash value for the shal
hash function is 20 bytes long.
WorkKeyId - the identifier of an encryption key used to encrypt
the token.
CipherType - the identifier of a cipher used to encrypt the token.
enum {
CipherType-des,
t5 CipherType_ides,
CipherType_rc4
} CipherType;
Content-Length - the length of the token (plain text), in bytes.
Token-Type - the identifier of the token.
enum {
TokenType_http
} TokenType;
TokenContent - the encrypted token.
struct {
opaque random[8];
uint32 GeoPlexUserid;
TokenType type;
select (type) {
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
case http:
uint32 Secure;
uint32 DomainLength;
uint8 Domain[TokenContent.DomainLength];
5 ) TokenContent;
GeoTokenContent;
Random - eight random bytes help to prevent a known plain text
attack when a stream cipher such as RC4 is used.
Secure - this flag is set if this authentication token should be used
only over secure connections.
Domain - attributes of the domain (URI) for which this cookie
was issued.
GeoPlexUserid - user id of the token owner.
Padding - padding of the TokenContent field to be a multiple of
eight. This field is present only when a block cipher was used to
encrypt the token.
In this embodiment, authentication tokens have a limited
validity period, which is enforced by the authentication proxy.
When the token validity period is about to expire, the
authentication proxy updates the tokens issued to all active users
by sending a new set of http cookies.
Each updated set of tokens issued to a user is encrypted
with a key different from the one used to encrypt the previous set
of tokens. This measure prevents replay attacks against the
authentication proxy when a malicious user may send a stolen
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
16
token to gain access to a protected resource. Immediate replay
attacks are made impossible since fresh tokens are delivered over a
SSL protocol-protected (or other secure communications protocol-
protected) network connection.
In order to provide the keying material for the next
generation of authentication tokens the authentication proxy
updates its pool of random data, called the master secret, every T
minutes. When a master secret object is created, it is assigned a
handle that uniquely identifies the object. The authentication
1o proxy keeps one preceding instance of the master secret so that the
tokens issued under the older master secret are still valid for some
time. This is done in order to avoid the race condition when new
tokens are already issued but have not reached the user yet. The
update period T is a configurable parameter
("KeyGenerationInterval") set by the System Administrator. Each
newly generated master secret object is marshaled by the
authentication proxy and is saved in the ACT. The authentication
proxy stores the two most recent marshaled master secret objects
in the ACT. A new marshaled master secret object replaces the
older, saved, marshaled master secret object in the ACT.
In one embodiment, authentication proxy 120 periodically
and automatically sends tokens to user 130 over the network
control connection. In particular, in this embodiment,
authentication proxy 120 automatically sends user 130 tokens
encrypted with new keys after an update of the master secret.
Thus, in this embodiment, the gateway "pushes" updated tokens to
the user. This embodiment may be implemented, for example,
where user 130's browser supports multi-part data types-defined
in the MIME 1.0 specification.
Alternatively, in another embodiment, authentication proxy
120 will send user 130 a meta http tag after user 130 reconnects to
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
17
the authentication proxy through the network control connection.
The meta http tag causes user 130's browser to periodically and
automatically send a request signal to authentication proxy 120
through the network control connection. When the master secret
is updated, authentication proxy 120 sends tokens encrypted with
new keys to user 130, as long as authentication proxy 120 has
received the last scheduled request signal, and/or has received at
least one request signal during a predetermined amount of time.
Thus, in this embodiment, the user "pulls" updated tokens from
the gateway. This embodiment may be implemented, for example,
where user 130's browser does not support multi-part MIME data
types.
Figure 2 shows one embodiment of the present invention.
At step 200, a request from a user for authorization to access a
t5 service is received. The user may request authorization to access
services on Cloud 20, for example, by attempting to log on
through authentication proxy 120 for access to services on Cloud
20. User 130 may make such a request by directing his browser to
a web site corresponding to authentication proxy 120.
After the user logs on, at step 210, a token corresponding
to a service is transmitted to the user. For example, authentication
proxy 120 may transmit a token corresponding to a Cloud service
after user 130 properly authenticates himself to authentication
proxy 120 (or logs on) at step 200. Additionally, tokens
corresponding to other Cloud services may also be transmitted to
user 130.
At step 220, the token corresponding to the service is
received from the user. For example, user 130, to access the
service, may direct his browser to a web site corresponding to the
service, e.g., the web site "geoplex.service.com." The browser
may then be redirected to the web address of data proxy 110 and
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
18
transmit the cookie containing the token corresponding to the
service to data proxy 110. The cookie, and hence the token, may
then be received at data proxy 110.
At step 240, a determination of whether the user is
authorized to receive the service is made. For example, data proxy
I 10 may extract and decrypt the token embedded in the received
cookie. Data proxy 110 may then determine whether the received
cookie authorizes the user to receive the requested service. For
example, data proxy 110 may extract the user identification
information in the token and compare it to the user identification
list contained in the ACT. If the user identification information
does not match any of the users in the ACT, then the user will not
be connected to the requested service. Further, data proxy 110
may extract the expiration time of the token and compare it to the
current time. If data proxy 110 determines that the token has
expired, then the user will not be connected to the requested
sermce.
If the user identification information in the received token
matches a user in the ACT and the token has not yet expired, then
the user may be connected to the requested service and may begin
using the requested service at step 250.
Figure 3 shows another embodiment of the present
invention. This embodiment illustrates the interaction of Alice, a
registered Cloud user, with the Gateway. At step 300, Alice
directs her browser to the authentication web site (for example, the
web site of the Gateway) that is managed by the authentication
proxy. For example, if the address of this web site is
"www.login.domain/login.html", then Alice may enter the
following command in her browser:
"https://www.login.domain/login.html". This will establish a
connection between Alice's browser and the authentication proxy
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
19
that uses the Secure Sockets Layer protocol for data security.
At step 305, the authentication proxy presents Alice with a
form that asks for her login name and, possibly a password.
At step 310, Alice provides her login name in the form.
She also types in the login password if she uses the password-
based authentication method. If she uses certificate-based
authentication, she does not need to type her password and this
field is left blank. Alice presses the "login" button on her browser
to submit the form to the authentication proxy.
At step 315, the authentication proxy verifies Alice's login
name. If the authentication proxy does not recognize the name
provided by Alice, it asks her to repeat step 3'10.
If Alice uses a password as a credential, then at step 320,
the authentication proxy verifies the validity of the password. If
the password provided by Alice is incorrect, the authentication
proxy asks Alice to repeat step 310. If Alice uses certificate-based
authentication, then step 320 is skipped and step 325 is executed.
At step 325, the authentication proxy sends Alice a web
page with a JavaScript program that contains a unique URL
reachable through a SSL protocol connection. The web page
contains Alice's login page for the new session. The
authentication proxy then closes the network connection with
Alice's browser.
At step 330, Alice receives the login page. The embedded
JavaScript program creates a new pop-up window in Alice's
browser. This window attempts to reconnect to the login page
using the unique URL provided by the authentication proxy.
At step 335, the authentication proxy waits for Alice to
reconnect to the authentication proxy through the unique URL.
At step 340, the authentication proxy accepts the new
connection if Alice provided a proper certificate when the SSL
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
protocol negotiation for the connection took place. Otherwise, the
new connection from Alice is rejected.
At step 345, the authentication protocol sends Alice a
stream of http protocol cookies, where each cookie corresponds to
5 a domain. The authentication proxy also sends a logout page to
the pop-up window on Alice's computer.
At step 350, Alice's browser receives the cookies. The
pop-up window displays the received logout button.
At step 360, the authentication proxy sends standby
messages to the pop-up window to maintain a persistent
connection. The authentication protocol also updates Alice's
cookies when they are about to expire.
At step 365, the pop-up window in Alice's browser is in
standby mode. Alice may discontinue her session at any time by
t5 pressing the logout button or by simply closing the pop-up
window. Alice uses the cookies to transparently authenticate
herself to the data proxy when establishing connections with
services in the Cloud.
Figure 4 shows another illustration of the embodiment of
20 the invention discussed in connection with Figure 3. Browser
state 410 shows the state of Alice's browser after Alice directs her
browser to the authentication web site (i.e., after step 300 of
Figure 3). Browser state 410 is essentially a form that Alice may
complete in order to logon to use services in the Cloud (i.e. to
login to the Gateway), which are located behind firewall 415.
Firewall 415 is implemented through authentication proxy 420
and data proxy 440.
After Alice properly authenticates herself, authentication
proxy 420 stores Alice's user identification in the list of active
users in ACT 435. Authentication proxy 420 also sends Alice a
page with a JavaScript program that contains a unique URL.
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
21
Furthermore, authentication proxy 420 closes its connection with
Alice's browser.
The JavaScript program received by Alice's browser
creates pop-up window 425 and causes Alice's browser to
reconnect to authentication proxy 420 through the unique URL.
While the connection to the unique URL is extant, Alice receives a
stream of cookies, for example, cookies 450, 455, 460 and 465,
from authentication proxy 420 containing tokens corresponding to
services in the Cloud. When Alice logouts of the Gateway by, for
l0 example, clicking on the logout box within pop-up window 425,
the stream of cookies sent by authentication proxy 420 is stopped.
While Alice remains logged on, she may access any Cloud service
by simply directing her browser to that service. For example, she
may direct her browser to the web site
"geoplex.domain.com/server." Her browser, detecting that the
requested web site corresponds to a Cloud service, connects to
data proxy 440 and sends cookie 450 corresponding to the
requested Cloud Service to data proxy 440. Data proxy 440 then
extracts the user identification information and other validity
information embedded in the cookie (or embedded in a token
embedded in the cookie). Other validity information, for example,
may include the token expiration date, or information on the
security grade over which the cookie is sent. For example, if
security grade information in the cookie specifies that the cookie is
to be transmitted over a connection secured through the SSL
protocol, but the cookie is transmitted to data proxy 440 through
an unsecured connection, then data proxy 440 may determine that
the token is invalid and refuse to connect Alice to the requested
service. Data proxy 440 may also check the user identification
information against the list of users stored in ACT 435. If no
match is established, then data proxy 435 may determine that the
CA 02400623 2002-08-15
WO 01/72009 PCT/USO1/07282
22
received token is invalid and refuse to connect Alice to the
requested service.
Finally, if data proxy 440 establishes that the received
token is valid, then data proxy 440 connects Alice's browser to
service 445. Alice will then see home page 430 of the requested
service on her screen.
Several of the embodiments above discuss a single-sign-on
mechanism for services, or more generally, resources, distributed
over the Internet. However, other embodiments are possible in
1o which the services or resources are distributed over a network
other than the Internet; for example, an intranet, or any other type
of network.
As described above, the various embodiments of the
present invention describe a single sign-on method and system for
accessing a plurality of services distributed over a network in
which authentication-related functionality is separated from the
services, and in which authentication need not be renegotiated for
access to a new service from the plurality of services during a
session. Additional benefits accruing from embodiments of the
invention include notification of the plurality of services when a
user has terminated a session, and the use of secure, short-lived
authentication tokens to verify a user's identity for subsequent
access to the plurality of services.
The present invention has been described in terms of
several embodiments solely for the purpose of illustration.
Persons skilled in the art will recognize from this description that
the invention is not limited to the embodiments described, but may
be practiced with modifications and alterations limited only by the
spirit and scope of the appended claims.
