A SINGLE SIGN-ON PROTOCOL FOR DISTRIBUTED WEB

APPLICATIONS BASED ON STANDARD INTERNET MECHANISMS

Julian Gantner

Andreas Geyer-Schulz

Anke Thede

Information Services and Electronic Markets

Universit

at Karlsruhe (TH), 76128 Karlsruhe, Germany

Keywords:

single sign-on, cookies, Web authentication, Web services, cross-domain

Abstract:

Growing e-commerce and personalized Web sites require users to set up many different personal accounts.

Personal data has to be entered many times and each user has to memorize different username and password

combinations. This reduces system security as users tend to either use passwords that are very easy to guess,

or they write them down, or they use the same password for many different accounts. It also increases the cost

of the administration of the user accounts.

We propose a protocol for a single sign-on system that allows users to visit multiple internet applications

having to login only once. The system is based on standard internet mechanisms. It is composed of different

servers that provide authentication and authorization services and is based on cookie technology. The system

is designed to be implemented in a heterogenous environment with independent and diverse service providers.

The communication between the servers is done via Web services. Additionally, plug-ins are available for

other protocols that allow for easy integration of existing authentication and authorization components. A

prototype system is operational at the Schroff Stiftungslehrstuhl Information Services and Electronic Markets.

1 INTRODUCTION

As more and more e-businesses and service providers

emerge on the internet and especially the World Wide

Web (WWW) the number of accounts and pass-

words a user has to handle and to remember increases

rapidly. Many providers require some type of identiﬁ-

cation and personal data to offer their services. Users

either tend to re-use the same account name and pass-

word for many different providers or write their cre-

dentials down and even carry them with them to have

them always available. Both methods increase the risk

that a malicious person might get access to personal

data and abuse them which might cause an important

damage to the user as well as the service provider. In

addition, in decentralized organisations multiple user

accounts increase IT administration and service costs.

Single sign-on (SSO) systems offer the possibility

to use only one account for a multitude of distributed

services (Shirey, 2000). The user logs into one of the

services and is then able to access resources of other

service providers without having to re-authenticate.

The set of services for which SSO can be provided

is called the SSO domain. SSO systems mainly stem

from two sources, namely distributed operating sys-

tems and telecommunication infrastructure. Many

different systems like Kerberos (Steiner et al., 1988)

or Radius (Metz, 1999) have been developed that of-

fer single sign-on for a special kind of environment.

SSO solutions for distributed Web applications are

special because they have to be based on standard in-

ternet mechanisms in order to be deployable. A multi-

tude of user clients (Web browsers) exists on the mar-

ket and there is no control over the choice of which

browser a user decides to use.

Besides the most often stated ﬁeld of e-commerce,

universities are a very promising domain of setting up

SSO environments (Murawski, 2000; Anchan and Pe-

gah, 2003). Nowadays extensive user proﬁles of stu-

dents, teachers, and researchers are kept digitally and

e-learning platforms and administrative systems re-

quire digital transmission of data. Universities not of-

fering their students an online time-table system and

access to lecture materials are even considered not to

be up-to-date. Universities still represent a very het-

erogeneous system where each institute has already

made its proper choice of platform and applications.

It is difﬁcult to impose common standards and proto-

cols on these independent entities. Thus, to success-

fully implement an SSO system in such an environ-

191

Thede A., Geyer-Schulz A. and Gantner J. (2004).

A SINGLE SIGN-ON PROTOCOL FOR DISTRIBUTED WEB APPLICATIONS BASED ON STANDARD INTERNET MECHANISMS.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 191-198

DOI: 10.5220/0001400201910198

 SciTePress

ment it must be able to integrate different types of ex-

isting systems and rely on standard mechanisms that

can easily be adopted by different kinds of proprietary

platforms.

We propose a single sign-on system for cross-

domain authentication based on standard internet

mechanisms that is designed in order to integrate vari-

ous types of existing user accounts and user databases

of service providers. The strength of our system lies

in the clear separation of user credentials and user

proﬁles from role assignment and access permission

information. The communication between the differ-

ent components of our system is based on standard-

ized protocols to which existing applications can eas-

ily be adapted. The choice of policies is left to the

service providers who can choose their level of trust

towards other system components.

In the following sections, we ﬁrst present our sys-

tem and describe its functionalities. After that we dis-

cuss the characteristics of our system and compare it

to other related systems for Web authentication.

2 PRESENTATION OF THE

SYSTEM

authentication

servers

application

servers

user

client

server

http

web service

authorization

server

domain 2

authorization

server

domain 1

user DB

domain 2

user DB

domain 1

internal

communication

protocols

internal

communication

protocols

(1) (2)

(3) (4)

Figure 1: Components of the SSO system and communica-

tion links, dashed link: not necessarily secure

The components and their communication protocols

are shown in ﬁg. 1. The system consists of one or

multiple application servers that contain the Web ap-

plications a user wants to access. The application

servers can reside in different domains. One or multi-

ple authentication servers handle the authentication of

the user. They can access one or more user databases

where one database contains the data for one speciﬁc

user domain. The authentication server is allowed

to query only the credentials needed to authenticate

the user (typically username and password, link (1)

in ﬁg. 1). The user database may contain additional

personal data about the user which are only accessi-

ble by the application servers in the corresponding do-

main (link (3)). For each user database domain there

is an authorization server that contains the role and ac-

cess information for each user. Two kinds of roles are

available: public roles are valid across domain bor-

ders and can be accessed by the authentication server

(link (2)). Local roles are restricted to the respec-

tive domain and may be queried only by application

servers of the corresponding domain (link (4)).

The cookie server is the last element of the system.

It contains information about the currently valid cook-

ies, the corresponding users, and their public roles.

The authentication servers may insert and delete en-

tries in the cookie server database whereas application

servers only perform entry look-ups. The description

of the role system is not within the scope of this paper.

The communication between the user client and

the application servers depends on the application re-

quirements, it may or may not be secured. The re-

maining communication channels have to be secured

as they carry sensitive data. The communication be-

tween the servers is mainly realized by the means

of Web services over an SSL (secure socket layer)

connection. Web services ease cross-domain access

as they only require a standard HTTP connection.

The communication with the user databases and the

authorization servers may be adapted to the speciﬁc

type of the underlying system (e.g. kerberos, secured

Web service). Different plug-ins in the authentication

servers offer customized communication. This allows

for integration of Web applications with already ex-

isting authentication and authorization schemes.

2.1 Single sign-on procedure

Now how does the system offer single sign-on for

multiple cross-domain applications? The procedure

is the following (see also ﬁg. 2, the letters refer to the

messages in the ﬁgure):

1. The user is not logged on to any application. He

sends a request for a service to application server

app1 (a).

2. app1 cannot identify the user as no application

server cookie is sent with the request. It there-

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

192

authentication

server auth1

user

client

server

user data-

base udb1

a) request service

authorization

server

application

server app1

c) redirect to auth1 (app seq, source url)

c) set app cookie (app seq)

d) request login (app seq, source url)

e) login page

f) post username, domain, password

g) check password (username, password)

h) password ok

i) get public roles (username)

j) public roles

l) new entry (username, domain, app seq, auth seq, roles, udb1)

m) confirmation page & redirect to source url

m) set auth cookie (auth seq, auth1)

k) generate

new auth seq

b) generate

new app seq

n) request service (app cookie)

o) get username and roles (app seq)

p) username and roles

s) service

q) get local roles, access permissions (username, service)

r) local roles, access permissions

Figure 2: Sequence diagramm of SSO procedure at ﬁrst login

fore sends a redirection to one of the authentica-

tion servers, say authentication server auth1. The

redirection contains the URL of the originally re-

quested application page and a randomly generated

sequence of characters, the application sequence.

The application sequence is also included in the ap-

plication cookie that is sent back to the user along

with the redirect request (b, c).

3. auth1 requests the credentials from the user con-

sisting of a username, a password, and a domain

(d, e). The credentials are transmitted over a secure

connection (f).

4. auth1 contacts the user database corresponding to

the given domain to verify the correctness of the

credentials (g). Once the veriﬁcation succeeds (h)

auth1 retrieves the public role information for this

user from the domain’s authorization server. The

roles are matched by means of the user name (i, j).

5. auth1 randomly generates another sequence of

characters, the authentication sequence (k). The se-

quences have to be long enough such that the prob-

ability of a malicious user reproducing a valid se-

quence by random trial is sufﬁciently small. The

two sequences, the user name and domain, the list

of public roles, and the name of the user database

are transmitted to the cookie server who saves the

information in its database (l).

6. An authentication cookie containing the authenti-

cation sequence and the identiﬁcation of auth1 is

created and transmitted back to the user along with

a login conﬁrmation page. The page displays for

some seconds and then redirects back to the origi-

nating application URL (m).

7. The user now has two cookies set: the application

cookie and the authentication cookie. Upon the fol-

lowing request to app1 the application cookie is

transmitted (n). app1 extracts the application se-

quence from the cookie and requests the user infor-

A SINGLE SIGN-ON PROTOCOL FOR DISTRIBUTED WEB APPLICATIONS BASED ON STANDARD INTERNET

MECHANISMS

193

authentication

server auth1

user

client

server

user data-

base udb1

a) request service

authorization

server

application

server app2

c) redirect to auth1 (app seq2, source url)

c) set app cookie (app seq2)

d) request login (app seq2, source url)

e) find user (auth seq, app seq2)

h) confirmation page, redirect to source url

b) generate

new app seq

i) request service (app cookie)

j) get username and roles (app seq2)

g) entry ok

n) service

d) send auth cookie

f) new entry(username, domain,

app seq2, auth seq, roles, udb1)

k) username and roles

l) get local roles, access permissions (username, service)

m) local roles, access permissions

Figure 3: Sequence diagramm of SSO procedure at cross-domain service request

mation from the cookie server (o).

8. The cookie server ﬁnds the existing entry contain-

ing the application sequence in its database and

transmits the user name and his public roles to app1

(p). app1 may now look up local roles and access

rights in the domain’s authorization server and may

deliver the requested service (q – s).

The user can now easily access services from all

application servers in the domain of app1 as the cor-

responding application cookie is always included in

the requests. If a user now requests a service from a

server residing in a different domain (say app2) the

application cookie is not sent along with the request

and the user is not recognized as logged in. The fol-

lowing steps are then performed (see ﬁg. 3 and corre-

sponding message numbering):

1. The user accesses app2 without an application

cookie (a). The server generates an application se-

quence (b) and redirects the user to auth1, setting

the second application cookie (c).

2. auth1 extracts the authentication sequence from the

transmitted cookie (d) and requests the associated

user information from the cookie server. The re-

quest also includes the new application sequence

(e).

3. The cookie server ﬁnds the user associated with the

authentication sequence and adds another entry in

its database differing from the ﬁrst only in the new

application sequence (f, g).

4. auth1 redirects the user who has now three cookies

set back to the originating URL of app2 (h). app2

can now identify the user as described in the last

two steps of the previous procedure (i – n).

In this scenario app2 uses the same authentication

server (auth1)asapp1. But the system allows for sev-

eral authentication servers in one SSO domain and

each application server may choose which authen-

tication server to use. For different authentication

servers to recognize the user as logged in it is nec-

essary that they be able to have a valid authentication

cookie transmitted. As cookies (Kristol and Montulli,

1997) may not be set on behalf of other servers the

following work-around is deployed. Each authentica-

tion server maintains a list of the other known authen-

tication servers. After the ﬁrst successful login the

conﬁrmation page displayed to the user contains for

each other authentication server an HTML image tag

including the authentication sequence and the name

of auth1. The requests sent to the other servers al-

low them to set an own authentication cookie with

the same authentication sequence. In reply to each

request each authentication server delivers a transpar-

ent pixel image. Now the user can be recognized as

logged in by all other authentication servers, as well.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

194

However, steps 7 and 8 may increase the network

trafﬁc considerably as a request is sent to the cookie

server upon each service request to an application

server by a user. In order to minimize the network

trafﬁc and to increase the performance of the system

the application server may locally cache the associa-

tion of the application sequence to the username and

roles. This design decision needs to be carefully con-

sidered with respect to the global logout procedure

and its implications are discussed in the following

section.

2.2 Global logout

When the user logs out of one of the applications with

which he is logged in (and of which he consequently

possesses an application cookie) the logout has to be

propagated to all other applications in the SSO do-

main, as well. Upon logging out the user is redi-

rected to the authentication server. The authentication

server sends a request to the cookie server to delete

all entries containing the authentication sequence in-

cluded in the authentication cookie. The authentica-

tion server sends a logout conﬁrmation page to the

user and deletes his authentication cookie. To delete

the authentication cookies of all other authentication

servers with which the user is currently registered the

conﬁrmation page contains again transparent images

pointing to logout links of the other servers. Upon

sending the images the other authentication cookies

can be deleted, as well. If the user now accesses an

application the application server will fail to ﬁnd the

corresponding entry in the cookie server and conse-

quently can delete the application cookie. This is the

standard case as described in the previous section.

If the application server uses caching to minimize

network trafﬁc the following two options of cache in-

validation are possible:

1. The cache entries are only valid for a limited time

and the application server checks the entries with

the cookie server on cache expiration (variant 1).

2. The logout message is propagated to the applica-

tion servers. This possibility is also employed in a

similar manner in Microsoft’s Passport SSO proto-

col (Microsoft Corporation, 2004b). It consists in

keeping track of all applications the user is logged

in with in the current session and to include trans-

parent image requests for cookie deletion in the lo-

gout conﬁrmation page, as well. The cookie server

could easily keep track of the applications as a sep-

arate entry for each application sequence already

exists. This would allow the application servers

to locally cache user information and avoid subse-

quent requests to the cookie server while still vali-

dating the global logout without delay (variant 2).

2.3 Public roles

Each user can be associated with several public and

private roles. Public roles are valid across all applica-

tions in the SSO domain whereas private roles are lo-

cal to an application or domain. A user’s public roles

are contained in the cookie server entries and can be

read by all applications the user accesses. Each ap-

plication may decide on its own whether to trust the

validity of a public role.

Public roles can be used to identify users and user

groups and their corresponding access rights across

different applications. For example, if a student

worker logs in at the site of the department where

he works he may be assigned the private role “stu-

dent worker” and the public role “student at faculty of

mathematics”. If he subsequently accesses the Web

page of the faculty of mathematics he is recognized as

a valid student by means of the public role and may

be granted access to lecture material without the need

to re-authenticate.

Public roles could also be used to identify single

users across different domains without the need to ex-

change user names or to issue globally unique user

identiﬁers. Each user may be assigned a public role

corresponding e.g. to his matriculation number. With

this information each student can be identiﬁed by all

university applications whose user databases contain

the matriculation numbers of their users.

2.4 Failure of servers

For a single sign-on system it is important to note

which of the participating servers constitute single

points of failure. Unavailablilty of a server that pro-

vides necessary information to perform login func-

tionality means that all services that require login and

access control become unusable. It is therefore de-

sirable to have different servers that are able to pro-

vide the same functionality. A slow authentication

system due to increased server load is still preferable

to a completely non-functional system.

In the system described in this paper the authen-

tication server does not constitute a single point of

failure. Many different authentication servers may be

set up and as long as one of the authentication servers

that an application server knows is functional the lo-

gin can be performed. If an authentication server is

temporarily not available this may result in a broken

image tag displayed on the login conﬁrmation page

after a timeout but the login is still completed.

If a user database or an authorization server breaks

down applications in the corresponding domain can-

not be accessed but the other domains are not af-

fected. In the current implementation only the cookie

server as the only central component constitutes a

single point of failure. By replication of the cookie

A SINGLE SIGN-ON PROTOCOL FOR DISTRIBUTED WEB APPLICATIONS BASED ON STANDARD INTERNET

MECHANISMS

195

server’s database and network interfaces this risk can

be avoided, respectively reduced to a minimum. Mir-

ror cookie servers do not increase the vulnerability of

the overall system as the cookie server does not con-

tain extremely sensitive data (like credentials, credit

card information etc.). The sequences contained in

the cookie server are only valid for a single session.

To avoid replay of valid sequences in case that a ma-

licious person gets access to the contents of a cookie

server these could be stored encrypted either in the

cookies or in the cookie server.

2.5 Scalability

For a single sign-on system to be practically relevant

scalability is an important factor. An SSO system

must be able to handle a large number of users, ac-

counts, and applications without being considerably

slowed down.

Looking at our solution, what does a large number

of accounts and users imply?

• Accounts and their authorization information have

to be stored in the user databases and authoriza-

tion servers. As the system is already designed to

have separate servers for each domain application

speciﬁc scalability is not affected by the SSO pro-

cedure.

• The bottleneck of the current application is the

central cookie server. The size complexity of the

database is of the order number of currently logged

in users · number of currently used applications.

The number of concurrent users usually is only a

small fraction of the total users, the same is true

for the applications so that currently available data

base systems should be able to accomodate cookie

data both with respect to size and response time.

The requests to the cookie server are all of the

same structure such that efﬁcient indexing tech-

niques can be deployed. Tests with a single LDAP

server containing about 25 million entries showed

no performance degradation.

• Another important point is the amount of network

trafﬁc to and from the cookie server. For each lo-

gin to a new application two requests to the cookie

server are necessary (see ﬁg. 2 and 3). The global

logout requires one request for each authentication

server the user logged in with. However, the most

important amount of requests is generated at each

access to an application service as the application

server veriﬁes the validity of the transmitted ap-

plication cookie. These requests can be reduced

or even avoided using the caching schemes as de-

scribed in sec. 2.2 such that only a manageable

amount of network trafﬁc is left. Currently, the

variant 1 described in sec. 2.2 is implemented.

2.6 The Role of Cookies for SSO

Building essential infrastructures on cookies has

some important drawbacks. Many internet users have

privacy concerns and do not want to use cookies,

they can simply disable the cookie mechanism locally

within their internet browser. There are also some se-

curity issues as cookies can on the one hand be mod-

iﬁed by the user and on the other hand they may pos-

sibly be read or replayed by a third party. For a dis-

cussion on cookie security see e.g. (Samar, 1999).

Nevertheless, any SSO solution requires some sort

of state management and user identiﬁcation that can-

not be provided by the stateless HTTP. Several possi-

bilities exist to maintain information across multiple

HTTP requests. An often used method is to include

session information in the URLs, either as part of the

query string or as an integral part of the URL itself.

In contrast to cookies this does not require any data

to be stored in ﬁles on the user’s computer. This solu-

tion works very well for session management in one

domain but it poses some problems when applied to

cross-domain services. Each web server in an SSO

domain would have to take care of including applica-

tion and authentication sequences only in the URLs of

the corresponding server. Otherwise sequences would

risk to be exposed to third party websites who would

be able to replay this information. Second, in our sce-

nario web servers that issue redirect requests would

have to have knowledge of the sequences that corre-

spond to the redirect target server. In ﬁg. 3, consider

message (c). app2 would have to include the authenti-

cation sequence of auth1 in the redirect request. This

requires additional transfer of sequence information

over the network which means additional exposition

of sensitive information to possible attackers. Thus

we can see that replacing cookies with URL encoded

sequences introduces additional security threats.

Keeping track of session information by using the

user’s IP address generally poses problems because of

the use of proxy servers and network address transla-

tions, as well as the use of public terminals by many

different users. Identiﬁcation of the user through

HTTP authentication also does not work for cross-

domain scenarios. Other solutions require the user

to install additional, specialized software and are no

longer based on standard Internet mechanisms.

In general, privacy and single sign-on services are

contradictory requirements that are difﬁcult to com-

bine. To minimize scepticism it is important to pro-

vide the user detailed information about what is stored

in the cookies and what they are used for. Further-

more, an SSO solution based on cookies can still offer

privacy concerned users alternative login mechanisms

without cookies if they are willing to renounce single

sign-on and log on to every service separately. In the

current version, however, this is not yet implemented.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

196

3 RELATED SYSTEMS

Many different solutions have been proposed in recent

years for offering single sign-on in different environ-

ments (de Laat et al., 2000; Volchkov, 2001). Many of

them are not transferable to a heterogeneous and dis-

tributed Web environment as they require a central-

ized structure of the involved components and com-

mon protocols. Other systems work with clients that

are required to have additional functionality (Pﬁtz-

mann and Waidner, 2003) which we do not consider

to be a realizable approach in the World Wide Web

environment. In the following, we give an overview

over the three solutions known to us regarding single

sign-on for Web applications and compare the sys-

tems with our solution.

Microsoft’s .NET Passport system (Microsoft Cor-

poration, 2004b; Kormann and Rubin, 2000) is the

largest functional single sign-on solution with 200

million accounts performing approximately 1350 au-

thentication requests per second (March 13, 2003,

(Microsoft Corporation, 2004a)). The system consists

of a central Passport server that contains and man-

ages all user accounts and corresponding user infor-

mation and performs the authentication. Each user

has a unique identiﬁer. If a user has logged on to

Passport from a service provider’s site he can sub-

sequently visit sites of other businesses adhering to

Passport and is recognized by his unique identiﬁer.

The Passport server as well as the service providers

set transient (session-only) or persistent cookies to

recognize the user as already logged in. The cook-

ies contain credential information about the user. A

global logout from all Passport accounts is realized

by including logout requests to all services the user is

currently logged in with (and of which he possesses

valid cookies) in HTML image tags.

The main difference between Passport and our so-

lution is Passport’s central authentication and user

database server. This server is a single point of failure,

if the service breaks down all businesses using Pass-

port are unavailable to the users. It is not stated which

measures are taken to offer scalability and backup

servers. Possible dangers of replicated databases are

discussed in (Kormann and Rubin, 2000). Our solu-

tion works with different, distributed authentication

servers and integrates multiple, local user databases

without requiring a separate, unique identiﬁer. Iden-

tiﬁcation across multiple domains may be realized

at different levels by the means of public roles. No

credential information is stored in local user cookies

which may potentially be modiﬁed by the user him-

self and is not well protected against access from in-

truders.

The Liberty Alliance Project (Liberty Alliance

Project, 2003) was formed in September 2001 by an

association of several major companies in order to

specify open standards for federated network iden-

tity management. The architecture (Liberty Alliance

Project, 2003) allows for each service provider to

maintain its own user database and user identities. A

user who wants to use single sign-on between service

providers with different identities may select to fed-

erate these identities between the service providers

who are now able to match the foreign identity to their

own. Without federation the user has to separately log

into each service provider. The decision of whether to

trust a user logged in with a different, federated iden-

tity remains the service provider’s local policy. Iden-

tity providers take the role of the authentication server

and the cookie server in our scenario, they use cookies

to maintain a user’s login state.

Like our solution, the Liberty architecture allows

for integration of existing user databases and accounts

of different service providers. The choice of whether

to trust a federated identity can be made locally by

each service provider, like it is the case with the pub-

lic roles introduced in our system. The server ar-

chitecture is nevertheless different. Liberty does not

state whether SSO is possible across multiple identity

providers and does not distinguish between authenti-

cation server and cookie server. Having the possibil-

ity to choose a nearby authentication server reduces

the route length over which passwords and other cre-

dential information have to be carried to a minimum

whereas no such sensitive data has to be transferred to

and from the cookie server. Data have to be transmit-

ted between the cookie and the authentication server

only upon an initial service provider login. It is there-

fore useful and improves the security of the system to

introduce this ﬂexibility without having an important

impact on the overall system performance.

Samar (Samar, 1999) proposes different proto-

cols for cookie-based single sign-on. For cross-

domain authentication, he introduces two centralized

servers, a cookie server and a login server. The login

server contains the authentication information about

all users in the SSO domain and recognizes signed-in

users by means of a login server cookie. The cookie

server contains information about the different Web

application cookies. Samar does not give detailed in-

formation about the possibility of a global logout in

this scenario.

Samar’s approach does not offer the integration of

decentralized user databases and introduces two sin-

gle points of failure, namely the login and the cookie

server. The approach is similar to Microsoft’s Pass-

port except that Passport integrates the two different

server types in one central server. Authorization is

done locally at the service providers.

A SINGLE SIGN-ON PROTOCOL FOR DISTRIBUTED WEB APPLICATIONS BASED ON STANDARD INTERNET

MECHANISMS

197

4 CONCLUSION

In this paper we propose a single sign-on system ar-

chitecture based on standard HTTP mechanisms for

distributed, cross-domain Web applications. The sys-

tem allows for integration of distributed, proprietary

user databases and authorization servers. User ac-

counts need neither to be centralized nor to be expli-

citly exposed to other service providers in order to

provide SSO services. Public roles offer a ﬂexi-

ble mechanism to transport user information across

different domains while leaving the ﬁnal decision

of whether to accept public roles to the single ser-

vice providers. The system works with multiple,

cross-domain authentication servers and a centralized

cookie server. Different possibilities for implement-

ing a global logout are proposed. We compared the

system to other, well-known propositions and solu-

tions for offering cross-domain single sign-on in a

world wide Web environment and discussed similar-

ities and differences between the systems as well as

advantages and drawbacks.

The prototype system is already functional over

different domains at the department Information Ser-

vices and Electronic Markets. To test the system

please visit http://demo.em.uni-karlsruhe.de/sso/ and

http://sso.itloesungen.com/, log into one of them as

indicated on the login screen, and test the system

by visiting the other. First experiences with the sys-

tem revealed no major difﬁculties concerning usabil-

ity and the initial user reaction towards the single

sign-on service was very positive.

The next step is to integrate other domains of uni-

versity institutes and departments, afﬁliated compa-

nies and student organisations to test the system at

a larger scale and to identify possible improvements

especially concerning the adaption of proprietary sys-

tems into the SSO environment. Further research will

be directed towards the analysis of various attack sce-

narios and on role contracting models.

REFERENCES

Anchan, D. and Pegah, M. (2003). Regaining single sign-on

taming the beast. In Proceedings of the 31st annual

ACM SIGUCCS conference on user services, pages

166 – 171.

de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and

Spence, D. (2000). RFC 2903: Generic AAA Archi-

tecture. Network Working Group.

Kormann, D. P. and Rubin, A. D. (2000). Risks of the

passport single signon protocol. Computer Networks,

33:51–58.

Kristol, D. and Montulli, L. (1997). HTTP State Man-

agement Mechanism. Network Working Group RFC

2109.

Liberty Alliance Project (2003). Liberty Architecture

Overview v1.1. Technical report, Liberty Alliance

Project. http://www.projectliberty.org.

Metz, C. (1999). AAA protocols: Authentication, autho-

rization and accounting for the internet. IEEE Internet

Computing, 3(6):75–79.

Microsoft Corporation (2004a). Microsoft .NET Pass-

port for Businesses. http://www.microsoft.com/-

net/passport/services/business.asp, accessed Feb 25,

2004.

Microsoft Corporation (2004b). .NET Passport Review

Guide. Technical report. http://www.microsoft.com/.

Murawski, R. (2000). Centralized directory services and

accounts management project. In Proceedings of the

28th annual ACM SIGUCCS conference on User ser-

vices: Building the future, pages 198 – 201.

Pﬁtzmann, B. and Waidner, M. (2003). Analysis of lib-

erty single sign-on with enabled clients. IEEE Internet

Computing, 7(6):38–44.

Samar, V. (1999). Single sign-on using cookies for web ap-

plications. In Enabling Technologies: Infrastructure

for Collaborative Enterprises, pages 158–163. IEEE.

Shirey, R. (2000). Internet security glossary. Network

Working Group RFC 2828.

Steiner, J. G., Neumann, B. C., and Schiller, J. I. (1988).

Kerberos: An authentication service for open network

systems. In Usenix Conference Proceedings, pages

191 – 202.

Volchkov, A. (2001). Revisiting single sign-on: A prag-

matic approach in a new context. IT Professional,

3(1):39–45.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

198