FINAL Dissertation Cervicek

8/2/2019 FINAL Dissertation Cervicek

http://slidepdf.com/reader/full/final-dissertation-cervicek 1/95

Master Dissertation

Authentication in web applications

July 2009

Supervisor: Dr. Tatiana Kalganova

Course: MSc Distributed Computing Systems Engineering

Student Name: Patrick Cervicek

Student ID: 0733018

A dissertation submitted in partial fulfilment of the requirements for the degree of Master

of Science




Declaration:

I have read and I understand the dissertation guidelines on plagiarism and cheating, and

I certify that this submission fully complies with these guidelines.

Student’s name: Patrick Cervicek

Student’s signature:



CONTENTS

Contents

1 Introduction 5

2 Components for Identity Management 7

2.1 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Central Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 User-centric Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 IP based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Password Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 X.509 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5 HTTP Basic Access Authentication . . . . . . . . . . . . . . . . . . 17

2.2.6 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.7 Back-ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.8 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Analysis and Implementation 32

3.1 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.3 Integration and Implementation . . . . . . . . . . . . . . . . . . . . 39

3.1.4 Attribute Exchange and Data Privacy . . . . . . . . . . . . . . . . 41

3.1.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3



CONTENTS

3.2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.4 Integration and Implementation . . . . . . . . . . . . . . . . . . . . 56

3.2.5 Attribute Exchange and Data Privacy . . . . . . . . . . . . . . . . 61

3.2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.7 Clustering and High Availability . . . . . . . . . . . . . . . . . . . . 63

3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Conclusions and Outlook 67

5 Acknowledgments 70

6 References 71

4



1 Introduction

1 Introduction

Web users today are faced with a lot of different web applications. To use these web

applications, the users have to authenticate themselves by entering a userID and password

(figure 1).

Figure 1: User authenticates at web server

Usually, this has several disadvantages:

• Consistency: If a user changes a password, it is still unchanged on all other web

applications.

• Ease of use: Users have to remember all passwords on each system. If they do not,passwords have to be reset.

• Uniqueness of userID: The preferred userID could be already used by another user,

which doubles the problem of forgotten passwords.

• Multiple authentication: Even if a user uses the same ID and password, he still has

to authenticate to each web application by typing in his userID and password.

This master dissertation shows, how the user can use the same userID/password for all

applications (Single User Login)1. Furthermore, techniques are discussed how the user

can log in only once to a server and being recognised by other applications laying on

other servers without having to log in again (Single sign-on)2. This dissertation gives an

overview of the necessary architecture and summarizes some eligible techniques to reach

these two goals.

1SUL2SSO

5



1 Introduction

The two Web SSO frameworks OpenID and Shibboleth have been chosen to be analysed

in more detail. The criteria for the analysis were:

• popularity: Is this framework widespread and can be used at many 3rd-party sites?

• architecture: Which roles exist in this setup?

• security: How secure is the framework in matters of integrity, availability, privacy

and authenticity?

• data privacy: How anonymous is the user on a 3rd-party resource?

• end user experience in the browser: What is the look and feel for the user?

• developers and deployers: What needs to be changed to allow single sign-on?

After the analyses the deliverables of this master dissertation should be:

• Clear understanding of SUL and Web SSO

• Example for a single user login setup with a database

• Two Web SSO implementations with OpenID and Shibboleth

• Comparison between OpenID and Shibboleth

• Advice under which circumstances OpenID or Shibboleth should be used

The tests will be implemented on virtual servers, which will speed up the tests as there

is no special hardware needed. Apache[apad] will be used as web server. PHP[phpb]

will be used for small scripting tests. To analyse HTTP protocol flows Firebug[fira]

and HttpFox[htta] will be used. Firebug/HttpFox are Firefox plugins and are originally

designed to inspect the content of a website but they are useful to see all HTTP request

and response headers.

6



2 Components for Identity Management

2 Components for Identity Management

System operators want to ensure that only valid users can log in to a resource3. At first

users need to be authenticated . In the easiest case, the user needs to provide a userID

and a password. The sent userID and password are compared with the data stored on

the resource (figure 2).

Figure 2: User database stored on web application server

Upon this authentication, the users can be given access to a resource - the user is then

authorized to access it. Depending on the service, the user could be charged for resources

he used e.g. on a video-on-demand website, this could be downloading a video. The

accounting ensures with a log, that the user pays for those (and only for those) movies he

downloaded.

The more different web applications the user uses, the more accounts need to be created as

each web application works independent from the others. This can be seen in companies

with old legacy applications, where no identity management is properly set up (figure 3).

Each application has its own local data store which needs to be maintained by system

operators and users. These ’silos’ are simple to set up as it ’just works’. The problemscome later, when there are more applications. Another example is the internet with its

huge variety of web applications. This causes problems for the user (chapter 1).

System operators have to ensure that only eligible users may have an account to a resource.

When a user is no longer employed within his organisation, this account needs to be locked.

When this user has decentralized accounts on different resources, it’s hard to lock them

as all resources have to be manually browsed for this account. This increases the price of

managing user identities.

3here: web application

7



2.1 Identity Management

Figure 3: Independent local user databases


Each person in a homogeneous IT infrastructure need a personal userID. Identity manage-

ment covers the management of the identity life cycle of these userIDs: Adding a userID,

moving a userID, change (for example, reset a password) and delete a userID (e.g. the

user is not longer employed).

The responsibility to manage the user accounts can lie at the organisation the user belongs

to or can lie at other places (figure 4). A user database can be stored at a central location,

where the data is administered within an organisation. Only the organisation itself is

responsible for the user administration. There is often a central user directory stored on

a SQL4- or a LDAP5 server, but it could also be a big text file. [JRGA02] [TAH03] [apac]

In a very simple setup, the web applications are not connected to this central user direc-

tory. Each user is created individually on each web application. Provisioning (chapter

2.1.1) or the connection to a central user directory (chapter 2.1.2) can improve that sit-

uation.

4Structured Query Language5Lightweight Directory Access Protocol

8




The user database can also be distributed where the user administration is delegated. The

accounts can be administrated by an organisation participating in a federation (chapter

2.1.3) or user-centric (chapter 2.1.4) by the user himself .

Figure 4: Responsibilities of user administration

2.1.1 Provisioning

Legacy applications do not allow the use of a central user database, therefore the localdatabase needs to be provisioned (figure 5). There are commercial solutions which allow

with help of a ’synchronisation application’ to take the userID/password from a central

place and provision the local database of each web application. The userID on the resource

doesn’t necessarily be the same as the userID in the central user database. This can

be accomplished with a ’user mapping’. Some ’synchronisation applications’ can also

reconcile accounts from this store back to the central user database.

2.1.2 Central Directory

Centralized user accounts decrease the complexity for users and system operators. The

userID and password (also know as ’user credentials’) stay the same on the whole domain

(figure 6). This is called ’Single User Login’.

9




Figure 5: Local user databases provisioned by corporate user database

Figure 6: Single User Login: Web applications use corporate user database

10




2.1.3 Federation

There is often a case where an organisation wants to allow other organisations to use its

resources without creating a new account for them. If they would do so, the users would

have to create new accounts with all known problems (chapter 1).

Example: A university wants to allow all members of other universities to user their e-

Learning application. To accomplish that, this university would join a federation with

other universities (figure 7). In a federation, the user accounts are managed locally at the

organisation, but the authorisation takes place at the resources’ site. This means that

a user from organisation A may use resources of organisation B. Each university would

have to provide a so-called ’Identity Provider’, which handles the authentication for their

own users, but the authorisation is done at the resource of the other federation members.

Figure 7: Federation

The federation of the Switch-AAI6 [swib] accomplishes this by dividing authentication

and authorisation among each other (figure 8). Without AAI, a member of university A

would need an account at university B to log in to an e-Learning application at university

B. With AAI, the application of university B asks university A7 and trusts, that the

response ”This user is a member of university A” is correct and allows (authorises) the6Authentication and Authorization Infrastructure7more exactly: its identity provider

11



2.2 Authentication and Authorization

access to e-Learning. The user only needs one userID and password and is logged in

(authenticated ) to AAI. Each resource in the AAI federation now trusts the identity and

the role of this user. AAI also enables single sign-on (chapter 2.2.1). There is one special

case where one organisation wants to ensure that only members affiliated to them can use

the resources. This is called local federation . This is mainly used for intranet applications

which should be SSO-enabled, but not being used by other organisations.

Shibboleth is an implementation used by many federations [shib].

Figure 8: Authentication separated from authorisation [swic]

2.1.4 User-centric Identity

With a user-centric identity, the account of a user is not administrated by an organisation.

It is the user who controls his identity and his attributes.


How can a user prove his identity and log in to a server? There are three categories of

authentication:

”Something that one knows” user name, password, PIN”Something that one owns” Smartcard, SecureID, IP”Something that is a personal characteristic” Finger print, voice (recognition)

When two methods from the same category are used, this is called 2-Means authenti-

cation. When two methods from different categories are used, this is called 2-Factor

12




authentication. This is also know as ”strong authentication” and should be used in confi-

dential areas. HTTP offers several mechanisms to accomplish authentication and session

management which will be discussed in this chapter.

2.2.1 Single sign-on

Single sign-on is a method which helps users to log in only once to a single sign-on domain .

All resources within this domain will not ask again for a userID and a password. The basic

architecture of a single sign-on method consists of an authentication server and at least

one resource (figure 9). The user needs to log in once to the authentication server. The

authentication server issues a so-called ’ticket’, in which the authentication server assures

that the ticket owner is a valid user of the domain. This ticket could also be a cookie

(chapter 2.2.8). When the user shows this ticket to a resource within this domain, the

resource accepts this ticket and allows the user to use the resource. This can be compared

with an identity card issued by the government. Single sign-on solves the necessity of

sending a password to each resource. Only the authentication server needs to know the

credentials.A user of one domain can also use the resources of another domain, when a cross realm

trust has been established before. Cross realm trusts often result in a federation (chapter

2.1.3), as in a federation each participating domain only has to trust one central site

which introduces new domains to existing domains.

A well-known authentication protocol which provides also single sign-on capabilities is

Kerberos [ker]. Microsoft Windows uses Kerberos to allow its users to utilise all services

within the same domain. This takes place on the operating system layer. In this disser-

tation the focus lies on Web SSO which takes place in the user browser, as we want to

get the same SSO behaviour for non-Windows-users. For Web SSO this dissertation will

focus on OpenID and Shibboleth as these are free standards. More information about

Single sign-on can be obtained in [PM03].

13




Figure 9: Single sign-on

2.2.2 IP based access

Web servers, which should only be accessible within an organisation, can be protected

with a firewall between internet and organisation. The web server can also protect itself

with an ACL8. The user is authorized to access the web server with its source IP address.

He doesn’t have to authenticate anywhere.

This solution is fast deployable and could be a good choice for intranet pages or relay

mail servers. IP addresses are spoofable and are therefore not an appropriate means of

user authentication. As soon as guest computers are in the same IP range, IP based

access should not be used. When the users are mobile, they would need a VPN9 solution

to get an internal IP. This would not scale in an environment, where the users are in

different networks. However, a combination of IP based ACL and authentication by

using userID and password can double security. A simple example is shown in figure 10:

With some small changes (listing 1), only users within the Brunel University network are

allowed to access this web server . Further examples can be found online in the apache

8Access Control List (used in Firewalls)9Virtual Private Network

14




documentation[apaa].

Figure 10: IP based access to a web server

# IP b as ed a c c es s f o r h t t p : / / h o s t / s e c u r e u r l

<L oc at io n / s e c u r e u r l />

Order Deny , Allow # b y d e f a u l t : Deny e v e ry b o d y

Deny f ro m a l l

# A l l ow a l l c l i e n t s i n . b r u n e l . a c . uk domain

Allow fro m . bru nel . a c . uk

# in c as e h o st i s no t i n DNS, t he n u se IP r ang e o f B ru ne l U n iv e r si t y

A ll ow f ro m 1 3 4 . 8 3

<

/ Lo ca tio n>

Listing 1: Apache configuration for IP based access

2.2.3 Password Manager

All popular browsers are equipped with a password manager, which can remember pass-

words and fill them into forms. The passwords can be encrypted with a master password.

There are also external password managers like keepass [kee]. A password manager could

work for websites which are not within a federation or can not be attached to a web SSO

framework. The drawbacks: The user is always dependent on the same browser. A pass-

word manager can therefore only be used on the same machine. Otherwise a notebook or

a portable browser [firb] on a USB stick is needed. When the portable device would get

lost, all passwords should be seen as compromised. A strong hard disk encryption could

protect data loss. There are also security issues present in browser password management

e.g. the destination where passwords are sent is not checked [bro] which aids phising.

15




2.2.4 X.509 Certificates

SSL/TLS enables not only server but also client authentication with X509 certificates.

”A single sign-on service is not needed in SSL, as SSL is really a peer to peer

protocol, however an application that uses SSL can implement some kind of

single sign-on mechanism.” [ACGV98]

Instead of manually logging in to a web server, users could log in by simply showing a

X.509 Certificate to the web server. If a PKI10 is set up, this could be a form of SSO. A

central authority would have to issue a X.509 certificate to all users. The public key of

this Certificate Authority would have to be deployed on all web servers, so they can trust

the users. Each web server would then accept these user certificates.

A simple example is shown in listing 2. The first time the user tries to log in to a

SSL client authentication enabled web server the user would get a pop up to choose an

appropriate certificate (figure 11). Further examples can be found online in the Apache

documentation[apab].

# by d e f a u l t : no c l i e n t a u t h e nt i c a ti o n ne ed ed

S S L V e r i f y C l i e n t n on e

# P ub l ic Key o f C e r t i f i c a t e A ut ho ri ty

S S L C A C e r t i f i c a t e F i l e / e t c / a p a ch e2 / c a . c r t

<L oc at io n / s e c u r e u r l />

# r e q u ir e c l i e n t a u t h e nt i c a ti o n f o r h t t p s : // h o st / s e c u r e u r l

S S L Ve r i f yC l i e nt r e q u i r e

SSLVerifyDepth 1

</ Lo ca tio n>

Listing 2: Apache configuration for SSL client authentication

On all participating web servers the public key of the certificate authority would have

to be installed. The user is always dependent on the same browser with the imported

10Public key infrastructure

16




Figure 11: Certificate User Identification Request

certificate. SSL certificates can therefore be only used on the same machine. Otherwise, a

notebook or a portable browser with the imported certificates is needed. When a user SSL

certificate is lost, it needs to be revoked over a certificate revoke list . Using certificates is

a strong authentication mechanism and can harden a password-based authentication.

2.2.5 HTTP Basic Access Authentication

HTTP has a built-in method called Basic Access Authentication to allow a web browser

to authenticate with a user name and password at a web server [httb]. When a web server

requires authentication, it asks the browser with a 401 Authorization Required status

code to authenticate. The web browser asks the user for a user name and a password

(figure 12). It concatenates the user name, a colon and the password. This string will be

Base64 encoded and transmitted to the web server (figure 13). The web server decodes

this string and checks user name and password with the back-end. Usually the passwords

in the back-end are hashed. The web server needs to hash the received password and

compare it with the hash in the back-end. Upon successfull authentication, the browser

sends on all subsequent HTTP request this authorisation header. This could be seen as

a kind of session management.

The web application itself does not need to implement an own authentication mechanism.

It simply needs to rely on the server environment variable REMOTE USER.

17




Figure 12: Browser asks for credentials

Figure 13: Browser sends authorization header

18




The web server can also authorise users based on the URL. Listing 3 shows an example

for two URLs.

<L oc at io n / l o g i n / t e s t 1>

# a ll o w a cc es s t o / l o g i n / t e s t 1 o nl y f o r u se r t e s t 1

r e qu i re u se r t e s t 1

</ Lo ca tio n>

<L oc at io n / l o g i n / t e s t 2>

# a ll o w a cc es s t o / l o g i n / t e s t 1 o nl y f o r u se r t e s t 2

r e qu i re u se r t e s t 2

</ Lo ca tio n>

Listing 3: Apache configuration for authorisation

Base64 is not an encryption but an encoding scheme and can be eavesdropped. This

encoded string should therefore be transmitted over a TLS secured connection. In the ex-

ample the credentials test1:test1 were used and encoded to dGVzdDE6dGVzdDE= [bas].

However the password is still plain text and could be sniffed on the web server. A compro-

mised web server could steal these passwords when a user wants to authenticate. Cookies

(chapter 2.2.8) are better as they have a unique session id, issued independent of the

user password. This session id can also be issued by an additional hardened web server

(chapter 2.2.1).

Independent of the location URL, the authorization header is always sent to the server.

When hosting more than one application on the same server, but under different URLs,

this could be a form of SSO. Unfortunately, with Basic and Digest Access Authentication

there is no other way to log out than closing the browser.

There exists also an second authentication method in HTTP called Digest Access Au-

thentication . It is nearly the same as Basic access authentication, but it encrypts user

name and password with a challenge-response mechanism before transmitting them. This

requires the password to be stored in plain text on the web server to check the response

with the stored password at the back-end. Storing passwords in plain text is a bad idea,

as a thief would immediately have all user passwords.

Therefore, HTTP Basic Authentication with TLS should be preferred.

19




2.2.6 Portal

Sometimes legacy web applications cannot be modified as they exist without source code.

They are using proprietary session management which cannot be integrated into a SSO

system. These applications are so-called ’black-boxes’ and need special attention. As

the application itself cannot be modified, the environment needs to be changed: A proxy

server could be placed in front of these applications which handles user authentication

and authorisation (figure 14). This proxy server can be redesigned to form a portal . It

embeds all other web resources in one frame. The user has to authenticate only once at

the portal and the portal accesses the applications in behalf of the user. Examples to

accomplish this:

URL Rewriting The portal appends a parameter to the calling URL and delegates

authorisation back to the application e.g. by sending the logged-in user name to

the legacy application (listing 4).

Redirecting The user accesses a URL on the portal server. The portal server proxies

this request to the legacy web application (listing 5). It trusts the IP address of the

portal and provides the content. This fits for read-only access.

Andreas Pashalidis developed a proxy solution which works with common browsers [PM].

In all cases the web application needs to unconditionally trust the portal. Proxy/Portal

solution do not scale well and should be rarely used.

20




Figure 14: A Portal server in front of legacy web applications

R e w r i t eE n g i n e on

RewriteCond %{LA−U:REMOTE USER} ( . ∗ )

R e wr i t eR u le ˆ / ( .∗ ) http :/ / a pp li ca ti o n 1 . example . com/ ? us er id=%{LA−U: \

REMOTE USER} [QSA,P,L]

# . . . . a l t e r n a t i v e l y f o r wa r d a s HTTP H e ad er

# i n s t e a d o f a pp en di ng an p ar am et er

#RewriteCond %{LA−U:REMOTE USER} ( . + )

#R e w r i t eR u l e . − [E=RU:%1]

#RequestHeader add X−Forwarded−U s e r %{RU}e

Listing 4: Apache: URL Rewriting

21




# R e d i r e c t h t t p : / / a p p l i c a t i o n 2 . e x am p le . c om /

# o ve r h t tp : / / p o r t a l / a p p l i c a t i o n 1

P r ox y Pa ss / a p p l i c a t i o n 2 / h t t p : / / a p p l i c a t i o n 2 . e xa mp le . c om /

P r o x yP a s sR e v e rs e / a p p l i c a t i o n 2 / h t t p : / / a p p l i c a t i o n 2 . e xa mp l e . c om /

Listing 5: Apache: Redirect via Proxy

2.2.7 Back-ends

To authenticate and authorise a user, the credentials need to be stored at a back-end.

When all web servers use the same back-end, SUL can be realized. Common back-ends

are a flat file, a SQL database or a LDAP server. They all have advantages in certain

scenarios and are exchangeable. Authorisation can be done independent from the back-

end (listing 3). The front-end11 needs to be configured to access the back-end and retrieve

the correct attributes. Passwords should not be stored in plain text to avoid data loss.

They should be hashed before storing them. Common hash-algorithms are MD5 [md5] or

SHA [sha]. SHA has a better collision resistance than MD5 and should be preferred.

Flat file A flat file is a simple text file with a user name and password on each row.

It is easy to set up. Users are added with the htpasswd command to the file .htpasswd

(listing 6). Apache then needs to know the location of this file (listing 7). To enable

more applications to use the same credentials, this text file could be stored on a central

file server or could be provisioned to all application servers. Flat files have no index for

improving search operations. Flat files would not scale well for applications with a large

number of users.

11here: Apache web server

22




$ cd /var/www/http−b a s i c−auth

$ htpasswd −s −b . h tpas swd t e s t 1 t e s t 1

$ htpasswd −s −b . h tpas swd t e s t 2 t e s t 2

$ ca t . htpasswd

t e s t 1 :{SHA}tESsBmE/yNY3lb6a0L6vVQEZNqw=

t e s t 2 :{SHA}EJ9LPFDXsN9ynSmbxvjp75Bmlx8=

Listing 6: Flat file: Creating user name and password

#### Au th en ti ca ti on

<Di re ct or y /var /www/http−b a s i c−a u t h / l o g i n>

# Text f o r t he u se r

AuthName "MasterDissertation: Login with test1/test1 or test2/test2"

# u s e HTTP B a s i c A u t h e n t i c a t i o n

AuthType Ba si c

# u se a t e x t f i l e a s b ac ke nd

AuthBa s icPro vid er f i l e

# l o c a t i o n o f t he t e x t f i l e

Auth UserF ile /var /www/http−b a s i c−auth /. htpasswd

# any v a l i d u se r may l o g i n t o / l o g i n

r e q u i re v al id−u s e r

</ D i r e c t o r y>

Listing 7: Flat file: Apache configuration for HTTP Basic Authentication

SQL Database Server The credentials are stored in a table within the database. The

table has the same structure as a flat file. Users can be added with a SQL statement on

the command line (listing 8). Apache then needs to know the location of this database

server and the necessary SQL statement to retrieve the user password (listing 9).

Database servers can generate an index to improve search operations. The server can be

centralised and accessed over the network. Flat file and database servers have only one

table. They do not have a hierarchy which can represent a company hierarchy.

23




$ mysql −h l o c a l h o s t −u admin −P p a s sw or d u s e r d a t a b a s e −e \

’ i n s e r t i n t o t b l a u t h u s e r ( u s e r i d , u se r p a ss wo rd ) \

VALUES ( ’ t es t 1 ’ , SHA( ’ te st 1 ’ ) ) ;

Listing 8: SQL: Creating user name and password

### D at ab as e Management

# u s e t h e MySQL d r i v e r

DBDriver mysql

# d a ta b a se name a nd l o g i n c r e d e n t i a l s

DBDParams \

"host=localhost dbname=userdatabase user=apache password=\

password"





AuthType Ba si c

# u se a SQL s e r v e r a s b ac k −end

AuthBa s icPro vid er dbd

# l o c a t i o n o f t he t e x t f i l e

AuthDBDUserPWQuery \

"SELECT user_password FROM tbl_auth_user WHERE user_id = %s"



Listing 9: SQL: Creating user name and password

LDAP A LDAP12 server stores its content in a tree of directory entries. It is therefore

also called ’directory server’. Each entry has a unique identifier and consists of key-value

attributes. Users can be added with ldapmodify on the command line (listing 10). Apache

12Lightweight Directory Access Protocol

24




then needs to know the location of this LDAP server, the base-tree and the attributes

to look for (listing 12). Authentication can also be done within the application: In PHP

LDAP-authentication can be accomplished with the class ’Auth’ which can be downloaded

at PEAR13 [phpa]. The Auth -class supports also flat files, SQL databases and a lot more

back-ends. To use the Auth -class, a new Auth -object needs to instantiated with connection

options. The method start() request credentials from the user and verifies them at the

LDAP back-end (listing 11). The result of the verification process can be fetched with

getAuth().

LDAP is optimized for read-only operations and has built-in replication capabilities. The

administration of a sub-tree can be delegated to different departments. In large environ-

ments a directory server is therefore predestined as back-end.

$ ca t myuser . l d i f

dn : uid=tes t1 , ou=People , dc=cer vi ce k , dc=de

o b j e c t c l a s s : top

o b j e c t c l a s s : p er so n

o b j e c t c l a s s : o r g a ni z a t i on a l P e r s ono b j e c t c l a s s : i n et O rg P er s on

c n : T e st U s er One

sn : Doe

givenname : John

u id : t e s t 1

us erpa s s wo rd : {SHA}tESsBmE/yNY3lb6a0L6vVQEZNqw=

$ lda pmo dify −h l o c a l h o s t −D "cn=admin" −w pa s s wo rd −f m yu se r . l d i f

Listing 10: LDAP: Creating user name and password

13PHP Extension and Application Repository - a framework and distribution system for reusable PHPcomponents

25




<?php

r e q u i r e o n c e "Auth.php" ;

$o p t i o n s = array ( ’host’ => ’localhost’ ,

’port’ => ’389’ ,

’version’= 3 ,

’basedn’ => ’ou=People,dc=cervicek,dc=de’ ,

’userattr’ => ’uid’ ,

’useroc’ => ’person’) ;

$a uth = new Auth( ’LDAP’ ,

$o p t i o n s ,

$ l o g i n Fu n c t i o n = ’my_login_function’ ,

$showLogin = true ) ;

// s t a r t a u t h e nt i ca t io n

$auth−>s t a r t ( ) ;

i f ( $auth−>getAuth () ) {

// s e ct i on f o r a u th e nt i ca t ed u se rs

}

e l s e {

// s e c t i on f o r no t a u t he n t ic a t e d u s er s

}

// l o g o ut u se r

$auth−>l o g o u t ( ) ;

?>

Listing 11: LDAP: Authentication with PHP

26








AuthType Ba si c

# u s e a LDAP s e r v e r a s b a ck −en d

A u t h B a s i cP r o v i d e r l d a p

# Lo ca ti on o f t he s er ve r , a t t r i b u t e f o r username

AuthLDAPURL ld ap s :// l o c a l h o s t /ou=People , dc=ce rv ic ek , dc=de? uid ? one



Listing 12: LDAP: Apache configuration for HTTP Basic Authentication

2.2.8 Cookies

HTTP14 is a stateless protocol. This means the web server does never know whom it is

serving. Netscape15 extended HTTP with a state mechanism to enable web applications

to create and use user sessions [rfc]. When a user first logs in to a web server, the web

server sends a so-called ’cookie’ to the user browser. The browser uses this cookie and

sends it on all further requests to this server. Usually a cookie is always sent back to the

server the browser originally got the cookie from, but a web server can modify the domain

attribute of a cookie, so that the cookie is not only sent to one host but to all servers

within a certain domain. This means, for a domain a form of SSO could be established.

This will be demonstrated here with 2 servers: A login [cooa] and a resource [coob] website.

The user tries to access the restricted resource (figure 15). As he is not authenticated, he

will be redirected to the login website (figure 16).

He can authenticate there with a simple click on the ”Log In” button.16 The login

website confirms with a short confirmation and sends a cookie back. This is done with

the Set-Cookie parameter in the HTTP response header (figure 17).

14Hypertext Transfer Protocol15http://www.netscape.com16In reality the user would have to authenticate with a user name and password

27




Figure 15: Restricted Area: Not authorized

Figure 16: Login page

Figure 17: Login page: Authorized

28




Listing 13 shows a short example, how a cookie can be sent with PHP[phpb].

$k e y = "MasterDissertation" ; // name o f t h e c o o k ie

$v a l u e = "1234567890" ; // t h i s i s t he u n i q u e key

$ e x p i r e s = time ( ) +3600; // k ey s h ou l d e x p i re a f t e r one ho ur

$p a t h = "" ; // no r e s t r i c t i o n t o t he p a t h

$domain = ".cervicek.hs-esslingen.de"; / / t h e name o f t h e SSO d om ai n

$ s e c u r e = 1 ; // c oo ki e has t o be s en t o ve r h t t ps

setcookie ( $key , $va lue , $e x p i r e s , $path , $domain , $ s ec ure ) ;

Listing 13: Set a cookie with PHP

Important is also to set the secure attribute. This forces the browser to send this cookie

only over an secured HTTPS connection. HTTPS uses TLS[tls] to ensure confidentiality

and authenticity. If this attribute would be absent, the cookie would be sent unencrypted

and could be eavesdropped. Somebody else could then use this cookie to impersonate the

user. Unfortunately there are still a lot of applications which do not set this attribute

[ins].

When the user now tries to access the restricted resource, its browser sends the cookie

with the Cookie parameter in the HTTP request header to the server. The server accepts

the cookie with the secret hash and authorizes the user to view the resource. (figure 18)

By clicking the ”Log Off” button, the server deletes the cookie bei unsetting the value for

the MasterDissertation cookie (figure 19). To make sure the browser really deletes the

cookie, it additionally sets the expiration date back to the past.

The use of cookies prevents phising of credentials at the web servers. Some users are con-cerned about data privacy and disable the use of cookies in their browsers. Unfortunately,

these frameworks work only with cookies enabled in the browser, so these users would

have a problem.

This cookie/SSO-domain approach could be a simple and fast-deployable solution for a

small organisation but there are some drawbacks in this solution: If the the 2nd-level

domain of an organisation is used as SSO-domain, then the cookie will be sent to all web

servers within the same domain, even if they are untrusted (figure 20). If an untrusted

web server can intercept this cookie, the owner of this untrusted web server could use

29




Figure 18: Restricted Area: Authorized

Figure 19: Logout response

30



2.3 Summary

this cookie to impersonate the victim. To avoid that security risk, a new subdomain

should be created for the SSO-domain. All web servers should be renamed to fit into

this new SSO-domain. A web server named webmail.example.com would have to be

renamed to webmail.sso.examle.com . This lacks usability, as all users need to update

their bookmarks and remember a new hostname to access their old webapplication. This

solution is dependent on DNS and works only within the same organisation. There is no

way to tell the browser to use the cookie also in other domains. A workaround could be

to share a domain with other organisations, but that would not scale well.

To get around these pitfalls, some cookie-based frameworks were developed which will be

discussed in the next chapter.

Figure 20: SSO domain

2.3 Summary

In this chapter technologies were discussed how a user can authenticate at a web server

and how these technologies could be used for SSO. User accounts managed in a central

directory provide an opportunity to use the same userID/password on all web servers

within a domain. The local federation approach offers the possibility for real single sign-

on. The accounts can be managed by an organisation or by the user itself in the User-

centric Identity approach. UserIDs stored on a LDAP server offer the best solution for

all scenarios. In small environments a Flat file would also be an option. Cookies offer the

best possibility for Web SSO. All other access methods are insecure or not user-friendly.

31



3 Analysis and Implementation

3 Analysis and Implementation

OpenID and Shibboleth are cookie-based frameworks and are discussed in this chapter.

The focus lies on understanding the main principles of these frameworks. The answers to

these questions are handled here:


• terminology: Which roles exist in this setup?


and authenticity?


• end user experience in the browser: What is the look and feeling for the user?


3.1 OpenID

OpenID is a standard for a single sign-on system, which offers a decentralized user-centric

identity [opeb]. OpenID exists currently in version 2.0.

Figure 21: Logo of OpenID

OpenID is widely spread in the blogger scene. Blogs usually give the reader the possibility

to comment an article. Unfortunately, this function is often abused by spammers. To

avoid spam a blog can force a reader to register an account.

As there are many blogs in the internet, the user would have to register on each blog

separately. OpenID with its decentralized architecture is therefore predestined to be

32



3.1 OpenID

used as an authentication mechanism on blogs. WordPress [worb] is a well-known blog

application and offers an optional OpenID-plugin [wora]. Figure 22 shows a blog entry

with a comment of an OpenID-enabled reader.

There are a lot of OpenID Providers which offer identifiers for free. Customers of AOL,

Yahoo and some companies more have already an OpenID enabled account and therefore

don’t need to register at another OP [opei]. The list of OpenID enabled Relying Parties

is already huge and still growing [opec]

A lot of content providers offer OpenID accounts but nearly none of them wants to

accept OpenIDs of a competing OP. They want to to promote their own services, increase

the market share and force users to register at them. Facebook, a well-known social

networking website, surprised the internet community by announcing April 27th 2009

they would accept OpenID identifiers from other OPs [fac]. Google is also using the

OpenID-technology, but Google has still to be used as Provider [opea].

Figure 22: WordPress OpenID-plugin used by the comment function

33



3.1 OpenID

3.1.1 Terminology

This section provides introductory information about OpenID and builds the foundation

for understanding the information provided in this and the next chapters.

End User The End User is the real user or a real person who is using the OpenID

system to log in to different web sites using his/her credentials stored at the Identity

Provider.

Identifier Each End User has at least one userID in form of an URL17 e.g. http://john.doe.example.c

The user can use this userID on all openID-enabled applications.

OpenID Provider (OP) The Identity Provider is the host where a user’s credentials are

stored. The OpenID URL points to the identity provider. During the authentication

process, the Consumer will validate an ID by exchanging some messages with the

Identity Provider. Sometimes it is also called as OpenID Server, OpenID Provider

or simply OP.

Consumer or Relying Party (RP) Consumer is the actual web site where the userlogs in using OpenID. It is called Consumer because it consumes the OpenID cre-

dentials provided by the Identity Provider. All web sites that support login using

OpenID are Consumers. In OpenID specification 2.0 as well as in some other lit-

erature related to ID administration, a Consumer is also called a Relying Party or

RP.

User Agent A User Agent is the browser. A user interacts with the User Agent directly.

3.1.2 User Experience

Delegation When a user wants to participate in OpenID he first needs to register at an

OpenID Provider. The identifier of an OpenID Provider can be used directly as identifier

for the user. However, this makes the user dependent on the OP. When this OP stops

serving his identifier, the user would have to take a new identifier on all his registeredOpenID Relying Parties.

17Uniform Resource Locator

34



3.1 OpenID

Fortunately, the host providing the identifier and the host/service providing the authenti-

cation service does not have to be the same. The user could use his homepage as identifier

which makes him independent from an OP. The homepage needs a link to an OP, where

the user needs to authenticate: The user delegates his identifier to an OpenID Provider.

When the user wants to take a new OP, he just changes the link and still keeps his

homepage as identifier.

These are the necessary steps for delegating an identifier to an OP: Two entries are added

to the head -section of an existing homepage, written in HTML18 (listing 14). The look of

the homepage will not change (figure 23). The rel-link openid.delegate is the identifier the

user has at its actual OP. The rel-link openid.server cites the responsible server-endpoint

process which will handle RPs requests.

The user could also host an own OP with phpMyID [phpc]. It is very simple to set up

and configure with a text file on the server (listing 15). Unfortunately, it has nearly no

features.

Figure 23: Homepage as identifier

18Hyper Text Markup Language

35



3.1 OpenID

<html>

<head>

<t i t l e>This i s my OpenID</ t i t l e>

<l in k r e l="openid.server"

href ="http://phpmyid.cervicek.hs-esslingen.de/index.php">

<l in k r e l="openid.delegate"

href ="http://phpmyid.cervicek.hs-esslingen.de/index.php">

</head>

<body>

. . . <h2>Welcome to my OpenID us er page </h2> . . .

</body>

</html>

Listing 14: Linking to an OP in HTML (shortened)

$GLOBALS [ ’profile’ ] = array (

’auth_username’ => ’test’ ,

’auth_password’ => ’37fa04faebe5249023ed1f6cc867329b’,

### Password gen e rat ed wit h

### echo −n ’ t e s t : p hpMyID : t e s t ’ | o p e n s s l md5

) ;

Listing 15: phpMyID: Defining credentials

Authentication Figure 24 shows the steps during the authentication process from a

user view.

1. The User has to type in the location of his desired resource (RP)

2. When the RP asks for its identifier, the user can provide his identifier at an OP. As

discussed above, the user can also provide his homepage with its delegated identifier.

3. The RP checks the identifier, if it is already pointing to an OP or if it is a private

homepage with a delegated identifier.

36



3.1 OpenID

4. When the RP knows the URL of the Login-from of the OP, the RP redirects to user

to this form.

5. The browser redirects the user to the OP.

6. The user types in his identifier and his password to the Login-form. He has to do

this only once. The user should verify if he is really connected the correct OP

(chapter 3.1.5).

7. The OP redirects the browser back to the RP. The OP also adds a ’ticket’ to this

redirect-URL.

8. The browser goes back to the RP and shows this ticket. The RP accepts this and

grants access to this user.

Please note, that the user in step 2 has to provide his identifier to the RP. Step 2 is

necessary for all RPs. In a real SSO system, step 2 would be absent and the RP would

already know the user without asking him. OpenID can therefore not really called to be

a ’SSO system’.

A small workaround could be, when the RP stores a cookie on the user browser to recognise

the identifier when the user comes back later. The user would then not have to type in

his identifier again. This does not help when another user with the same browser would

try to log in. At least the user does not have to remember and type in different passwords

so OpenID can be called ’simplified SSO’.

37



3.1 OpenID

Figure 24: Authentication with OpenID

38



3.1 OpenID

3.1.3 Integration and Implementation

There are Libraries for PHP, Phyton, Ruby, Java and C# [oped]. In all Libraries example

code is included. For this dissertation, the PHP example code had been installed and

tested on four servers:

• A Homepage as identifier [opee]

• phpMyID as own OpenID Provider [opef]

• Relying Party #1 [opeg]

• Relying Party #2 [opeh]

The example code could be verified with a valid OpenID identifier on the test setup [opeh].

The code comes with three files:

index.php This is the start page for the user. When the user logs in, a GET request to

try auth.php will be invoked with the GET parameter listed in table 1.

try auth.php The start page calls this page. It forms the OpenID request and sends it

to the with the GET parameters in table 2 to the OP.

finish auth.php The OP redirects the browser back to the RP with the GET parameters

in table 3.

There exists no good example how to modify existing applications. A developer has to

implement an own session management together with OpenID.

39



3.1 OpenID

action verifyopenid identifier http://id.cervicek.hs-esslingen.de

Table 1: GET parameters at Login

openid.assoc handle 41c36ebc5ee8617c45624c51a0606ac7openid.identity http://phpmyid.cervicek.hs-esslingen.de/index.php

openid.mode checkid setupopenid.pape.preferred auth policies

openid.return to Callback URLopenid.sreg.optional fullname,emailopenid.sreg.required nickname

openid.trust root http://rp1.cervicek.hs-esslingen.de:80/consumer/

Table 2: GET parameters to OP

janrain nonce 2009-07-14T07:26:01Zhmb7FGopenid1 claimed id http://id.cervicek.hs-esslingen.de/openid.mode id res

openid.identity http://phpmyid.cervicek.hs-esslingen.de/index.phpopenid.assoc handle 41c36ebc5ee8617c45624c51a0606ac7

openid.return to Callback URL

openid.sreg.nickname Patrick-OpenIDopenid.sreg.fullname Patrick C.openid.sreg.email [email protected]

openid.signed mode,identity,assoc handle,return to,sreg....openid.sig Le44zyR07tA2jMS/24Aoj2+7R58=

Table 3: GET parameters to RP

Local federation Using OpenID for a local federation is not the main use case, therefore

the web applications on the RPs need to be modified to accept only userIDs from the

own organisation. Modifications are not nice as this increases the complexity of these

applications: Updates need to be modified again. To prevent unauthorised access, the

firewall of the SPs should be adjusted to allow outgoing requests on TCP port 80 only to

the OP. All other outgoing request should be denied. An attacker could therefore never

authenticate at his own OP and gain unintended access, as the web application could

never establish a connection to its OP to verify him. To trust the local federation, it

must be ensured that users cannot create new accounts. Only accounts created by the IT

40



3.1 OpenID

department should be trusted. Attributes could be maintenend within the OpenID profile.

The web applications can also be configured to use OpenID only for Authentication and

use corporate directory to look up attributes.

3.1.4 Attribute Exchange and Data Privacy

OpenID allows to transfer user defined attributes to RPs. A user defined attribute can be

a nickname, mail address, birthday and some more. As OpenID needs to be compatible

with a lot of consumer sites, the attributes cannot be easily extended by the operators

themselves. Only attributes specified in OpenID specs are allowed. In phpMyID, the

attributes have to be defined on the server as key-value parameters (listing 16). When

the user authenticates at a RP, the OP transmits these attributes back (figure 27). There

are better OPs, which allow to generate multiple profiles with a webinterface (figure 26).

A profile is a set of user attributes. A user could therefore create a profile for business,

private and anonymous purposes and assign it to different RPs. The RP receives then

only those attributes and nothing more.

$GLOBALS [ ’sreg’ ] = array (

’nickname’ => ’Patrick-OpenID’ ,

’email’ => ’[email protected]’ ,

’fullname’ => ’Patrick C.’ ,

’country’ => ’DE’ ,

’language’ => ’de’ ,

’timezone’ => ’Europe/Berlin’

) ;

Listing 16: phpMyID: Defining attributes

Communication There is nearly no direct communication between the RP and the

OP. Most of the communication takes place over the user browser via HTTP redirects.

The RP only needs to resolve a delegated ID by parsing the homepage of a user. The

RP needs also to connect at least one time to the OP to get a shared secret. This shared

secret will be used by the OP to sign its assertions. The RP can then verify if the assertion

41



3.1 OpenID

Figure 25: Authentication at phpMyID

Figure 26: Releasing attributes to a relying party

Figure 27: Attributes received by a relying party

42



3.1 OpenID

supplied by the user is not tampered with something else. When a RP is operating in

Dump Mode, a shared secret has to be exchanged for every user of this OP. In Smart

Mode, the RP needs only one shared secret for all users of this OP, which saves time and

traffic.

3.1.5 Security

Operators should consider that OpenID helps only to verify that a user can claim an URL.

Claiming a URL named queenelizabeth.myorganisation.com does not tell anything about

the users’ real identity. However, the domain can provide operators the information,

that a user is affiliated to myorganisation . There exists also OPs which always return

authenticated as status result - no matter which username and password where used.

This can be seen a seen as analogon to BugMeNot. BugMeNot is a website which lists

user names and password for websites which require registration [bug]. Malicious Relying

Parties could redirect the user to a fake OpenID Provider. To avoid phising, the user

needs to pay attention that he enters his credentials only on the correct website (figure

28). Users should always verify, if they are really connected the correct OP. With SSL, thisis indicated through the lock-sign in the status bar. With standard basic authentication,

there is no good way to see whether the connection is secure or the destination is really

the OP (figure 25). The OpenID Provider MyOpenID offers also the possibility to save

a personal icon which will be associated with a cookie at the user browser. Whenever

the user wants to enter his password, he should verify if he sees his personal icon in the

upper-right corner. This picture needs to be secret and may not be used somewhere else.

Otherwise a malicious website could also use it for phising.

Even this feature is not necessary when the user is familiar with SSL, it helps users to

determine if they are on the correct OP. To prevent users typing in their passwords, a

login with SSL certificates (chapter 2.2.4) is also possible.

There exists a Firefox plugin named Sxipper [sxi] which helps a user to avoid typing their

passwords on faked sites. Sxipper monitors the protocol flow and if it detects unusual

redirection from the site the user is trying to log into, the user will get a phishing at-

tempt warning. This will give the user a chance to assess the threat before proceeding or

43



3.1 OpenID

Figure 28: Secure Login at MyOpenID.com

canceling.

By default, OpenID accepts all OPs. With a hack, a RP can be enforced to accept

only OPs with certificates signed by an trusted CA. The PHP library uses the command

line tool cURL for data transmissions [cur]. cURL stores its trusted CA certificates in

/etc/ssl/certs/ca-certificates.crt . OPs not using certificates signed by a CA listed in this

list will not be accepted by this RP. This works only if all users would use a https identifier,

otherwise cURL would accept all OPs.

To prevent replay-attacks, OpenID uses a nonce in all exchanged messages. A nonce is one

time valid number and cannot be used a second time. OpenID uses DNS to resolve the OP.

When the OP and RP exchange messages unencrypted, there is also a good chance that

a man-in-the-middle attack could occur [opej] [opek] [opel]. OpenID uses Diffie-Hellman,

which establishes an encrypted connection. Because Diffie-Hellman does not verify the

authenticity of the communication partners, it is prone to man-in-the-middle attacks.

The usage of https identifier could mitigate these problems, but as long as it is not default

it is still up to the user to enforce security.

44



3.2 Shibboleth

3.2 Shibboleth

Shibboleth [shib] is a free standard for federated identity-based single sign-on infrastruc-

ture. It was developed by the Internet2 [int] Networking Consortium and exists in version

2.0. Shibboleth is based on SAML19, an XML-based standard for exchanging authenti-

cation and authorization data between security domains. SAML was developed by the

OASIS consortium [oas].

Figure 29: Logo of Shibboleth

Shibboleth is mainly used by universities which unite to a federation on national level

[shij]. The Brunel University belongs to the UK Federation and provides an IDP but no

SPs [shia]. The list of ’shibbolized’ Applications is still small [shie].

3.2.1 Terminology

This section provides introductory information about Shibboleth and builds the founda-

tion for understanding the information provided in this and the next chapters.

Identity Provider (IDP) The Identity Provider is the host where a user’s credentials

are stored. During the authentication process, the SP will redirect the user to an

IDP and force the user to authenticate there. Upon success, the IDP confirms to

the SP that the user is valid and now logged in to the Shibboleth federation.

Service Provider (SP) The service provider is the actual web site where the user logs

in.

Discovery Service ”Where are you from?” (WAYF) When a user visits a SP thefirst time, it needs to determine the identity of the user. The SP therefore needs to

19Security Assertion Markup Language

45



3.2 Shibboleth

ask the correct IDP of the user. As there are many IDPs in a federation, the user

is being redirect to a A WAYF form, where the user needs to choose its IDP. The

SP can then ask the IDP for the identity of the user.

When a user visits a SP the first time, it needs to determine the identity of the

user. The SP would like to ask the home IDP for an assertion. As there are many

IDPs in a federation, the SP needs to determine the correct one. The SP therefore

redirects the user to a WAYF form where the user chooses his home organisation.

The WAYF reports the decision of the user back to the SP, which will redirect

the user to its home IDP. The user authenticates at the IDP and upon successful

authentication the user will be authenticated to the federation, issued an SAML

assertion and be redirected back to the SP. The SP checks the SAML assertion for

validity and accepts the user.

As stated earlier, Shibboleth is a federated identity-based single sign-on infrastructure.

A federation needs a central authority which maintains the following tasks:

Contracts Contracts are necessary to establish trust between the federation participants

by introducing policies to them. This central authority represents the federation to

all existing and new partners.

Policies Policies guarantee trust to all federation participants. The policies for IDPs are

high e.g. IDPs need to ensure that they maintain a correct identity management

system. All users within a IDP need to be correctly classified e.g. staff, student,

guest. When a user is no longer employed within his organisation, this account needs

to be locked. All participants need to use X.509 certificates which is usually signed

by the central authority itself. All participants agree on trusting this authority. SPs

are always welcome and are nearly not subject to any policies as they cannot harm

the federation in any way.

Discovery Service The central authority maintains a Discovery Service which all SPs

can use.

46



3.2 Shibboleth

Meta Data All participants are maintained in a central ’database’. This database con-

tains the attributes for each IDP/SP in XML format. This attribute are usually:

• Name of the organisation

• X.509 certificates

• SOAP20-endpoints for the Shibboleth daemon

• Administrative contact

All participants have a local copy of this database, which should be updated on a

regular basis.

Support The central authority helps participants with installation and configuration of

the necessary software components.

Training As shibboleth is a complex framework, federating system operators need train-

ing to introduce shibboleth in their organisations.

3.2.2 User Experience

Users demand an easy and transparent access to all resources within a federation. Figure

30 shows the steps during the authentication process from a user point of view.

1. The User has to type in the location of his desired resource (SP) (figure 31).

2. If the SP is part of a federation with more than one IDP, the SP redirects the

browser to a WAYF. Otherwise it directly redirects the user to its home IDP.

3. The browser redirects the user to the WAYF (figure 34).

4. The user chooses his home IDP.

5. The WAYF redirects the browser back to SP and sets a cookie. Whenever the user

is redirected to this WAYF again by another SP, the WAYF recognises him and

redirects him automaticaly to its home IDP.

6. The browser redirects the user to SP.

20Simple Object Access Protocol

47



3.2 Shibboleth

7. The SP redirects the user with a SAML Authentication Request (listing 17) to the

home IDP.

8. The browser redirects the user with a SAML Request to the home IDP. The URL

is https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO and has two GET pa-

rameters (table 4).

After processing the SAML request, the IDP checks if the user is already authen-

ticated at the IDP. If yes, the IDP would send the user back to the requesting SP.

If not, the IDP redirects the browser to an external authentication handler. In this

example, the IDP is using the username/password-handler. It therefore redirects

the user to the URL

https://idp.testshib.org:443/idp/Authn/UserPassword . By doing this, it is also set-

ting the cookie idp authn lc key . When the IDP transmits the user/password-

handler page it sets the cookie JSESSIONID .

9. The user types in his identifier and his password to the Login-form (figure 32). He

has to do this only once. The user should verify if he is really connected thecorrect OP (chapter 3.1.5).

10. When the authentication is successful, the IDP sets the cookie idp session . The

user is now authenticated at the IDP. Whenever the user comes back to the

IDP, the IDP will recognise the user and always send a SAML Response to the

requester. The SAML Response is sent by redirecting the user to a SAML request

form (listing 19). This is necessary as the SAML request would not fit into a GET-

string. The necessary fields are already filled with the necessary values. The form

is then automatically sent with the javascript submit() method. If the user has

disabled javascript (e.g. for security reasons), the user would have to click on the

submit button.

11. The browser redirects the user with the SAML Authentication Response Assertion

to the URL https://sp1.cervicek.hs-esslingen.de/Shibboleth.sso/SAML2/POST . The

SAML Assertion look like listing 18.

48



3.2 Shibboleth

RelayState http://sp1.cervicek.hs-esslingen.de/secure-allSAMLRequest base64 encoded SAML Request (listing 17)

Table 4: SAML Authentication Request

12. The SP redirects the browser back to the original location from step 1. It also sets

a cookie shibsession 6465666..... With help of this cookie the shibd daemon at

the SPs webserver can recognise the user without having to ask again for a SAML

Assertion at the IDP. The user can now access the Shibboleth protected resource

(figure 33).

The network between the user and the involved servers can have a big impact on the

authentication process. There are three factors to consider:

Bandwidth The bandwidth is not important for the authentication process as only small

redirections, cookies, and SAML assertions are exchanged.

Latency The latency is a bigger problem. Whenever the browser access an involved actor

the TCP Three-way-handshake is initiated before user data or SAML assertions canbe exchanged. The latency could depend on congested backbones or the distance

between the actors. It should therefore not be a problem for intranet applications

on the same LAN.

Round-trip time (RTT) The round-trip time is the time a message needs to get to

a destination and get back to the source. The bigger the latency, the bigger the

round-trip time. RTT plays a role with ’ping-pong’ protocols like TCP or DNS.

Figure 35 shows the latency which can occur while trying to access a web server. When

the user types a URL into the browser, the browser needs to look up the IP address of the

web server. The browser asks the operating system which in turn asks the local configured

DNS server. The result is then sent back to the browser. The browser now tries to connect

to the remote web server. The underlying operating system is doing a so called ’TCP

three-way handshake’ to establish a connection to the remote web server on port 80. TCP

sends a packet with the ’SYN’-flag set, waits for a response packet with the ’ACK’-flag

49



3.2 Shibboleth

Figure 30: Authentication with Shibboleth

50



3.2 Shibboleth

Figure 31: Accessing a resource

Figure 32: Authentication at a IDP

Figure 33: Authorized access to a resource

51



3.2 Shibboleth

Figure 34: WAYF server from ukfederation.org

set. The operating system responds to this response packet with ’SYN/ACK’-flag. The

TCP connection is then established. The browser can now request websites by sending an

HTTP-Request to the remote web server. The remote web server returns the requested

resource back to the client. This steps are all dependent on each other and increase the

latency for the user. When the user is redirected to a WAYF or a IDP, the browser needs

to repeat all of the above listed steps. To avoid a bad user experience, the RTT to the

the involved servers should be low.

3.2.3 Architecture

A short overview of the protocol flow has been shown in section 3.2.2. Figure 36 shows

the internal architecture of Shibboleth, how they are related to each other and where they

are distributed at the IDP and SP.

These services are located on the IDP:

Handle Service (HS) The HS provides a pointer (handle) to the Shibboleth Indexical

Reference Establisher. It determines whether the user has already logged in to the

52



3.2 Shibboleth

Figure 35: Latency while connecting to a web server

Figure 36: Shibboleth: Relationship between the components

53



3.2 Shibboleth

IDP. If yes, the handle will be provided to the SP. If not, the user is forced to

authenticate.

Attribute Authority (AA) The AA responds on attribute requests from SHAR. To

get these attributes, SHAR needs to provide a handle which has a valid session on

the IDP. The attributes are resolved in the IDM and released upon the polices on

the IDP.

Identity Management (IDM) The IDM keeps the information about the valid users

in the domain. Usually a directory service like LDAP is used.

Attribute Release Policy (ARP) The ARP is not a service but a Policy for the AA.

It defines which attributes are released to the SP.

These services are located on the SP:

Resource Manager (RM) The RM protects the resource and allows only authenti-

cated requests. It uses the attributes sent by the SHAR. Unauthenticated requests

are sent to SHIRE.

Shibboleth Indexical Reference Establisher (SHIRE) The SHIRE is invoked by

the RM and checks a user’s validity. It redirects the user to the WAYF or directly

to the IDP. Handles sent by the HS are received here and passed to the SHAR.

Shibboleth Attribute Requester (SHAR) SHAR is invoked by SHIRE and requests

attributes about the user from the AA. It passes along the handle delivered by

SHIRE. The received attributes will be checked against the AAP and then passed

to the RM.

Attribute Acceptance Policy (AAP) The AAP is not a service but a policy for the

SHAR. It defines the attributes accepted by the SP from a certain IDP.

54



3.2 Shibboleth

<samlp:AuthnRequest

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

A s s e r t i o n C o n s u m e r S e r v i c e I n d e x ="1 "

D e s t i n a t i o n =

"https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO"

ID="_bbd9fd..." I s s u e I n s t a n t ="2009-04-19T14:59:59Z" Vers io n="2.0">

<s a m l : I s s u e r x m ln s: s am l="urn:oasis:names:tc:SAML:2.0:assertion">

h t t p s : // s p 1 . c e r v i c e k . hs−e s s l i n g e n . d e / s h i b b o l e t h−sp

</ s a m l : I s s u e r>

<s a mlp:Na meIDPolicy Allo wCrea te="1"/>

</samlp:AuthnRequest>

Listing 17: SAML request (shortened)

<?xml version="1.0" enco ding ="UTF-8"?>

<s a mlp:Res po ns e

D e s t i n a t i o n =

"https://sp1.cervicek.hs-esslingen.de/Shibboleth.sso/SAML2/POST"

ID="_9467..." InResponseTo="_bbd9fd..."

I s s u e I n s t a n t ="2009-04-19T15:03:33.902Z" Vers io n="2.0"

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

<s a m l : I s s u e r

Format="urn:oasis:names:tc:SAML:2.0:nameid- format:entity"

xmlns :s a ml="urn:oasis:names:tc:SAML:2.0:assertion">

h t t p s : / / i d p . t e s t s h i b . o r g / i d p / s h i b b o l e t h

</ s a m l : I s s u e r>

. . .

</ s a m l p : R e s p o n s e>

Listing 18: SAML response (shortened)

55



3.2 Shibboleth

<html>

<body onload="document.forms[0].submit()">

<form method="post" . . .

action=

"https://sp1.cervicek.hs-esslingen.de/Shibboleth.sso/SAML2/POST"

>

<input type="hidden" name="SAMLResponse" value="....." />

. . .

<input type="submit" value="Submit" />

</form>

</body>

</html>

Listing 19: SAML response form (shortened)

3.2.4 Integration and Implementation

For this dissertation, Shibboleth had been tested with four servers:

• Identity Provider at TestShib (foreign organisation) [tes]

• Identity Provider at University of Applied Sciences Esslingen (home organisation)

[idp]

• Service Provider #1 [shih]

• Service Provider #2 [shii]

The shibboleth daemon is a module which can be used in the IIS21 or the Apache web

server22. It provides a new authtype. URLs can now be protected with a simple ⟨ Location ⟩

directive (listing 20).

21’Internet Information Server’ from Microsoft22In this dissertation the focus lies on the module for the apache web server

56



3.2 Shibboleth

<L o c a ti o n / s e c u r e−a l l> # p r o t e c t h t t p : / / s p1 / s e c u r e−a l l

AuthType s hi bb o l et h

S h i b R e q u i r e S e s s i o n O n


</ L o c a t i o n>

<L o c a ti o n / s e c u r e−s t a f f o n l y> # p r o t e c t h t t p : / / s p1 / s e c u r e−s t a f f o n l y

AuthType s hi bb o l et h

S h i b R e q u i r e S e s s i o n O n

r e qu i re a f f i l i a t i o n ˜ ˆ S ta f f@ # o nl y ’ S t af f ’ u s er s a ll ow ed

</ L o c a t i o n>

Listing 20: Apache: Protecting a resource with Shibboleth

It protects the content of a location specified in a ⟨ directory ⟩ node. When a user connects

to a shibboleth protected resource for the first time, the shibboleth daemon checks whether

the user is already authenticated to the federation. If yes, the user may see the requested

resource. If not, the user is being redirected to its home IDP.

To use Shibboleth on a Service Provider, the Shibboleth daemon needs to be downloaded

and installed. All federations provide sufficient support installing IDPs and SPs [dfn]

[swid] [shil].

The Shibboleth daemon provides environmental variables, which can be accessed within all

dynamic pages. Listing 21 shows an example how to access some environmental variables

within PHP. Figure 33 shows the result.

Sometimes the application itself is running in an application server like Tomcat [tom]. As

the application server is not running in the same context as Apache does, it cannot access

the environmental variables. Apache needs to ensure with the keyword ShibUseHeaders

On that the environmental variables are added to the HTTP Header. This directive is

off by default as an attacker could inject faked HTTP Headers. Whenever possible, the

application should only use environmental variables.

The attributes sent from the IDP to the SP can be investigated by displaying the received

attributes with a special viewer page [swie].

57





3.2 Shibboleth

choice to detect, whether a session has already been established or not. It should also

check, if it still receives the Shibboleth environment variables. If they are absent, then

there exists no valid Shibboleth session and the application should redirect the user to

the session initiator to enforce a re-authentication.

The catholic university Leuven also provides example code for lazy sessions [shig].

<a h re f ="http://sp1.cervicek.hs-esslingen.de/Shibboleth.sso/\

TestShib?target=http://sp1.cervicek.hs-esslingen.de/\

lazysession/">Login</a>

Listing 22: Lazy Session: Log in link

<L o ca t i on / l a z y s e s s i o n>

AuthType s hi bb o le th

S h i b R e qu i r e S e ss i o n O f f

r e q u ir e s h i bb o le t h

</ Lo ca tio n>

Listing 23: Lazy Session: Apache configuration

Local federation Shibboleth can be used to build a local federation to enable SSO.

Shibbolized applications do not care in which federation they are being used as this

is managed by the Shibboleth daemon and the web server together. Therefore these

applications usually do not have to be modified.

To build an own federation the following steps are needed:

1. Ensure the user objects are stored in a central back-end.

2. Determine a server as IDP.

3. Identify the servers which should participate in the local federation.

4. Choose a PKI for the internal usage. These can be self-signed certificates as only

the involved servers need to trust each other. The outer certificates should be signed

by a certificate authority well-known to the browser of the users.

59



3.2 Shibboleth

5. Set up an Attribute Release Policy. Even within an organisation data privacy needs

to be ensured between departments.

6. Implement the mentioned steps with Shibboleth.

Further support for building a local federation can be found in the Shibboleth documen-

tation [shid].

Legacy Applications Legacy applications are hard to integrate with Shibboleth, as

they have own session management and can not be influenced from outside with environ-

ment variables. SWITCH developed AAIportal to address this problem [swia]. AAIportal

is a portal solution as already described in chapter 2.2.6. It supports e-learning applica-

tions like WebCT or Blackboard .

Logout Single Log Out (SLO) is still a problem with Shibboleth. When a user logs out

at SP #1 he is still authenticated at the IDP. He could then visit SP #2 and the IDP

would still confirm that he is valid user who may enter SP #2. If the user would log out

directly at the IDP, he would still get access to already authenticated SPs.

In local federations all web applications could include a logout link which closes the session

on the SP, redirects the user to the IDP and closes the session there, too (listing 24). An

optional return value can redirect the user on the start page of a SP. Unfortunately, this

logout procedure does not close the session at other SPs. When a lazy session was used,

then the application itself should also be informed about the logout by redirecting the

user to the logout page of the application itself. The application should then invalidate

the actual user session.

The only way to ensure a logout is to close to browser. By closing the browser, all session

cookies are delete and therefore all valid sessions to IDPs and SPs are removed. This may

be a good tradeoff when the user has an own account on his operating system and has to

take responsibility for his account. But as soon as the user is sharing the same account

on his desktop with other users, the danger of identity theft is real. Shibboleth shouldn’t

therefore be used on SPs with confidential information. It is a common security policy to

disable all kinds of SSO systems on resources with confidential information anyway.

60



3.2 Shibboleth

<a h re f ="/Shibboleth.sso/Logout?return=https://idp.cervicek.hs-\

esslingen.de/logout%3Fhttp://sp1.cervicek.hs-esslingen.de/"\

>Logout</a>

Listing 24: Shibboleth: Log out link

3.2.5 Attribute Exchange and Data Privacy

In earlier versions of Shibboleth IDP and SP needed to talk over dedicated SOAP-Callback

endpoints to each other, which requires further ports to be opened in the firewall. Since

Shibboleth version 2.0, attributes can be exchanged directly over the browser, which

minimises the necessary traffic between SP and IDP. As the attributes are encrypted and

signed it is not a security risk to the federation. This makes it easy for corporate users to

use extranet applications at partner companies without giving these extranet applications

access to the IDP which usually resides within the protected company intranet.

The federation members need to agree on several attributes: Name, mail, affiliation and

so on. The federation is open to new attributes as long as all member agree to use the

same namespace and same type.

According to data protection laws, the home organisation has to ensure that the users’

data/attributes are not released to a SP without obtaining user consent. Birgit Pfitzmann

and Michael Waidner describe the requirements for privacy in their research paper [PW02].

To ensure this policy, the user could be forced to sign a contract that ’all user attributes

may be sent to partners of the organisation’. It would be more flexible when the user

could decide individually where to send its attributes and where not. SWITCH developed

the tool ’uApprove’ which redirects the user to a form which displays the attributes sent

to a service provider [uap]. The user can approve or deny the transfer of attributes to the

SP. So the organisation has legal security as it is up to the user who has to approve the

attribute exchange. Sidharth Nazareth developed SPADE which has the same purpose

[NS04].

In case a UID is simply needed to recognise a user without knowing his exact iden-tity, a unique ID can be used. This is usally a hash value generated by the IDP e.g.

61



3.2 Shibboleth

[email protected] and sent to the SPs instead of the the real UID.

To prevent SPs collecting and sharing logfiles about a certain user, the IDP can also use

a different unique ID on each resource for the same user. The unique ID is hashed with

the UID of the user, the ID of the SP and the ID of the IDP. The IDP stores in a table

the UID, the corresponding resources and unique IDs (Table 5).

UID resource unique IDpatrick sp1.example.com [email protected] sp2.example.com [email protected]... ... ...

Table 5: Unique IDs stored by IDP

This approach needs to be used carefully as the unique ID would change when the ID of

the IDP or SP changes. Otherwise the user would not be recognised any longer.

3.2.6 Security

Shibboleth is a very secure framework as it relies on an own PKI:

• All transmissions are encrypted with strong ciphers.

• All SPs and IDPs need own X.509 certificates signed by a trusted CA.

• Only known SPs and IDPs can participate in the federations.

• The XML-messages exchanged by SP and IDP are itself signed and encrypted.

• The IDP forces the user to enter his credentials only over secure HTTPS connections.

• Cookies have the secure-flag set.

Thomas Groß discovered some security flaws in the underlying SAML protocol, but

pointed out that

”In general, it is a good idea to use SSL 3.0 or TLS 1.0 as communication

channel. Their use enhances the security of the SAML Single Sign-on protocol

dramatically.” [Gro03]

From the security point of view, Shibboleth fulfils all requirements.

62



3.2 Shibboleth

3.2.7 Clustering and High Availability

As the whole federation depends on working IDPs, some considerations have to be done to

guarantee high availability. Both frameworks depend on a working web server, database

and network.

Clustering To make the IDPs more scalable, a load balancer could be placed in front

of the IDPs. The load balancer should be ’sticky-session’ aware to provide clients always

the same IDP during a session. This is important to avoid the user to authenticate to all

IDPs again. Sessions could be determined on the basis of the source-IP and source-port.

Clustering itself is not recommend as the database would be the single-point-of-failure.

A cheap alternative could be DNS Round Robin: The DNS server knows 2 or more IPs

for the same hostname. On each query to this hostname, the DNS server replies with an

IP not already sent in the previous answer. The browser remembers the server IP and is

therefore ’sticky-session’ aware.

Sometimes companies use more than one outgoing IP address in their proxies. Shibboleth,

by default, does not accept alternating source IPs during one session. Shibboleth doesthis to prevent attacks with spoofed IP addresses. To enable alternating IPs, the SP needs

to be adjusted with consistentAddress=”false” in the ⟨Sessions⟩ element [shic]. Security

of the SSO system is not affected as the security lays in SAML and SSL.

High Availability Each web server can run on a physical node which itself is fault-

tolerant by using a RAID23 and redundant power supplies. One server is active and the

others are passive. The active server provides the service to its users while the other servers

check the active server for its availability. If the active server is not longer reachable, one

of the passive nodes takes over the virtual master IP address (figure 37). There exists

solutions like Heartbeat or UCARP [hea] [uca]. If there were active user sessions on this

server, the users would now have to sign on again.

Virtualisation on a virtual server like VMWare ESX [vmw] would also be an option as

this could make the whole server independent from the hardware. In case of a hardware23Redundant Array of Independent Disks

63



3.2 Shibboleth

damage, the virtual machine could be easily migrated to another server and powered on

again. The same mechanism could be used to provide high availability to web resources.

Not only the server hardware but also the network connectivity has to be considered.

The servers should use two NICs24 and connect to two different switches. Both switches

should be connected to the same router. This covers outages of a NIC, switch or problems

with the wiring. In mission-critical environments at least two routers with two uplinks to

the internet should be used. A loop-free network has to be maintained to avoid broadcast

storms. RSTP25 [RST] could be used to block redundant paths and unblock them in case

a link goes down. Figure 37 shows the blocked and unblocked paths.

Figure 37: Redundancy with RSTP, UCARP and RAID

24Network Interface Controller25Rapid Spanning Tree

64



3.3 Summary

3.3 Summary

In this chapter, the two frameworks OpenID and Shibboleth had been analysed. The

main issues of both frameworks are summarised here and compared with each other:

OpenID ShibbolethUser identifier Looks like a URL Looks like an email addressPlatforms PHP, Phyton, Ruby, .NET,

JavaAll languages supported byApache and IIS, the IDPneeds to run in an applica-tion server

Single sign-on No, not really: The user stillhas to provide his userID toeach resource. The pass-

word is needed only onceduring the whole session

Yes

Single Log Out No NoSession Management Needs to be implemented by

the developerBuilt-in in the webserverwrapper module

Security Not secure by default, canbe secured

Secure by default

Complexity Easy to set up Complex, needs thought-out design

Back-ends Loosely coupled - all Back-

ends possible

Loosely coupled - all Back-

ends possibleAttributes Fixed set of attributes Set of attributes can be ex-

tendedPrivacy User can control attribute

releaseUser can control attributerelease

Closed user groups No, OpenID trusts everyone Yes, SP and IDP need totrust each other

User identity verification User identity cannot be ver-ified as OpenID is user-centric

User identity is maintainedby an organisation

Message Structure Key-value pairs SAML (XML)Table 6: OpenID vs. Shibboleth

User experience With Shibboleth, the user has only to provide his userID and pass-

word once. The SP redirects the user to the WAYF, where the WAYF already knows the

home IDP and gets a new assertion for the SP. In OpenID, the user always has to provide

his identifier. OpenID can therefore not be called a SSO system - rather a ’everywhere

the same password’- or ’simplified SSO’-system.

65



3.3 Summary

Integration and Implementation All applications that want to use OpenID need

modifications. As long as OpenID is not supported by the developer himself, the system

operator always needs to modify the code after each upgrade. In Shibboleth, applications

often do not to have be modified, as they often trust the environment variables from

Apache. Shibboleth simply modifies this environment seen by the application. This is

definitely a plus for Shibboleth. It would be nice if OpenID could also provide a wrapper

which supplies environment variables like Shibboleth.

Attribute Exchange and Data Privacy Both frameworks allow the exchange of

attributes. Attributes can be easily added with Shibboleth, as long as all SPs know the

new name. With OpenID this is not possible, as nobody can deploy the new attributes

to all RPs due of its decentralised architecture. If a new attribute is needed on all RPs,

a new OpenID spec needs to be published.

Security OpenID leaves a lot of security unanswered, but Shibboleth fulfils all require-

ments. In OpenID, RPs trust anyone with a valid OpenID identifier whereas Shibboleth

SPs only allow users affiliated to the federation. Shibboleth makes it easy to enforce terms

of licence e.g. libraries granting access only to members of universities.

66



4 Conclusions and Outlook


Technologies needed to authenticate a user at a web server were discussed and how these

technologies could be used for SSO. While comparing the native technologies to each other

it showed up that cookies are a predestined means for SSO. A properly Identity Man-

agement is necessary to ensure valid userIDs. In a federation also the reference between

userID and real person needs to be validated. Security needs to be ensured with help of

a PKI and signed X.509 certificates. Shibboleth doesn’t allow unknown 3rd-party users

and SPs. It can be used to establish a trust-relationship between all members.

SSO eases the handling for all users in web applications. The user needs only one pass-

word and can use all participating SSO web servers. The complexity of SSO systems is

fortunately not seen by the user. It is hard work for system operators to setup a well

working SSO system but they will be rewarded with happy users. Credentials (especially

passwords) are not longer transmitted to 3rd-party web servers. This helps to use re-

sources outside the corporate LAN without any drawbacks in security.

The problem ’one password - all accounts’ still remains. If an attacker can obtain a

valid userID and password, he can impersonate the victim and access all resources with

the victims authorization level. Sometimes all kind of SSO systems have to be disabled

to protect resources with confidential information. A good choice of mitigating phising

is to use strong authentication mechanism at the IDP e.g. use of token cards. The user

still needs to verify the web site where he enters his credentials to prevent phising. With

strong X.509 certificates this shouldn’t be a problem.

The analysis of web authentication mechanism explains, why SSO is rarely deployed

within organisations: Standalone web applications without any design are setup fast.

They are by default often configured to work standalone with local back-ends. To enable

SSO a lot of planning has to be done untill it is fully functional: The location, contentand connection of a back-end need a thought-out design so it can be used with a lot of

67




applications. Years ago, it was hard to design and setup an SSO system. With OpenID

and Shibboleth exists two powerful and free frameworks which eases the implementation

for system operators.

Outlook Shibboleth is more powerful than OpenID and fulfils all requirements in a

productive environment. Unfortunately Shibboleth is also more complex than OpenID.

Private users prefer OpenID due of its simplicity. OpenID provides a life-long personal

userID. Shibboleth identities can only be used as long as an user is affiliated with an

organization or as long as that organization exists. OpenID will evolve and will more and

more be adopted on the web. This can be also seen on Google Trends (figure 38).

Figure 38: Google Trends: OpenID vs. Shibboleth comparison

Single Log out is still a problem but targeted on the roadmap to the next Shibboleth

release. The Shibboleth developers also announced they would like to offer more support

for OpenID as authentication mechanism [shik].

The user-centric approach with OpenID does not ensure the users real identity as it

is the user who manages himself. Google is therefore not trusting other OPs. As long as

the big players doesn’t open their SPs to other OPs, the use of OpenID will be limited to

some small sites in the community. Facebook announced to support OpenID identifiers

from other OPs [fac]. Maybe this animates other big Players to support OpenID identi-

fiers from other OPs, too.

The market for SSO services e.g. consulting will increase, as it is a competitive factor to

68




provide SSO capabilities for consumers. Old legacy applications without SSO capabilities

will still remain but more and more vanish into thin air. New web applications will be

designed to support SSO and replace those old legacy applications. The winner will be

the end-user.

69



5 Acknowledgments

5 Acknowledgments

I would like to thank all persons who helped me with my master dissertation:

• Dr. Tatiana Kalganova for supervising me.

• Ralf Gross (my colleague) for filling in my workplace while I was writing this master

dissertation.

• The computer center of the university of applied science Esslingen for hosting my

test-setup.

• Switch26 and DFN27 for the good documentation and support of all my questions

to Shibboleth.

• STZ Softwaretechnik (my employer) for sponsoring my master course.

• Tom Green and Ansgar Hoffmann for proof-reading.

26Swiss science network27Germany‘s National Research and Education Network

70



6 References

6 References

References

[ACGV98] Paul Ashley, Joris Claessens, Gary Gaskell, and Mark Vandenwauver.

Intranet security technologies - sesame or ssl?

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.1270,

1998.

[apaa] Apache: Authentication, authorization and access control.

http://httpd.apache.org/docs/2.0/howto/auth.html#

whatotherneatstuffcanido.

[apab] Apache: Client authentication with ssl certificates.

http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#

accesscontrol.

[apac] Apache htpasswd - manage user files for basic authentication.

http://httpd.apache.org/docs/2.2/programs/htpasswd.html.

[apad] Apache http server project.

http://httpd.apache.org/.

[bas] Simple online base64 tool.

http://gtools.org/tool/base64-encode-decode/.

[bro] Security issues present in browser password management.

http://www.info-svc.com/news/2008/12-12/.

[bug] Bugmenot: Bypass compulsory registration.

http://www.bugmenot.com.

[cooa] Cookie example: Login.

https://cookie-login.cervicek.hs-esslingen.de/.

71



REFERENCES

[coob] Cookie example: Resource.

https://cookie-resource.cervicek.hs-esslingen.de/.

[cur] curl: Command line tool for http actions.

http://curl.haxx.se/.

[dfn] Dfn support pages.

https://www.aai.dfn.de/dokumentation/.

[fac] Inside facebook: ”facebook announces users will soon be able to login to

facebook via openid”.

http://www.insidefacebook.com/2009/04/27/

facebook-announces-users-will-soon-be-able-to-login-to-facebook-with-an-

[fira] Firebug plugin.

https://addons.mozilla.org/en-US/firefox/addon/1843.

[firb] Mozilla firefox, portable edition.

http://portableapps.com/apps/internet/firefox_portable.

[Gro03] Thomas Groß. Security analysis of the saml single sign-on browser/artifact

profile.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.136,

2003.

[hea] Heartbeat.

http://linux-ha.org/.

[htta] Httpfox plugin.

https://addons.mozilla.org/en-US/firefox/addon/6647.

[httb] Rfc 2617: Http authentication: Basic and digest access authentication.

http://tools.ietf.org/html/rfc2617.

[idp] Shibboleth example: Identity provider.

http://idp.cervicek.hs-esslingen.de/.

72



REFERENCES

[ins] Bugtraq search results for ”insecure cookie”.

http://search.securityfocus.com/swsearch?metaname=alldoc\&query=

Insecure+Cookie.

[int] Internet2.

http://www.internet2.edu/.

[JRGA02] Paul N. Weinberg James R Groff (Author). SQL: The Complete Reference,

Second Edition (Paperback). McGraw-Hill Osborne Media, 2002.

[kee] Keepass password safe.

http://keepass.info/.

[ker] Kerberos: The network authentication protocol.

http://web.mit.edu/kerberos/.

[md5] The md5 message-digest algorithm.


[NS04] Sidharth Nazareth and Sean W. Smith. Using spki/sdsi for distributed mainte-

nance of attribute release policies in shibboleth. Technical report, Dartmouth

College, 2004.

[oas] Organization for the advancement of structured information standards (oasis).

http://www.oasis-open.org/.

[opea] Google: Federated login for google account users with openid.

http://code.google.com/apis/accounts/docs/OpenID.html.

[opeb] Openid.

http://openid.net/.

[opec] The openid directory - find enabled websites.

http://openiddirectory.com/.

[oped] Openid enabled: Libraries for openid.

http://www.openidenabled.com.

73



REFERENCES

[opee] Openid example: Identifier on a private homepage.

http://id.cervicek.hs-esslingen.de.

[opef] Openid example: Openid provider with phpmyid.

http://phpmyid.cervicek.hs-esslingen.de.

[opeg] Openid example: Relying party #1.

http://rp1.cervicek.hs-esslingen.de.

[opeh] Openid example: Relying party #2.


[opei] Openid provider.

http://openid.net/get/.

[opej] Openid/debian prng/dns cache poisoning advisory.

http://seclists.org/fulldisclosure/2008/Aug/0123.html.

[opek] The register: ”how poor crypto housekeeping left openid open to abuse”.

http://www.theregister.co.uk/2008/08/13/openid_phish_risk/.

[opel] Zdnet: ”openid at risk due to dns flaw, warns researcher”.

http://news.zdnet.co.uk/security/0,1000000189,39461045,00.htm.

[phpa] Php class ’auth’.

http://pear.php.net/package/Auth/.

[phpb] Php: Hypertext preprocessor.

http://www.php.net.

[phpc] phpmyid.

http://siege.org/projects/phpMyID/.

[PM] Andreas Pashalidis and Chris J. Mitchell. Impostor: A single sign-on system

for use from untrusted devices.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.5435.

74



REFERENCES

[PM03] Andreas Pashalidis and Chris J. Mitchell. A taxonomy of single sign-on sys-

tems. In Information Security and Privacy, 8th Australasian Conference,

ACISP 2003 , pages 249–264. Springer-Verlag, 2003.

[PW02] Birgit Pfitzmann and Michael Waidner. Privacy in browser-based attribute

exchange. In In Proceeding of the ACM Workshop on Privacy in the Electronic

Society , pages 52–62. ACM Press, 2002.

[rfc] rfc2965: Http state management mechanism.


[RST] Ieee 802.1w: Rapid spanning tree.

http://www.ieee802.org/1/pages/802.1w.html.

[sha] Us secure hash algorithm 1 (sha1).


[shia] Members of uk federation.

http://www.ukfederation.org.uk/content/Documents/MemberList.

[shib] Shibboleth.

http://shibboleth.internet2.edu/.

[shic] Shibboleth: Addresschecking security feature.

https://spaces.internet2.edu/display/SHIB/AddressChecking.

[shid] Shibboleth: Building a federation.

https://spaces.internet2.edu/display/SHIB2/BuildAFederation.

[shie] Shibboleth enabled applications and services.

https://spaces.internet2.edu/pages/viewpage.action?pageId=11484.

[shif] Shibboleth example: Lazy sessions.

http://sp1.cervicek.hs-esslingen.de/lazysession/.

[shig] Shibboleth example: Lazy sessions.

http://aai.kuleuven.be/shibboleth/examples/lazysessions/.

75



REFERENCES

[shih] Shibboleth example: Service provider #1.


[shii] Shibboleth example: Service provider #2.


[shij] Shibboleth list of federations.

https://spaces.internet2.edu/display/SHIB/ShibbolethFederations.

[shik] Shibboleth: Openid support.

https://spaces.internet2.edu/display/SHIB2/OpenIDSupport.

[shil] Shibboleth support pages.

https://spaces.internet2.edu/display/SHIB2/Home.

[swia] Aaiportal project.

http://aai-portal.sourceforge.net/.

[swib] Switch: Authentication and authorization infrastructure (aai).

http://www.switch.ch/aai/.

[swic] Switch: Authentication separated from authorisation.

http://switch.ch/aai/about/.

[swid] Switch support pages.

http://switch.ch/aai/support/.

[swie] Switch viewer.http://sp1.cervicek.hs-esslingen.de/secure-all/viewer/.

[sxi] Sxipper openid firefox plugin.

http://www.sxipper.com.

[TAH03] Gordon S. Good Timothy A. Howes, Mark C. Smith. Understanding and

Deploying LDAP Directory Services. Addison-Wesley Professional, 2003.

[tes] Testshib: Testing new shibboleth sps and idps.

http://testshib.org/.

76



LIST OF FIGURES

[tls] Transport layer security protocol.

http://tools.ietf.org/rfcmarkup/5246.

[tom] Apache tomcat.

http://tomcat.apache.org/.

[uap] Switch uapprove.

http://www.switch.ch/aai/support/tools/arpviewer.html.

[uca] Common address redundancy protocol.

http://www.ucarp.org/project/ucarp.

[vmw] Vmware esx.

http://www.vmware.com/products/vi/.

[wora] Openid-plugin for wordpress.

http://wordpress.org/extend/plugins/openid/.

[worb] Wordpress: A blog publishing application.

http://wordpress.org/.

List of Figures

1 User authenticates at web server . . . . . . . . . . . . . . . . . . . . . . . . 5

2 User database stored on web application server . . . . . . . . . . . . . . . 7

3 Independent local user databases . . . . . . . . . . . . . . . . . . . . . . . . 84 Responsibilities of user administration . . . . . . . . . . . . . . . . . . . . . 9

5 Local user databases provisioned by corporate user database . . . . . . . . . 10

6 Single User Login: Web applications use corporate user database . . . . . . 10

7 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

8 Authentication separated from authorisation [swic] . . . . . . . . . . . . . . 12

9 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10 IP based access to a web server . . . . . . . . . . . . . . . . . . . . . . . . 15

11 Certificate User Identification Request . . . . . . . . . . . . . . . . . . . . . 17

77



LIST OF FIGURES

12 Browser asks for credentials . . . . . . . . . . . . . . . . . . . . . . . . . . 18

13 Browser sends authorization header . . . . . . . . . . . . . . . . . . . . . . 18

14 A Portal server in front of legacy web applications . . . . . . . . . . . . . . 21

15 Restricted Area: Not authorized . . . . . . . . . . . . . . . . . . . . . . . . 28

16 Login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

17 Login page: Authorized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

18 Restricted Area: Authorized . . . . . . . . . . . . . . . . . . . . . . . . . . 30

19 Logout response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

20 SSO domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

21 Logo of OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

22 WordPress OpenID-plugin used by the comment function . . . . . . . . . . 33

23 Homepage as identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

24 Authentication with OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . 38

25 Authentication at phpMyID . . . . . . . . . . . . . . . . . . . . . . . . . . 42

26 Releasing attributes to a relying party . . . . . . . . . . . . . . . . . . . . . 42

27 Attributes received by a relying party . . . . . . . . . . . . . . . . . . . . . 4228 Secure Login at MyOpenID.com . . . . . . . . . . . . . . . . . . . . . . . . 44

29 Logo of Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

30 Authentication with Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . 50

31 Accessing a resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

32 Authentication at a IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

33 Authorized access to a resource . . . . . . . . . . . . . . . . . . . . . . . . 51

34 WAYF server from ukfederation.org . . . . . . . . . . . . . . . . . . . . . . 52

35 Latency while connecting to a web server . . . . . . . . . . . . . . . . . . . 53

36 Shibboleth: Relationship between the components . . . . . . . . . . . . . . . 53

37 Redundancy with RSTP, UCARP and RAID . . . . . . . . . . . . . . . . . 64

38 Google Trends: OpenID vs. Shibboleth comparison . . . . . . . . . . . . . . 68

78



LISTINGS

Listings

1 Apache configuration for IP based access . . . . . . . . . . . . . . . . . . . 15

2 Apache configuration for SSL client authentication . . . . . . . . . . . . . . 16

3 Apache configuration for authorisation . . . . . . . . . . . . . . . . . . . . 19

4 Apache: URL Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Apache: Redirect via Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Flat file: Creating user name and password . . . . . . . . . . . . . . . . . . 23

7 Flat file: Apache configuration for HTTP Basic Authentication . . . . . . . 23

8 SQL: Creating user name and password . . . . . . . . . . . . . . . . . . . . 24

9 SQL: Creating user name and password . . . . . . . . . . . . . . . . . . . . 24

10 LDAP: Creating user name and password . . . . . . . . . . . . . . . . . . . 25

11 LDAP: Authentication with PHP . . . . . . . . . . . . . . . . . . . . . . . 26

12 LDAP: Apache configuration for HTTP Basic Authentication . . . . . . . 27

13 Set a cookie with PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

14 Linking to an OP in HTML (shortened) . . . . . . . . . . . . . . . . . . . 36

15 phpMyID: Defining credentials . . . . . . . . . . . . . . . . . . . . . . . . . 36

16 phpMyID: Defining attributes . . . . . . . . . . . . . . . . . . . . . . . . . 41

17 SAML request (shortened) . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

18 SAML response (shortened) . . . . . . . . . . . . . . . . . . . . . . . . . . 55

19 SAML response form (shortened) . . . . . . . . . . . . . . . . . . . . . . . 56

20 Apache: Protecting a resource with Shibboleth . . . . . . . . . . . . . . . . 57

21 Environmental variables with Shibboleth (shortened) . . . . . . . . . . . . 58

22 Lazy Session: Log in link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

23 Lazy Session: Apache configuration . . . . . . . . . . . . . . . . . . . . . . 59

24 Shibboleth: Log out link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

79



Interim Report


Patrick Cervicek

February 9, 2009

Supervisor: Dr. Tatiana Kalganova

Course: MSc Distributed Computing Systems Engineering

Student Name: Patrick Cervicek

Student ID: 0733018



CONTENTS

Contents

1 Introduction 3

2 Background 4

2.1 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Authentication, Authorization and Accounting . . . . . . . . . . . . . . . . 4

3 Initial Survey 6

3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Central directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 User-centric Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Aims and Objectives 11

5 Experimental Methods to be adopted 12

6 Time Table 12

7 Deliverables and specific outcomes 14

8 References 15

2



1 Introduction

1 Introduction

Web users today are faced with a lot of different web applications. To use these web ap-

plications, the users have to authenticate themselves by entering a login ID and password

(figure 1).

Figure 1: User authenticates at web server

Usually, this has several disadvantages:

• Consistency: If a user changes a password, it is still unchanged on all other web

applications.

• Ease of use: Users have to remember all passwords on each system. If they do not,

passwords have to be reset.

• Uniqueness of userID: The preferred userID could be already used by another user,

which doubles the problem of forgotten passwords.

• Multiple authentication: Even if a user uses the same ID and password, he still has

to authenticate to each web application by typing in his userID and password.

This master dissertation wants to show, how the user can use the same userID/password

for all applications (Single User Login)1. Furthermore, techniques are discussed how the

user can log in only once to a server and being recognized by other applications laying on

other servers without having to login again (Single sign-on)2.

This dissertation wants to give an overview of the necessary architecture and summarize

some eligible techniques to reach these two goals. These techniques will be compared

against each other and be analyzed for certain scenarios.

1SUL2SSO

3



2 Background

2 Background

This chapter shows some basic terms and describes its usage.


Each person in a homogeneous IT infrastructure need a personal userID. Identity manage-

ment covers the management of the identity life cycle of these userIDs: Adding a userID,

moving a userID, change (for example, reset a password) and delete a userID (e.g. the

user is not longer employed)

2.2 Authentication, Authorization and Accounting

Access control is ensured by the principle of AAA3. System operators want to ensure, that

only valid users can login to a resource4. At first users need to be authenticated . In the

easiest case the user needs to provide a userID and password. The sent userID/password

are compared with the data stored on the resource (figure 2).

Figure 2: User database stored on web application server

Upon this authentication, the users can be given access to a resource - the user is then

authorized to access it. Depending on the service, the user could be charged for resources

he used e.g. on a video-on-demand website, this could be downloading a video. The

accounting ensures with a log, that the user pays for those (and only for those) movies he

downloaded.

The more different web applications the user uses, the more accounts need to be created as

each web application works independent from the others. This can be seen in companies

3Authentication, Authorization and Accounting4here: web application

4



2.2 Authentication, Authorization and Accounting

with old legacy applications, where no identity management is properly set up (figure 3).

Each application has its own local data store which needs to be maintained by system

operators and users. These ’silos’ are simple to set up as it ’just works’. The problems

come later, when there are more applications. Another example is the internet with its

huge variety of web applications. This causes problems for the user (chapter 1).

Figure 3: Independent local user databases

System operators have to ensure, that only eligible users may have an account to a re-

source. When a user is no longer employed within his organisation, this account needs to

be locked. When this user has decentralized accounts on different resources, it’s hard to

lock them as all resources have to be manually browsed for this account. This increases

the price of managing user identities.

5



3 Initial Survey

3 Initial Survey

The responsibility to manage the user accounts can lie at the organisation the user belongs

to or can lie at other places (figure 4). A user database can be stored at a central location,

where the data is administered within an organisation. Only the organisation itself is

responsible for the user administration. There is often a central user directory stored on

a SQL5- or a LDAP6 server, but it could also be a big text file. [JRGA02] [TAH03] [apaa]

In a very simple setup, the web applications are not connected to this central user direc-

tory. Each user is created individually on each web application. Provisioning (chapter

3.1) or the connection to a central user directory (chapter 3.2) can improve that situation.

The user database can also be distributed where the user administration is delegated.

The accounts can be administrated by a an organisation participating in a federation

(chapter 3.3) or user-centric by the user himself (chapter 3.4).

Figure 4: Responsibilities of user administration

5Structured Query Language6Lightweight Directory Access Protocol

6



3.1 Provisioning

3.1 Provisioning

Legacy applications do not allow the use of a central user database, therefore the local

database needs to be provisioned (figure 5). There are commercial solutions which allow

with help of a ’synchronisation application’ to take the userID/password from a central

place and provision the local database of each web application. The userID on the resource

doesn’t necessarily be the same as the userID in the central user database. This can

be accomplished with a ’user mapping’. Some ’synchronisation applications’ can also

reconcile accounts from this store back to the central user database.

Figure 5: Local user databases provisioned by corporate user database

3.2 Central directory

Centralized user accounts decrease the complexity for users and system operators. The

user ID and password (also know as ’user credentials’) stays the same on the whole domain

(figure 6). This is called ’Single User Login’.

7



3.3 Federation

Figure 6: Single User Login: Web applications use corporate user database

3.3 Federation

There is often a case, where an organisation wants to allow other organisations to use

their resources without creating a new account for them. If they would do so, the users

would have to create new accounts with all known problems (chapter 1).

Example: A university wants to allow all members of other universities to user their e-

Learning application. To accomplish that, this university would join a federation with

other universities (figure 7). In a federation, the user accounts are managed locally at the

organisation, but the authorisation takes place at the resources’ site. This means that

a user from organisation A may use resources of organisation B. Each university would

have to provide a so-called ’Identity Provider’, which handles the authentication for their

own users, but the authorisation is done at the resource of the other federation members.

The federation of the Switch-AAI [swi] accomplishes this by dividing authentication and

authorisation among each other (figure 8). Without AAI, a member of university A would

need an account at university B to log in to an e-Learning application at university B.

With AAI, the application of university B asks university A7 and trusts, that the response

7more exactly: its identity provider

8



3.3 Federation

Figure 7: Federation

”This user is an member of university A” is correct and allows (authorises) the access to

e-Learning. The user only needs one userID and password and is logged in (authenticated )

to AAI. Each resource in the AAI federation now trusts the identity and the role of this

user. AAI also enables single sign-on (chapter 3.5).Shibboleth is an implementation used by many federations [shi].

Figure 8: Authentication separated from authorisation (Source: http://www.switch.ch)

9



3.4 User-centric Identity

3.4 User-centric Identity

With a user-centric identity, the account of a user is not administrated by an organisation.

It is the user who controls his identity and his attributes.

OpenID is a standard for a single sign-on system, which offers a decentralized user-centric

identity.[ope] The form of an OpenID-ID looks like a URL8 .e.g. http://john.doe.example.com

The user can use this userID on all openID-enabled applications.

3.5 Single sign-on

Single sign-on is a method, which helps users to log in only once to a single sign-on

domain . All resources within this domain will not ask again for a userID and a password.

The basic architecture of a single sign-on method consists of an authentication server

and at least one resource (figure 9). The user needs to log in once to the authentication

server. The authentication server issues a so-called ’ticket’, in which the authentication

server assures that the ticket owner is a valid user of the domain. When the user shows

this ticket to a resource within this domain, the resource accepts this ticket and allows

the user to use the resource. This can be compared with an identity card issued by the

government. Single sign-on solves the necessity of sending a password to each resource.

Only the authentication server needs to know the credentials.

A user of one domain can also use the resources of another domain, when a cross realm

trust had prior been established. Many cross realm trusts result often in a federation, as in

a federation each participating domain only has to trust one central site which introduces

new domains to existing domains.

8Uniform Resource Locator

10



4 Aims and Objectives

Figure 9: Single sign-on

4 Aims and Objectives

This dissertation wants to study the complexity and summarize the essentials for an or-

ganisation to enable SUL and Web SSO. A well-known authentication protocol which

provides also single sign-on capabilities is Kerberos [ker]. Microsoft Windows uses Ker-

beros to allow its users to use all services within the same domain. This takes place on the

operating system layer. In this dissertation the focus lies on Web SSO which takes place

in the user browser, as we want to get the same SSO behaviour for non-Windows-users.

For Web SSO this dissertation will focus on OpenID and Shibboleth as these are freestandards.

These standards will be compared against each other focusing on:


• architecture: Which roles exist in this setup?


and authenticity?

11



5 Experimental Methods to be adopted


• end user experience in the browser: What is the look and feeling for the user?


5 Experimental Methods to be adopted

There are some books about identity management which can be applied in this disserta-

tion. [boo03], [Ben05], [Win05], [Tod07]

To study the Web SSO frameworks OpenID and Shibboleth, there a several tools needed.

A virtual server will speed up the tests as there is no special hardware needed to test

the frameworks. In the SUL scenario there will be one Apache web server [apab] and

a central user directory. In the Web SSO scenario there will be a virtual server for

an ’authentication server’ and a ’resource’. With a browser the user experience will be

tested. The network sniffer will be used to validate the specifications. The Frameworks

are analysed based on the questions in chapter 4.

6 Time Table

The master dissertation has to be written beside of a full-time job. A holiday of two weeks

has already been agreed on with the company. A Gantt chart has been prepared (figure

10) to plan this dissertation. A big time has been spent on the initial survey to study the

possibilities for SUL and Web SSO. The first step in the dissertation is implementing a

SUL setup with a web sever as SUL is less complex than a Web SSO implementation. The

second step is to find libraries to implement the 2 Web SSO solutions. For an OpenID

implementation 5 days are planned and for a Shibboleth implementation 10 days as a

federation has to be set up to test it. The evaluation should be only 2 days long as the

results should not vary from the specifications.

The dissertation has to be sent in 03/30/2009 at Brunel.

12



6 Time Table

Figure 10: Timetable

13



7 Deliverables and specific outcomes

7 Deliverables and specific outcomes

The deliverables of this master dissertation are:

• Clear understanding of SUL and Web SSO

• Example for a single user login setup with an database

• Two Web SSO implementations with OpenID and Shibboleth

• Comparison between OpenID and Shibboleth

• Advice under which circumstances OpenID or Shibboleth should be used

14



8 References

8 References

References

[apaa] Apache htpasswd - manage user files for basic authentication. http://httpd.

apache.org/docs/2.2/programs/htpasswd.html.

[apab] Apache http server project. http://httpd.apache.org/.

[Ben05] Messaoud Benantar. Access Control Systems: Security, Identity Management

and Trust Models. Springer, 2005.

[boo03] Enterprisewide Identity Management: Managing Secure and Controllable Ac-

cess in the Extended Enterprise Environment . IT Governance Institute, 2003.

[JRGA02] Paul N. Weinberg James R Groff (Author). SQL: The Complete Reference,

Second Edition (Paperback). McGraw-Hill Osborne Media, 2002.

[ker] Kerberos: The network authentication protocol. http://web.mit.edu/

kerberos/.

[ope] Openid. http://openid.net/.

[shi] Shibboleth. http://shibboleth.internet2.edu/.

[swi] Switch: Authentication and authorization infrastructure (aai). http://www.

switch.ch/aai/.

[TAH03] Gordon S. Good Timothy A. Howes, Mark C. Smith. Understanding and

Deploying LDAP Directory Services. Addison-Wesley Professional, 2003.

[Tod07] Dobromir Todorov. Mechanics of User Identification and Authentication: Fun-

damentals of Identity Management . Auerbach Publications, 2007.

[Win05] Phillip Windley. Digital Identity . O’Reilly, 2005.

15



LIST OF FIGURES

List of Figures

1 User authenticates at web server . . . . . . . . . . . . . . . . . . . . . . . . 3

2 User database stored on web application server . . . . . . . . . . . . . . . 4

3 Independent local user databases . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Responsibilities of user administration . . . . . . . . . . . . . . . . . . . . . 6

5 Local user databases provisioned by corporate user database . . . . . . . . . 7

6 Single User Login: Web applications use corporate user database . . . . . . 8

7 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8 Authentication separated from authorisation (Source: http://www.switch.ch) 9

9 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

10 Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Date post:	06-Apr-2018
Category:	Documents
Upload:	nexhita
View:	216 times
Download:	0 times