Master Dissertation / Authentication in web applications

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 fulfillment of the requirements for the degree of Master

of Science

Authentication in web applications

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 7

2 Components for Identity Management 9

2.1 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Central directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.3 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.4 User-centric Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Single User Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 IP based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 Password Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.5 X.509 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.6 HTTP Basic Access Authentication . . . . . . . . . . . . . . . . . . 19

2.2.7 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.8 Back-ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.9 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Analysis and Implementation 33

3.1 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

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

3.1.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.3 Integration and Implementation . . . . . . . . . . . . . . . . . . . . 38

3.1.4 Attribute Exchange and Data Privacy . . . . . . . . . . . . . . . . 40

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

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

3.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3

LIST OF FIGURES

3.2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.4 Integration and Implementation . . . . . . . . . . . . . . . . . . . . 55

3.2.5 Attribute Exchange and Data Privacy . . . . . . . . . . . . . . . . 60

3.2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.7 Clustering and High Availability . . . . . . . . . . . . . . . . . . . . 61

4 Conclusions and Outlook 63

5 Acknowledgments 67

6 Appendix 68

List of Figures

1 User authenticates at web server . . . . . . . . . . . . . . . . . . . . . . . . 7

2 User database stored on web application server . . . . . . . . . . . . . . . 9

3 Independent local user databases . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Responsibilities of user administration . . . . . . . . . . . . . . . . . . . . . 11

5 Local user databases provisioned by corporate user database . . . . . . . . . 12

6 Single User Login: Web applications use corporate user database . . . . . . 12

7 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8 Authentication separated from authorisation (Source: http://www.switch.ch) 14

9 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

10 IP based access to a web server . . . . . . . . . . . . . . . . . . . . . . . . 17

11 Certificate User Identification Request . . . . . . . . . . . . . . . . . . . . . 19

12 Browser asks for credentials . . . . . . . . . . . . . . . . . . . . . . . . . . 19

13 Browser sends authorization header . . . . . . . . . . . . . . . . . . . . . . 20

14 A Portal server in front of legacy web applications . . . . . . . . . . . . . . 22

15 Restricted Area: Not authorized . . . . . . . . . . . . . . . . . . . . . . . . 29

16 Login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

17 Login page: Authorized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

18 Restricted Area: Authorized . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4

LISTINGS

19 Logout response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

20 SSO domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

21 Logo of OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

22 WordPress OpenID-plugin used by the comment function . . . . . . . . . . 34

23 Homepage as identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

24 Authentication with OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . 39

25 Authentication at phpMyID . . . . . . . . . . . . . . . . . . . . . . . . . . 41

26 Releasing attributes to a relying party . . . . . . . . . . . . . . . . . . . . . 42

27 Attributes received by a relying party . . . . . . . . . . . . . . . . . . . . . 42

28 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 Shibboleth: Relationship between the components . . . . . . . . . . . . . . . 52

36 Redundancy with RSTP, UCARP and RAID . . . . . . . . . . . . . . . . . 63

37 Latency while connecting to a web server . . . . . . . . . . . . . . . . . . . 65

38 Google Trends: OpenID vs. Shibboleth comparison . . . . . . . . . . . . . . 66

Listings

1 Apache configuration for IP based access . . . . . . . . . . . . . . . . . . . 17

2 Apache configuration for SSL client authentication . . . . . . . . . . . . . . 18

3 Apache configuration for authorisation . . . . . . . . . . . . . . . . . . . . 20

4 Apache: URL Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Apache: Redirect via Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Flat file: Creating user name and password . . . . . . . . . . . . . . . . . . 24

7 Flat file: Apache configuration for HTTP Basic Authentication . . . . . . . 24

5

LISTINGS

8 SQL: Creating user name and password . . . . . . . . . . . . . . . . . . . . 25

9 SQL: Creating user name and password . . . . . . . . . . . . . . . . . . . . 25

10 LDAP: Creating user name and password . . . . . . . . . . . . . . . . . . . 26

11 LDAP: Authentication with PHP . . . . . . . . . . . . . . . . . . . . . . . 27

12 LDAP: Apache configuration for HTTP Basic Authentication . . . . . . . 28

13 Set a cookie with PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

14 Linking to an OP in HTML (shortened) . . . . . . . . . . . . . . . . . . . 37

15 phpMyID: Defining credentials . . . . . . . . . . . . . . . . . . . . . . . . . 37

16 phpMyID: Defining attributes . . . . . . . . . . . . . . . . . . . . . . . . . 41

17 SAML request (shortened) . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

18 SAML response (shortened) . . . . . . . . . . . . . . . . . . . . . . . . . . 54

19 SAML response form (shortened) . . . . . . . . . . . . . . . . . . . . . . . 54

20 Apache: Protecting a resource with Shibboleth . . . . . . . . . . . . . . . . 55

21 Environmental variables with Shibboleth (shortened) . . . . . . . . . . . . 57

22 Lazy Session: Log in link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

23 Lazy Session: Apache configuration . . . . . . . . . . . . . . . . . . . . . . 58

24 Shibboleth: Log out link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6

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 recognised 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.

1SUL2SSO

7

1 Introduction

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

in more detail:

• 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 feeling 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 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

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.

8

2 Components for Identity Management

2 Components for Identity Management

System operators want to ensure, that only valid users can login to a resource3. 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

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).

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.

3here: web application

9

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

10


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 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 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.

2.1.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’.

11


Figure 5: Local user databases provisioned by corporate user database

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

12


2.1.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.

Figure 7: Federation

The federation of the Switch-AAI [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 A6 and trusts, that the response

”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)

6more exactly: its identity provider

13

2.2 Authentication and Authorization

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.2). There is one special case, where one

organisation wants to ensure that only members affiliated to them can use the ressources.

This is called local federation. This is mainly used for intranet applications which should

be SSO-enabled, but not beeing used by other organisations.

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

Figure 8: Authentication separated from authorisation (Source: http://www.switch.ch)

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 one is” Finger print, voice (recognition)

When two method from the same category are used, this is called 2-Means authentication.

When two method from different categories are used, this is called 2-Factor authentica-

tion. This is also know as ”strong authentication” and should be used in confidential areas.

14


HTTP offers several mechanisms to accomplish authentication and session management

which will be discussed in this chapter.

2.2.1 Single User Login

2.2.2 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.9). 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

(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 use 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.

2.2.3 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

15


Figure 9: Single sign-on

with an ACL7. The user is authorized to access the web server with its source IP adress.

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 adresses are spoofable and are therefore not appropriate to authenticate

users. 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 VPN8 solution to get an internal

IP. This would not scale in an environment, where the users are in different networks.

However, a combination with IP based ACL and authentication 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 documentation[apaa].

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

16


Figure 10: IP based access to a web server

# IP based acces s f o r h t t p :// hos t / s e c u r e u r l

<Locat ion / s e c u r e u r l />

Order Deny , Allow # by d e f a u l t : Deny everybody

Deny from a l l

# Allow a l l c l i e n t s in . b rune l . ac . uk domain

Allow from . brune l . ac . uk

# in case hos t i s not in DNS, then use IP range o f Brunel Un i v e r s i t y

Allow from 134.83

</Location>

Listing 1: Apache configuration for IP based access

2.2.4 Password Manager

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

words and fill them into 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 password manager can therefore be only used on the same machine. Other-

wise 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 pass-

word management e.g. The destination where passwords are sent is not checked [bro]

which aids phising.

17


2.2.5 X.509 Certificates

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

Instead of manually log in to a web server, users could login by simply showing a X.509

Certificate to the web server. If a PKI9 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 this user certificates.

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

SSL client authentication enables 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 au t h en t i c a t i on needed

SSLVer i fyCl ient none

# Pub l i c Key o f C e r t i f i c a t e Author i ty

SSLCACert i f i cateFi l e / e t c /apache2/ca . c r t

<Locat ion / s e c u r e u r l />

# requ i r e c l i e n t au t h en t i c a t i on f o r h t t p s :// hos t / s e c u r e u r l

SSLVer i fyCl ient r e qu i r e

SSLVerifyDepth 1

</Location>

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

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 get lost, it needs to be revoked over certificate revoke list Using certificates

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

9Public key infrastructure

18


Figure 11: Certificate User Identification Request

2.2.6 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 successfully authentication, the browser

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

a kind of session management.

Figure 12: Browser asks for credentials

19


Figure 13: Browser sends authorization header

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.

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

for 2 URLs.

<Locat ion / l o g i n / te s t1>

# al l ow access to / l o g i n / t e s t 1 on ly f o r user t e s t 1

r e qu i r e user t e s t 1

</Location>

<Locat ion / l o g i n / te s t2>

# al l ow access to / l o g i n / t e s t 1 on ly f o r user t e s t 2

r e qu i r e user t e s t 2

</Location>

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.9) are better as they have a unique session id, issued independent from the

20


user password. This session id can also be issued by another & hardened web server

(chapter 2.2.2).

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

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

URLs, this could be a form of SSO. Unfortunately, with Basic and Digest Access Authen-

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

There exists also an second authentication method in HTTP called Digest access authen-

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

and password with a challenge-response mechanism before transmitting it. This requires

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

stored password in 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.

2.2.7 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 application 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 access the applications in behalf of the user. Examples to accomplish this:

URL Rewriting The portal appends a parameter to the calling URL and delegate au-

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

legacy application (listing 4).

Redirecting The user access an 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.

21


In all cases the web application needs to unconditionally trust the portal. This solution

does not scale well and should be rarely used.

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

RewriteEngine on

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

RewriteRule ˆ / ( . ∗ ) http :// app l i c a t i on1 . example . com/? u s e r i d=%{LA−U: \

REMOTE USER} [QSA,P,L ]

# . . . . a l t e r n a t i v e l y forward as HTTP Header

# in s t ead o f appending an parameter

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

#RewriteRule . − [E=RU:%1]

#RequestHeader add X−Forwarded−User %{RU}e

Listing 4: Apache: URL Rewriting

22


# Redi rec t http :// app l i c a t i on2 . example . com/

# over http :// po r t a l / app l i c a t i on1

ProxyPass / app l i c a t i on2 / http :// app l i c a t i on2 . example . com/

ProxyPassReverse / app l i c a t i on2 / http :// app l i c a t i on2 . example . com/

Listing 5: Apache: Redirect via Proxy

2.2.8 Back-ends

To authenticate and authorise a user, the credentials needs to be stored in 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-end10 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 setup. 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. The more users an application has, flat files would not scale

well.

10here: Apache web server

23


$ cd /var /www/http−bas ic−auth

$ htpasswd −s −b . htpasswd t e s t 1 t e s t 1

$ htpasswd −s −b . htpasswd t e s t 2 t e s t 2

$ cat . htpasswd

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

te s t 2 :{SHA}EJ9LPFDXsN9ynSmbxvjp75Bmlx8=

Listing 6: Flat file: Creating user name and password

#### Authent i ca t ion

<Direc tory /var /www/http−bas ic−auth/ log in>

# Text f o r the user

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

# use HTTP Basic Authen t i ca t ion

AuthType Bas ic

# use a t e x t f i l e as backend

AuthBasicProvider f i l e

# lo ca t i o n o f the t e x t f i l e

AuthUserFile /var /www/http−bas ic−auth / . htpasswd

# any v a l i d user may l o g in to / l o g i n

r e qu i r e va l id−user

</Directory>

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 an 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.

24


$ mysql −h l o c a l h o s t −u admin −P password userdatabase −e \

’ i n s e r t i n to t b l a u t h u s e r ( u s e r i d , user password ) \

VALUES ( ’ t e s t1 ’ , SHA( ’ te s t1 ’ ) ) ;

Listing 8: SQL: Creating user name and password

### Database Management

# use the MySQL dr i v e r

DBDriver mysql

# database name and 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 Bas ic

# use a SQL se r v e r as back−end

AuthBasicProvider dbd

# lo ca t i o n o f the t e x t f i l e

AuthDBDUserPWQuery \

"SELECT user_password FROM tbl_auth_user WHERE user_id = %s"


</Directory>

Listing 9: SQL: Creating user name and password

LDAP A LDAP11 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

11Lightweight Directory Access Protocol

25


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

looking 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 PEAR12 [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-backend (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 to different departments. In large envi-

ronments a directory server is therefore predestinated as back-end.

$ cat myuser . l d i f

dn : uid=tes t1 , ou=People , dc=cerv i c ek , 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 : person

o b j e c t c l a s s : o r gan i za t i ona lPe r son

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

cn : Test User One

sn : Doe

givenname : John

uid : t e s t 1

userpassword : {SHA}tESsBmE/yNY3lb6a0L6vVQEZNqw=

$ ldapmodify −h l o c a l h o s t −D "cn=admin" −w password −f myuser . l d i f

Listing 10: LDAP: Creating user name and password

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

26


<?php

r equ i r e on c e "Auth.php" ;

$opt ions = array (’host’ => ’localhost’ ,

’port’ => ’389’ ,

’version’= 3 ,

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

’userattr’ => ’uid’ ,

’useroc’ => ’person’ ) ;

$auth = new Auth(’LDAP’ ,

$opt ions ,

$ l og inFunct ion = ’my_login_function’ ,

$showLogin = true ) ;

// s t a r t au t h en t i c a t i on

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

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

// s e c t i on f o r au t h en t i c a t e d users

}

else {

// s e c t i on f o r not au t h en t i c a t e d user s

}

// l o g out user

$auth−>l ogout ( ) ;

?>

Listing 11: LDAP: Authentication with PHP

27






AuthType Bas ic

# use a LDAP ser ve r as back−end

AuthBasicProvider ldap

# Location o f the server , a t t r i b u t e f o r username

AuthLDAPURL ldaps :// l o c a l h o s t /ou=People , dc=cerv i c ek , dc=de? uid ?one


</Directory>

Listing 12: LDAP: Apache configuration for HTTP Basic Authentication

2.2.9 Cookies

HTTP13 is a stateless protocol. This means the web server does never know, who it is

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

to create and use user sessions [rfc]. When a user first login to 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 there could be establish a form of SSO.

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.15 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).

13Hypertext Transfer Protocol14http://www.netscape.com15In reality the user would have to authenticate with a user name and password

28


Figure 15: Restricted Area: Not authorized

Figure 16: Login page

Figure 17: Login page: Authorized

29


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

$key = "MasterDissertation" ; // name o f the cook ie

$value = "1234567890" ; // t h i s i s the unique key

$ exp i r e s = time ( ) +3600; // key shou ld e xp i r e a f t e r one hour

$path = "" ; // no r e s t r i c t i o n to the path

$domain = ".cervicek.hs-esslingen.de" ; // the name o f the SSO domain

$ s ecure = 1 ; // cook ie has to be sen t over h t t p s

setcookie ( $key , $value , $exp i r e s , $path , $domain , $ s ecure ) ;

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

somebody else. 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 realy deletes the

cookie, it additionally set the expire date back to the past.

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 they are untrusted (figure 20). If an untrusted

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

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

30


Figure 18: Restricted Area: Authorized

Figure 19: Logout response

31


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, there exists some cookie-based frameworks which will be

discussed in the next chapter.

Figure 20: SSO domain

32

3 Analysis and Implementation

3 Analysis and Implementation

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

and how these technologies could be used for SSO. Cookies offer the best possiblitiy for

Web SSO. 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

details of the frameworks can be found online.

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 gives 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

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 OPs 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 with OpenID enabled Relying Parties is already

huge and still growing [opec]

33

3.1 OpenID

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

OpenIDs of an 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

3.1.1 Terminology

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

tion on which you will be able to understand the information provided in this and next

chapters.

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

to login to different web sites using his/her credentials stoopred at the Identity

Provider.

34

3.1 OpenID

Identifier Each End User has at least one userID in form of an URL16

.e.g. http://john.doe.example.com. 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 user

logs 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.o as well as in some other lit-

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

RP.

User Agent 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 from 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

registered OpenID Relying Parties.

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 needs to change the link and still

keeps his homepage as identifier.

16Uniform Resource Locator

35

3.1 OpenID

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 HTML17 (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 setup

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

features.

Figure 23: Homepage as identifier

17Hyper Text Markup Language

36

3.1 OpenID

<html>

<head>

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

<l ink rel="openid.server"

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

<l ink rel="openid.delegate"

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

</head>

<body>

. . . <h2>Welcome to my OpenID user page </h2> . . .

</body>

</html>

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

$GLOBALS[ ’profile’ ] = array (

’auth_username’ => ’test’ ,

’auth_password’ => ’37fa04faebe5249023ed1f6cc867329b’ ,

### Password generated wi th

### echo −n ’ t e s t : phpMyID : t e s t ’ | opens 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 it is private

homepage with a delegated identifier.

37

3.1 OpenID

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

to this from.

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 adds also a ’ticket’ to this

redirect-URL.

8. The browser goes back to the RP and shows this ticket. The RP accepts this 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 then would not have to type in

his identifier again. This does not help when an other 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’.

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]

38

3.1 OpenID

Figure 24: Authentication with OpenID

39

3.1 OpenID

• Relying Party #2 [opeh]

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

the web applications on the SPs needs to be modified to accept only User IDs from the

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

applications: Updates needs 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

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

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

and use corporate directory to lookup attributes.

3.1.4 Attribute Exchange and Data Privacy

OpenID allows to transfer user defined attributes to be transmitted 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 extened by the

operators itself. 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.

40

3.1 OpenID

$GLOBALS[ ’sreg’ ] = array (

’nickname’ => ’Patrick-OpenID’ ,

’email’ => ’patrick@phpmyid -sreq.spamtrap.hs-esslingen.de’ ,

’fullname’ => ’Patrick C.’ ,

’country’ => ’DE’ ,

’language’ => ’de’ ,

’timezone’ => ’Europe/Berlin’

) ;

Listing 16: phpMyID: Defining attributes

Figure 25: Authentication at phpMyID

Communication There is nearly no direct communication between the RP and 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 supplied

by the user is not tampered. 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.

41

3.1 OpenID

Figure 26: Releasing attributes to a relying party

Figure 27: Attributes received by a relying party

42

3.1 OpenID

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 requires 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, this

is 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.5) is also possible.

There exists a Firefox plugin named Sxipper which helps user to avoid typing their pass-

words on faked sites [sxi]. 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

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

43

3.1 OpenID

Figure 28: Secure Login at MyOpenID.com

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 2nd time. OpenID uses DNS to resolve the OP.

When the OP and RP exchanges 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 establish an encrypted connection. Diffie-Hellman does not verify the authenticity

of the communication partners is prone for man-in-the-middle attacks.

The usage of https identifier could mitigate this 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 SAML18, 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 unites 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 on which you will be able to understand the information provided in this and 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.

18Security Assertion Markup Language

45

3.2 Shibboleth

Discovery Service ”Where are you from?” (WAYF) When a user visits a SP the

first time, it needs to determine the identity of the user. The SP therefore needs to

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, where the SP 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 needs to ensure that they maintain a correct identity management

system. All users within a IDP needs to be correct classified e.g. staff, stud, guest.

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

locked. All participants needs 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

• SOAP19-endpoints for the Shibboleth daemon

• Administrative contact

All participants have a local copy of this databases, 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 needs 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 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

sends redirects him automaticaly to its home IDP.

6. The browser redirects the user to SP

19Simple 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 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 1).

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 the

correct 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 an 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. 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 1: SAML Authentication Request

12. The SP redirects the browser back to 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 to ask again for a SAML Assertion

at the IDP. The user can now access the Shibboleth protected resource (figure 33).

3.2.3 Architecture

A short overview of the protocol flow has been shown in section 3.2.2. Figure 35 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 SHIRE. It determines

whether the user has already logged in to the 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. 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.

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

Figure 35: Shibboleth: Relationship between the components

52

3.2 Shibboleth

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

the RM and checks the users 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.

<samlp:AuthnRequest

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

Assert ionConsumerServiceIndex="1"

Dest inat i on=

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

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

<s am l : I s s u e r xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

h t t p s : // sp1 . c e r v i c e k . hs−e s s l i n g e n . de/ sh ibbo le th−sp

</ s am l : I s s u e r>

<samlp:NameIDPolicy AllowCreate="1"/>

</ samlp:AuthnRequest>

Listing 17: SAML request (shortened)

53

3.2 Shibboleth

<?xml version="1.0" encoding="UTF-8"?>

<samlp:Response

Des t ina t i on=

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

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

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

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

<s am l : I s s u e r

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

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

h t t p s : // idp . t e s t s h i b . org / idp / sh ibbo l e th

</ s am l : I s s u e r>

. . .

</ samlp:Response>

Listing 18: SAML response (shortened)

<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)

54

3.2 Shibboleth

3.2.4 Integration and Implementation

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

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

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

[idp]

• Service Provider #1 [shih]

• Service Provider #2 [shii]

The shibboleth daemon is a module which can be used in the IIS20 or the apache web

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

directive (listing 20).

<Locat ion / secure−a l l> # prot e c t http :// sp1/ secure−a l l

AuthType sh ibbo l e th

Sh ibRequ i reSes s ion On

r equ i r e va l id−user

</Locat ion>

<Locat ion / secure−s t a f f o n l y> # prot e c t http :// sp1/ secure−s t a f f o n l y


Sh ibRequ i reSes s ion On

r equ i r e a f f i l i a t i o n ˜ ˆ Staf f@ # only ’ S ta f f ’ u s e r s a l lowed

</Locat ion>

Listing 20: Apache: Protecting a resource with Shibboleth

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

first time to a shibboleth protected resource, 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.

20’Internet Information Server’ from Microsoft21In this dissertation the focus lies on the module for the apache web server.

55

3.2 Shibboleth

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

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

[shik].

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 with a

special viewer page [swid].

Existing applications often do not have to be modified, as they are already enabled for

HTTP Basic Auth and using the environment variable REMOTE USER. Applications

which use an own session management can be shibbolized by modifying the authentication

handler to use the REMOTE USER environment variable. To force uniqueness of the

UID within the federation, the mail address could be used instead of REMOTE USER.

In comparison to REMOTE USER the email address contains not only the UID but also

the domain of the user.

56

3.2 Shibboleth

<html>

. . .

<h2>Su c c e s s f u l l y authent i ca ted @ / secure−a l l − a l l authent i ca ted \

use r s a l lowed</h2>

Authent icated as <b><?=$ SERVER[ "eppn" ] ?></b><p>

A f f i l i a t i o n : <b><?=$ SERVER[ "affiliation" ] ?></b> environment

< !−− When us ing HTTP−Headers : <?=$ SERVER[ "HTTP_EPPN" ] ?> −−>

. . .

</html>

Listing 21: Environmental variables with Shibboleth (shortened)

The function of shibd can be verified with following URLs:

https://sp.example.org/Shibboleth.sso/Session Shows session detailshttps://sp.example.org/Shibboleth.sso/Logout Removes shib sessionhttps://idp.example.org/idp/profile/Status Shows simply ”OK”

Lazy Session Usually the web server handles the authentication when a certain location

is called. Sometimes a application wants to implement a second way to authenticate users

which are not registered within the federation. Normally these are guests-accounts. When

an application decides itself to use shibboleth, it just needs to provide a redirect or a link

to the session initiator of Shibboleth (listing 22). A small demo site has been prepared

and tested with a log in link [shif]. Apache needs the keyword ShibRequireSession to be off

(listing 23). Using lazy sessions increases the security risks a little bit, as the developer

has to take care that the user is already authenticated. Cookies are a good 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].

57

3.2 Shibboleth

<a href="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

<Locat ion / l a z y s e s s i on >


Sh ibRequ i reSes s ion Off

r e qu i r e sh ibbo l e th

</Location>

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.

5. Set up a 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].

58

3.2 Shibboleth

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.7. It support e-learning applications

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 there the session, 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 all valid sessions to IDPs and SPs are removed. This

may 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 kind of SSO systems on resources with confidential information anyway.

<a href="/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

59

3.2 Shibboleth

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 min-

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

signed it is not a security risk to the federation. This make it easy for company 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 needs 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 obtain user consent. 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 sent it’s attribute 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 the attributes to the

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

attribute exchange.

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.

[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:

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.

60

3.2 Shibboleth

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

3.2.6 Security

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

• All transmission are encrypted with strong ciphers

• All SPs and IDPs need own X.509 certificates signed by 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

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

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 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 reminds the server IP and is

therefore ”sticky-session” aware.

61

3.2 Shibboleth

Sometimes companies use more than one outgoing IP in their proxies. Shibboleth by

default does not accept alternating source IPs during one session. Shibboleth does this

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].

High Availability Each web server can run on a physical node which itself is fault-

tolerant by using a RAID22 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

checks 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 36). 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 Virtualserver like VMWare ESX [vmw] would also be a option as this

make the whole server independent from hardware. In case of a hardware damage the

virtual machine could be easily migrated to an other server and powered on again. The

same mechanism could be uses 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 2 NICs23 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. RSTP24 [RST] could be used blocks redundant paths and unblocks them in case

a link goes down. Figure 36 shows the blocked and unblocked paths.

22Redundant Array of Independent Disks23Network Interface Controller24Rapid Spanning Tree

62

4 Conclusions and Outlook

Figure 36: Redundancy with RSTP, UCARP and RAID


The main disciplines of both frameworks are summarised here and compared against each

other

User experience With Shibboleth, the user has only to provide its user id and password

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 note be called a SSO system - rather a ’everywhere the

same password’- or ’simplified SSO’-system.

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

authentication process. There are 3 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-exchange is initiated before user data or SAML assertions can

be 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

63


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 37 shows the the latency which can occur while trying to access a web server. When

the user types in an URL in the browser, the browser needs to lookup the IP address of the

webserver. 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 webserver on port 80. TCP

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

set. The operating system responds 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 webserver 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.

Integration and Implementation All applications which want to use OpenID needs

a modification. 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 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.

Attribute Exchange and Data Privacy Both framework allow the exchange of at-

tributes. Attributes can be easily added with Shibboleth, as long as all SPs need to know

the new name. With OpenID this is not possible, as nobody can deploy the new attribute

to all all RP due of its decentralised architecture. If a new attribute is needed on all RPs

a new OpenID spec needs to be published.

64


Figure 37: Latency while connecting to a web server

65


Security OpenID lets a lot of security questions open, but Shibboleth fulfils all require-

ments

Outlook Shibboleth is more complex than OpenID and therefore mainly used by or-

ganisations. Shibboleth is more powerful than OpenID and fulfils all requirements in a

productive environment. OpenID should only be used in an private environment.

Private users prefer OpenID due of its simplicity. This can be also seen on Google Trends

38.

Figure 38: Google Trends: OpenID vs. Shibboleth comparison

The use of cookies prevents phising of credentials at the web servers. Some users are

concerned about data privacy and disable the use of cookies in its browser. Unfortunately

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

have a problem.

Shibboleth fulfils nearly all demands on security, privacy and should be the preferred

SSO system. Single Log out is still a problem but on the roadmap to the next Shibboleth

release.

The analysis of both frameworks explains, why SSO is rarely deployed within organi-

sations: Standalone web applications without any design are fast setup. They are by

default often configured to work standalone with local back-ends. To enable SSO a lot of

planning has to be done till it is fully functional: The location, content and connection

of a back-end so it can be used with a lot of applications.

66

5 Acknowledgments

5 Acknowledgments

I would like 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

• Switch25 and DFN26 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

25Swiss science network26Germany‘s National Research and Education Network

67

6 Appendix

6 Appendix

References

[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/.

[coob] Cookie example: Resource.

https://cookie-resource.cervicek.hs-esslingen.de/.

[cur] curl: Command line tool for http actions.

http://curl.haxx.se/.

68

http://httpd.apache.org/docs/2.0/howto/auth.html#whatotherneatstuffcanido

http://httpd.apache.org/docs/2.0/howto/auth.html#whatotherneatstuffcanido

http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#accesscontrol

http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#accesscontrol

http://httpd.apache.org/docs/2.2/programs/htpasswd.html

http://httpd.apache.org/

http://gtools.org/tool/base64-encode-decode/

http://www.info-svc.com/news/2008/12-12/

http://www.bugmenot.com

https://cookie-login.cervicek.hs-esslingen.de/

https://cookie-resource.cervicek.hs-esslingen.de/

http://curl.haxx.se/

REFERENCES

[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-openid/.

[fira] Firebug plugin.

https://addons.mozilla.org/en-US/firefox/addon/1843.

[firb] Mozilla firefox, portable edition.

http://portableapps.com/apps/internet/firefox_portable.

[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/.

[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.

69

https://www.aai.dfn.de/dokumentation/

http://www.insidefacebook.com/2009/04/27/facebook-announces-users-will-soon-be-able-to-login-to-facebook-with-an-openid/

http://www.insidefacebook.com/2009/04/27/facebook-announces-users-will-soon-be-able-to-login-to-facebook-with-an-openid/

https://addons.mozilla.org/en-US/firefox/addon/1843

http://portableapps.com/apps/internet/firefox_portable

http://linux-ha.org/

https://addons.mozilla.org/en-US/firefox/addon/6647

http://tools.ietf.org/html/rfc2617

http://idp.cervicek.hs-esslingen.de/

http://search.securityfocus.com/swsearch?metaname=alldoc\&query=Insecure+Cookie

http://search.securityfocus.com/swsearch?metaname=alldoc\&query=Insecure+Cookie

http://www.internet2.edu/

REFERENCES

[kee] Keepass password safe.

http://keepass.info/.

[ker] Kerberos: The network authentication protocol.

http://web.mit.edu/kerberos/.

[md5] The md5 message-digest algorithm.


[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.

[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/.

70

http://keepass.info/

http://web.mit.edu/kerberos/


http://www.oasis-open.org/

http://code.google.com/apis/accounts/docs/OpenID.html

http://openid.net/

http://openiddirectory.com/

http://www.openidenabled.com

http://id.cervicek.hs-esslingen.de

http://phpmyid.cervicek.hs-esslingen.de

http://rp1.cervicek.hs-esslingen.de


http://openid.net/get/

REFERENCES

[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/.

[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.

71

http://seclists.org/fulldisclosure/2008/Aug/0123.html

http://www.theregister.co.uk/2008/08/13/openid_phish_risk/

http://news.zdnet.co.uk/security/0,1000000189,39461045,00.htm

http://pear.php.net/package/Auth/

http://www.php.net

http://siege.org/projects/phpMyID/


http://www.ieee802.org/1/pages/802.1w.html


http://www.ukfederation.org.uk/content/Documents/MemberList

http://shibboleth.internet2.edu/

https://spaces.internet2.edu/display/SHIB/AddressChecking

https://spaces.internet2.edu/display/SHIB2/BuildAFederation

REFERENCES

[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/.

[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 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 support pages.

http://switch.ch/aai/support/.

[swid] 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.

72

https://spaces.internet2.edu/pages/viewpage.action?pageId=11484

http://sp1.cervicek.hs-esslingen.de/lazysession/

http://aai.kuleuven.be/shibboleth/examples/lazysessions/



https://spaces.internet2.edu/display/SHIB/ShibbolethFederations

https://spaces.internet2.edu/display/SHIB2/Home

http://aai-portal.sourceforge.net/

http://www.switch.ch/aai/

http://switch.ch/aai/support/

http://sp1.cervicek.hs-esslingen.de/secure-all/viewer/

http://www.sxipper.com

REFERENCES

[tes] Testshib: Testing new shibboleth sps and idps.

http://testshib.org/.

[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/.

73

http://testshib.org/

http://tools.ietf.org/rfcmarkup/5246

http://tomcat.apache.org/

http://www.switch.ch/aai/support/tools/arpviewer.html

http://www.ucarp.org/project/ucarp

http://www.vmware.com/products/vi/

http://wordpress.org/extend/plugins/openid/

http://wordpress.org/