authentication and authorization - uu.diva-portal.org344199/fulltext01.pdf · ti cation,...

28
IT 10 036 Examensarbete 15 hp Augusti 2010 Authentication and Authorization Achieving Single Sign-on in an Erlang Environment Fabian Alenius Institutionen för informationsteknologi Department of Information Technology

Upload: tranquynh

Post on 25-Aug-2018

233 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

IT 10 036

Examensarbete 15 hpAugusti 2010

Authentication and Authorization

Achieving Single Sign-on in an Erlang Environment

Fabian Alenius

Institutionen för informationsteknologiDepartment of Information Technology

Page 2: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing
Page 3: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Authentication and Authorization

Fabian Alenius

Forcing users to enter their credentials every time they want to use a service isassociated with several problems. Common problems include lowered userproductivity, increased administration costs and security issues. As companies andorganizations are adding more services to their networks, it is becoming anincreasingly important problem. By allowing users to sign on once and centralizingaccess control decisions, it is possible to reduce or completely mitigate this problem.This paper describes how a service written in Erlang was modified to allow for singlesign-on and centralized access control.

Tryckt av: Reprocentralen ITC

Sponsor: KreditorIT 10 036Examinator: Anders JanssonÄmnesgranskare: Björn VictorHandledare: Erik Stenman

Page 4: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing
Page 5: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Chapter 1

Introduction

In this paper we will study the problems associatedwith authentication and access control in corporate net-works. We retrofit an existing service to enable singlesign-on and centralize access control. The design de-scribed in chapter 4 will show how to enable single sign-on, by using a network authentication server to verify usercredentials. We will also show how to centralize autho-rization decisions with the help of a directory server. Theproblems that were encountered during the implementa-tion are discussed together with their solutions.

1.1 Background

Because password authentication is so easy to implement,it is the most commonly used authentication method [9].When using password based authentication, the relativesecurity of individual passwords can vary. For example,a longer password is more secure than a short password.Yan et al. [18] conducted a study on password securitywhere they found that good passwords should be longand random. While good for security, these restrictionsincrease users difficulty in remembering their passwords.Users who forget their password need help from the help-desk to retrieve or reset their password. If one user for-gets his or her password, it’s typically not a problem.However, in a large corporation or organization it’s notuncommon to have several password-related issues everyday [1]. There are also security problems related to for-gotten passwords. Users who often forget their passwordssometime resort to writing them down. Passwords lyingaround for anyone to see is a disaster to network security.The problem with passwords only worsens as the numberof services on the network increase.

There are very tangible costs related to password au-thentication. Fortunately there are solutions, as we willsee in chapter 3. However, in a study that surveyed IT

administrators, Ahlborg and Halsjo [1] found that whileadministrators were aware of the problems, they wereunable to fix them. The reason cited by the adminis-trators was that the problem of retrofitting existing ser-vices range from difficult to impossible. For example, thesource-code for old legacy services that are no longer inactive development is often hard to obtain. In practice,this makes retrofitting these services an impossible task.

1.2 Problem definition

A typical corporate network offers a wide range of ap-plications and services, but before a user can utilize theservices, the user has to login. The user has to authenti-cate themselves (sec. 2.2) . A simple way to authenticateusers is to supply them with usernames and passwords.The problem with passwords is that they are hard to re-member. In general, the better a password is, the harderit is to remember [18]. This is especially true if users needto remember a different password for each service. Theproblems associated with authentication have greatly in-creased with the introduction of web-services in corporatenetworks. Today it’s not uncommon for users to authenti-cate themselves 25 times per day [13]. One way to reducethis number is by enabling single sign-on(SSO) on thenetwork. SSO enables users to sign on once and not haveto retype their passwords during the session, even as theyutilize different services.

Another problem on large networks is that of autho-rization: all users should not have the same access rights.For example, a customer service representative should nothave access to financial data, while someone working inthe financial department should not have access to per-sonnel files. In a network that provides a wide rangeof services, management of access control can become aserious burden. By centralizing authorization decisions,

5

Page 6: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

management can be simplified, while at the same timealleviating the problem of managing user accounts acrossdifferent services. In this paper we conduct a case studyin which we retrofit a service to use SSO. We also cen-tralize authorization decisions with the help of a LDAPserver (sec. 3.3). Specifically, we will show how to:

• Enable single sign-on for a web service using a Ker-beros server (sec 3.1).

• Provide fallback to username/password authentica-tion for users that can’t directly communicate withthe Kerberos server.

• Centralize authorization using a directory server.

• Enable single sign-on for a service written in Erlang.

1.3 The case

Kreditor AB, which we will refer to as simply Kreditor,is a Stockholm-based financial organization that offers fi-nancial services over the internet. Kreditor is growingvery fast: in the last year alone, they have increasedfrom 70 to 130 employees. As the number of employeeshas increased, so has the effort required to manage theusers. Kreditor uses a directory server to store employeerecords. The records hold information such as employeenames, email addresses, passwords, and more. The direc-tory server makes it possible to look up employees and seewhat departments they belong to. Kreditor uses a Ker-beros server to authenticate the users on their network,Kerberos is described in section 3.1.

Kreditor has one primary service that almost all em-ployees use, the kred system, which we will refer to assimply kred. Kred is written in Erlang, a programminglanguage that according to its creator Joe Armstrong [2]was designed for writing concurrent programs that “runforever”. Because Kreditor has very high reliability de-mands on their services, this is an important property.Embedded in the kred system is a web interface namedKreditor Online (KO). KO does not use existing networkinfrastructure for authentication and access control. In-stead, KO stores user accounts that are unique to KOand not in any way synchronized with the accounts inthe directory server. Accounts in KO hold a subset ofthe information stored in the directory server, includinga separate username and password. As a consequence,users have to remember two different username/passwordpairs.

Kreditor wished to integrate the authentication andaccess control in KO with the existing infrastructure in or-der to consolidate IT management. Enabling SSO wouldincrease user productivity and cut help-desk costs [1]. Askred is written in Erlang, a language that isn’t widelyused, there is no existing literature or study that cov-ers this exact problem. However, the general solutionoutlined in [15] proved applicable with some small mod-ifications. The specification from Kreditor is outlined insection 4.3 and the subsequent design in section 4.4.

1.4 Motivation

According to a study by the Network Applications Con-sortium (NAC) [12] up to 44 hours a year is spent byemployees solving authentication related problems. Thisis more than one week every year that could be spentdoing something more productive, a huge cost to com-panies that virtually every company has. Centralizingauthentication is often done as an afterthought when theneed becomes apparent. Refitting an enterprise networkto use single sign-on can often be problematic and becomevery expensive. Because of this, studies examining thisproblem should be helpful to companies and organizationsthat are faced with this problem. Because Kreditor’s envi-ronment is somewhat unique, the implementation detailsin this case study are likely to be particularly interesting.

1.5 Related research

Xiong [17] reviews popular web SSO solutions and con-ducts a case study where he presents a design that usesCentral Authentication Service1. The design presented inthis paper is more secure than Xiong’s: it primarily relieson SPNEGO(sec. 3.2.2) for authentication. When CAS isused for authentication, the username and password haveto be sent over the network every time a user wishes toauthenticate his or her identity to a service. With SP-NEGO, this is not necessary. Instead, a token is sent.The details of the design are explained in chapter 4.

Kabay [10] has written a general introduction to iden-tification, authentication and authorization on the WorldWide Web, but does not include a case study. Kabay’spaper also reviews commercial products that are used inthis context.

A common network authentication service used bymany companies is Kerberos (sec. 3.1). Tagg [14] has

1http://www.jasig.org/cas

6

Page 7: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

written an informative paper describing the details ofKerberos, and how it can be used to provide SSO ona corporate network. Samar [13] has written a paperabout cookie-based authentication as an alternative toKerberos.

7

Page 8: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Chapter 2

AAA

The three As in computer security are authentication(sec. 2.2), authorization (sec. 2.3) and auditing (sec. 2.4).The three As are crucial parts of any successful networksecurity scheme. This chapter attempts to define the con-cepts associated with the As and introduce them to theunfamiliar reader. We will also see how they relate tosingle sign-on (sec. 2.5), but first we need to define iden-tification, because it is important to each of the threeAs.

2.1 Identification

Before a user can be authenticated, he first have to gothrough the process of identification.

Definition 1. Identification is the process that enablesrecognition of a user described to an automated data pro-cessing system. This is generally by the use of uniquemachine-readable names [10].

Essentially, it means that the user announces who heis, for example, by providing a username. This is anal-ogous to presenting yourself to someone you have nevermet before. It is important to understand that the iden-tity can still be fake if, for example, the user is lying. Tobe sure of a user’s identity we need some way to verifyit. In the real word we can force a person to show anID-card. Unfortunately, ID-cards are not very useful in acomputer-network setting, but alternatives exist.

2.2 Authentication

Authentication is the process of verifying a provided iden-tity.

Definition 2. Authorization is a positive identification,with a degree of certainty sufficient for permitting certain

rights or privileges to the person or thing positively iden-tified [10].

In computer systems, an identity need not be tied toan actual person. Instead, the identity can represent asystem or a service. Verification can be done in a varietyof ways, depending on the context, but all verificationmethods rely on some factor. A factor is an attribute orproperty that makes it possible to positively identify anindividual. Below, we outline different factors.

What the user knows

This factor, what the user knows, indicates that we au-thenticate based on some information that only the userhas knowledge of. We can give the user a secret passwordthat can be used to verify the user’s identity. Passwordscan be assigned and distributed in different ways. Forexample, the passwords can either be randomly gener-ated or chosen by the user. Based on how the passwordsare generated and distributed, you can divide passwordauthentication into different categories, called passwordschemes [9].

What the user has

The second factor, what the user has, can be combinedwith the first factor or used alone. Verifying a user’sidentity based on this factor means that we authenticateusing something the user has in his possession, such as asecurity token or an ID card.

What the user is

In a computer security context, what the user is typicallyrefers to the biometric properties of the user. If the prop-erties are unique each user, it is possible to authenticatebased on them. For example, fingerprint scanning, retina

8

Page 9: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

scanning and face recognition exploit the fact that certainproperties are unique for each person.

Summary

Any of the factors above is sufficient to authenticate auser, and they are all used to varying degrees. Becauseregular username/password authentication falls into thecategory of what the user knows, it is the most commonmethod [8]. Online banks commonly employ security to-kens in their security solutions, which is why what theuser has is the most common factor in banking [7].

2.3 Authorization

Users who are authenticated can proceed to make re-quests to the system. However, just because a user isauthenticated, it does not mean the user can perform anyoperation. In order for a request to succeed, the requesthas to be authorized. What this means is that the re-quest has to be allowed according to some policy or con-trol mechanism. One such mechanism that can be usedis an Access Control List (ACL). The ACL specifies whatoperations users are allowed to perform [4]. ACLs typi-cally associate an object with a list of users and groups.For every combination of object and user, there is a list ofoperations for each object that the user can perform. Ev-ery time a user wants to perform an operation, a lookupis performed in the ACL to see if the operation is allowed.

2.4 Auditing

Auditing is the process of logging activities in the sys-tem. For example, failed and successful authenticationattempts are often logged. When there is a problem orerror, it is often helpful to review the logs in order to de-termine the root problem. It is possible to detect attacksagainst the system by analyzing the logs.

2.5 Centralization

When users want to log in to a system or service, theyhave to go through the process of authentication. If auser wants to authenticate against two different systems,the user needs to authenticate twice. In a larger setting,such as a company or organization, this becomes imprac-tical very fast as the number of services grows, especiallyif the users have to remember separate usernames and

passwords for each system. Another problem is that themanagement of user accounts becomes complicated as weneed several user accounts for each user. For example, ifwe want to update the address of a user, we could poten-tially need to update a user record in all of our systems.

The solution is to centralize authentication and au-thorization. This means that every time a user has tobe authenticated or authorized, it is done at a central lo-cation. The benefit of centralization is that all the useraccounts are stored in one place so there is no unneces-sary redundancy. For centralization to work in practice,the services on the network have to be able to delegateauthentication and authorization responsibility to a cen-tral server. There are different protocols and applicationsthat can be used to delegate responsibility. For networkauthentication, Kerberos (sec 3.1) is probably the mostcommonly used protocol. To delegate authorization re-sponsibility, the OAuth protocol can be used [11].

One benefit of using centralized authentication is thatit’s potentially possible to allow for single sign-on (SSO),so that users who have entered their credentials once donot have to do so again during the session.

Definition 3. A session is an activity for a period oftime; the activity is access to a computer/network re-source by a user; a period of time is bounded by sessioninitiation (a form of logon) and session termination (aform of logoff) [10].

One way to implement SSO is through the use of tick-ets. Users that has been authenticated can make requestsfor tickets. The tickets enable the users to utilize services.The services can verify the tickets, and thus verify theidentity of the user. The requests of tickets and the sub-sequent transmission of the tickets is done automaticallywithout the user’s knowledge. From the end user’s per-spective, he enters his credentials once and is not botheredagain during the session.

One problem with centralization is that it can cre-ate a single point of failure. If there is only one serverdoing authentication and authorization, then failure ofthat server will cause all services to be inaccessible. For-tunately, most tools that are used for centralization sup-port replication, which enables creation of a second serverthat contains the same information. When the first servergoes down, the second server will take over and continueas if nothing had happened. The second, and probablybiggest, problem with centralization is that of retrofittingexisting services to support delegation. In some cases itis even impossible, such as, if the source code is no longer

9

Page 10: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

available or if the company that originally delivered thecode has failed.

10

Page 11: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Chapter 3

Tools and Protocols

This chapter describes some of the tools and proto-cols that are commonly used in companies and organiza-tions for authentication and authorization. Section 3.1describes Kerberos, a network authentication protocol.Other protocols attempt to standardize authentication;they are described in section 3.2. Finally, in section 3.3we look at LDAP, a directory protocol.

3.1 Kerberos

Kerberos is a computer network authentication protocoldeveloped at MIT. Its name refers to a character fromGreek mythology: Cerberus is a three-headed dog respon-sible for guarding the entrance of the underworld. In asimilar way, Kerberos guards a network, allowing entryonly to those who are authenticated. In this section wewill describe the Kerberos protocol and the concepts asso-ciated with it. The goal is to avoid getting bogged downin technical details. Instead, we attempt to provide anoverview that will allow us to understand how Kerberoscan be used as a central authentication server. Tagg [14]gives a more detailed description.

3.1.1 Terminology and concepts

The first step towards understanding Kerberos is to geta grip on the terminology.

Principals

In Kerberos literature, the term principal is used to de-scribe an entity such as a user or a service. Every user,computer or service that needs to be authenticated is as-sociated with a principal. The principals are authenti-cated based on a long-term key or password that is asso-ciated with every principal.

Realm

Each Kerberos installation defines an administrativerealm that the principals belong to. In other words, aKerberos realm is the set of Kerberos principals that areregistered within a Kerberos server. The common conven-tion is to use a DNS domain name, converted to uppercase, as realm. For example, helloworld.com forms therealm HELLOWORLD.COM.

Tickets

Tickets are a very central concept, because they are usedto verify identities. The tickets are essentially data con-structed in such a way that it becomes possible to authen-ticate the sender. There are two types of tickets, TicketGranting Tickets (TGTs) and service tickets. The TGTis a form of master ticket that is used to ask for servicetickets, and service tickets are used to access the servicesthat are provided on the network.

Key Distribution Center

The Key Distribution Center (KDC) consists of three log-ical parts: a database of all principals, an AuthenticationServer (AS) and the Ticket Granting Server (TGS). Aprincipal who wishes to start a session asks the AS for aTGT. This ticket is then used to ask for service ticketsthat can be sent to individual services. The TGT is en-crypted with the principal’s key so that it is not usableby anyone else. It is important to note that the TicketGranting Server (TGS) and the Ticket Granting Ticket(TGT) are two completely different things.

3.1.2 Putting the pieces together

We will now study the Kerberos protocol to see how userscan authenticate themselves to services on the network.

11

Page 12: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Kerberos actually ensures mutual authentication, mean-ing that the service is authenticated to the user as well.Figure 3.1 shows the steps involved when a client authen-ticates with a service; below we outline the steps in moredetail.

Figure 3.1: Kerberos authentication sequence

Step 1

The client begins the authentication process by requestinga TGT from the AS.

Step 2

The AS returns the TGT. Because the ticket is encryptedwith the client’s password, the ticket is not usable byanyone else. This means that the ticket can be sent overan unencrypted channel.

Step 3

The client sends the TGT to the TGS to request a serviceticket for a specific service.

Step 4

When the TGS receives the TGT, it verifies the TGT andreturns a service ticket to the client.

Step 5

The client sends the service ticket it received in step 4 tothe service in order to begin a session.

Step 6

The service verifies the ticket and sends back a messageencrypted with the session key. Because the ticket is en-crypted with the session key, the client can verify theidentity of the service.

3.1.3 Kerberization

Refitting existing applications and services to use Ker-beros is a common task; in fact the task is so commonthat it has become a verb. To add Kerberos support toan application is called to ”Kerberize”. Specifically howthis is done depends on the particular application. Theeasiest way is to use one of the standardized protocolsor APIs. Alternatively, if a customized protocol is used,it may be possible to fit Kerberos into the customizedprotocol framework.

3.2 Standardized authentication

Many protocols and APIs attempt to standardize authen-tication. In this section we will present some of them andgive brief descriptions. The focus will be on protocols andAPIs that can interact with Kerberos.

3.2.1 GSS-API

GSS-API is an abbreviation for Generic Security ServicesApplication Program Interface. This API provides se-curity services to application programmers. GSS-APImakes it possible to call security services in a standard-ized way. It also shields the programmer from the po-tential complexities of the underlying protocol. MostKerberos implementations provide support for GSS-API,which means that all programs that support GSS-APIalso support Kerberos. The messages sent in a Kerberossession are encapsulated by GSS-API before being sentover the network.

12

Page 13: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

3.2.2 SPNEGO

The biggest problem GSS-API faces is that the applica-tions must agree beforehand what protocol to use. SP-NEGO, which is an abbreviation for Simple and ProtectedGSSAPI Negotiation Mechanism, sets out to solve thisproblem. Using SPNEGO, a client and server can jointlydetermine what protocol to use.

The server sends the client a list of supported pro-tocols and the client picks the strongest protocol it canuse. SPNEGOs greatest benefit is that it is supported byall major web-browsers. By using an SPNEGO enabledweb server and Kerberos it becomes possible to Kerber-ize web services. This method can be used to integrateweb-services into a single sign-on framework, somethingthat is otherwise very difficult.

3.2.3 PAM

Pluggable Authentication Modules is an API that allowsintegration of several low-level authentication schemes.By defining a standard interface for authentication, dif-ferent applications and authentication methods can easilybe integrated. The biggest problem with PAM is that itonly supports username/password authentication, whichmeans that it’s not possible to authenticate Kerberos tick-ets using PAM. It is, however, possible to authenticateagainst a Kerberos server if a user has the principal nameand password. Therefore, PAM can be used to providea fallback method for users that do not have Kerberostickets but do have a valid principal name and password.

3.2.4 SASL

SASL stands for Simple Authentication and SecurityLayer, which is a generic protocol framework for doingvarious sorts of authentication between a client and aserver. The idea is to separate the authentication mech-anism from the application protocol. What this meansis that the application protocols specify an ”applicationprofile” that describes how to encapsulate SASL mes-sages. Within the SASL framework different authenti-cation mechanisms may be used, such as:

• DIGEST-MD5

• OTP One-time Passwords

• Kerberos

• GateKeeper (Microsoft)

SASL is more generic than PAM. For example SASL sup-ports Kerberos mutual authentication using tickets. Notethat application programmers need to explicitly add sup-port for all underlying mechanisms that they want to uti-lize, so in order to add Kerberos support to an applicationusing SASL the programmer needs to explicitly add sup-port for GSS-API.

3.2.5 Summary

It is easy confuse all the different protocols and it is some-times difficult to understand their purposes. In table 3.1we provide a summary intended to make it easier to un-derstand the relationships between the different protocolsand APIs.

Name PurposeKerberos Network authentication protocol.

GSS-API Generic authentication protocol, sup-ports Kerberos as underlying mechanism.

SPNEGO Enables GSS-API to be used over theweb.

PAM Generic API for authentication usingusername/passwords.

SASL Similar to PAM, allows more complexmechanisms.

Table 3.1: Summary of tools and protocols

3.3 LDAP

An LDAP server is a directory server; its most commonuse is as an enterprise management tool [6]. LDAP is anabbreviation for Lightweight Access Directory Protocol.An LDAP server can be used as a central directory forusers, groups and accounts, which stores information suchas usernames, passwords, real names, telephone numbersand email addresses.

3.3.1 History

At its core LDAP is a network protocol designed toretrieve and store data in a X.500 directory (a direc-tory server architecture, designed and standardized in the1980s). The original LDAP servers were thus just gate-ways to the X.500 directories [6]. Today, however, LDAPhas grown into a directory service in its own right, and

13

Page 14: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

now includes the standards needed to operate as a full-fledged directory server.

3.3.2 Directories

A directory can, for example, be a phonebook or a cat-alogue. Because a phonebook is organized in alphabeticorder, it may be searched efficiently. A digital directory isnot very different from its analogue cousin: the purposeof the directory is to organize information and make itsearchable. It should be possible to add and remove in-formation, but it is assumed that modification occurs lessfrequently than searching. A directory server contains oneor more directories, and is optimized so that searching isvery effective [6]. A typical entry in a company personneldirectory might look something like this:

• Name: Joe Average

• Position: Vice President

• Street: Example-street 112

• City: New York

• Postal Code: 23423-3433

• Phone Number: 555-123321

• ObjectClass: person

3.3.3 Distinguished Names

To be able to uniquely identify an entry, we need a wayto distinguish it from the other entries in the directory.This is accomplished by setting a Distinguished Name(DN), which is a concept similar to a key in a relationaldatabases. The DN is a set of attributes associated withthe entry that allows us to uniquely identify the entry.The ObjectClass attribute in the example above is similarto a type declaration and specifies some attributes thatthe entry must include. Here is an example of a DN:CN=Peter, OU=Sales, DC=Example, DC=COM

3.3.4 Directory Information Trees

Entries in a directory are organized into hierarchies. Con-sider an example company Acme. At the top of the hi-erarchy is the company itself, below are the different de-partments such as Accounting and Marketing, and underthe departments are the employees working in the depart-ments. In Figure 3.2 we can see an example directory.

Figure 3.2: Sample Directory Information Tree

3.3.5 LDAP authentication

In order for a user to interact with an LDAP server,the user must first be authenticated; this action is calledbinding. LDAP supports two methods of binding, sim-ple binding and SASL binding. Simple binding is ex-actly what it sounds like, very simple to set up and toadminister. Unfortunately, simple binding is not very se-cure. With Simple Binding, the DN and password aresent in plaintext over the network [6]. Sometimes theLDAP server is configured to allow for anonymous bind-ing, which makes it possible for anyone to view informa-tion without binding first. To allow for more secure com-munication, most LDAP implementations allow for trafficencryption using SSL/TLS. Because LDAP includes sup-port for SASL, LDAP also supports every authenticationmechanism that can be used with SASL.

14

Page 15: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Chapter 4

Case study

This chapter contains a case study of authenticationand authorization centralization. It describes how single-sign on was enabled at a company called Kreditor. Somefundamental information about Kreditor and Kreditor’senvironment is given in section 4.1 and 4.2. The require-ments from Kreditor are described in section 4.3. Thedesign that was developed to meet the requirements isoutlined in section 4.4. Finally, section 4.5 contains im-plementation details and solutions to some of the prob-lems that were encountered.

4.1 Kreditor

Kreditor is a company offering financial services over theinternet. Two services offered are fakturera mig and delaupp betalningen1. The services allow web shops to del-egate credit payments from their customers to a thirdparty, namely Kreditor. Kreditor is growing very fast, inthe last year alone they have increased from 70 to 130 em-ployees2. As the number of users has increased, so has theeffort required to manage the users. Internally, Kreditoruse a Kerberos (sec. 3.1) server for network authenticationand a LDAP (sec. 3.3) server to organize their employees.

At the heart of Kreditor is the kred system that pro-vides Kreditor’s customers with services, and allow Kred-itor’s employees to do their daily jobs. In subsequenttext the kred system will be referred to as simply kred.The problem with kred is that it doesn’t use the exist-ing infrastructure for authorization and authentication;instead, it stores separate user accounts. If kred could beintegrated with Kerberos and the directory server, usermanagement would be simplified and security increased(sec. 2.5).

1http://kreditor.se/tjanster-las-mer/index.html2http://computersweden.idg.se/2.2683/1.219743

4.2 Environment

Kred is written in Erlang, a functional concur-rency oriented programming language. The sys-tem runs on a master/slave pair architecture to im-prove fault tolerance and availability. Kreditor hastwo LDAP servers: ldap1.internal.machines andldap2.internal.machines. Kreditor also has one Ker-beros server: lithium.internal.machines. Users getTGTs from the Kerberos server when they login to theircomputers. Information about employees and groups isstored in the directory server, queries can be sent to thedirectory server to retrieve this information.

4.2.1 Erlang

The development of Erlang began in 1986 at the Erics-son Computer Science Laboratory to design a languageto program telecom switches. Erlang was designed forwriting concurrent programs that ”run forever” [2]. Therequirements were virtually zero downtime and to allowfor hot code swapping, upgrading running code. Erlangmeets these by structuring programs using concurrentprocesses that have no shared memory and use asyn-chronous messages. The requirements of a telecom switchand a financial system are very similar, which is why Er-lang suits Kreditor well. A good book we recommendto anyone who wants to learn Erlang is the introductorybook by Armstrong [3].

4.2.2 Yaws

Kred uses a web interface to allow its employees and cus-tomers to interact with the system. The web pages areserved Yaws, a high performance web server written inErlang. The main benefit of Yaws is that it scales ex-tremely well. In Figure 4.1 we can see a comparison of

15

Page 16: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Yaws versus Apache3. On the horizontal axis is the num-ber of sessions and on the vertical axis is the throughput.Yaws is the red curve while the green and blue curvesshow different Apache configurations. On the graph wecan see that Apache simply dies at around 4000 sessionswhile Yaws can handle over 80 000 parallel sessions.

Figure 4.1: Apache vs Yaws comparison

Yaws authentication

Yaws supports quite a few authentication mechanisms,including username/password, SPNEGO and PAM. It isalso possible to write customized authentication modulesto add new authentication mechanisms. The version ofYaws that was available at the start of this project was1.81, which does not allow for different authenticationmethods to be used concurrently.

Yaws uses the methods embedded in the HTTP pro-tocol, the protocol used to transfer web pages from theweb server to the client, to perform authentication. Firstthe client sends a request; when Firefox makes a requestit looks similar to the contents of Table 4.1. The serverresponse can be seen in Table 4.2. The first 5 lines of theresponse are HTTP headers, the headers are followed bythe content that the web-browser should display.

Marked in bold is the HTTP status, used to indicatethe result of the request. For this request the status is200, which means that the request was successful. Theweb server can use the status to indicate that the clientneeds to authenticate its identity; this is done by set-ting the status to 401. The web server also includes a

3http://www.sics.se/ joe/apachevsyaws.html

list of alternatives that the client can use to authenticateits identity, they are indicated by a preceding ”WWW-Authenticate”.

Sample browser requestGET /example-page.html HTTP/1.1Host: example.comUser-Agent: Firefox/3.0.11Keep-Alive: 300Connection: keep-alive

Table 4.1: Stripped down version of Firefox GET request

Yaws OK responseHTTP/1.x 200 OKServer: Yaws/1.81 Yet Another Web ServerDate: Sat, 04 Jul 2009 13:21:35 GMTContent-Length: 57760Content-Type: text/html<html> .... </html>

Table 4.2: Yaws ”OK” response

Yaws unauthorized responseHTTP/1.1 401 UnauthorizedServer: Yaws/1.81 Yet Another Web ServerDate: Sun, 22 Mar 2009 03:47:47 GMTContent-Length: 63Content-Type: text/htmlWWW-Authenticate: Basic realm=””<html><body><h1>401 authentication needed</h1></body></html>

Table 4.3: Yaws ”unauthorized” response

When the web-browser sees that the status is 401, itattempts to authenticate using the alternatives available.If the web-browser fails, the content will be rendered tothe user, in this case the browser will render a 401 authen-tication needed message. When Yaws attempts to authen-ticate using a method that requires a username and pass-word, it includes the header WWW-Authenticate: Basicrealm=””. This will make the web-browser display a pass-word prompt where the user can enter his username andpassword. A sample of what this looks like in Firefox canbe seen in Figure 4.2. Once the user has entered his cre-dentials, the credentials are added to the HTTP headers

16

Page 17: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

and sent back to the web-server.

Figure 4.2: Firefox password window

When Yaws is configured to authenticate usingSPNEGO the header sent to the client is WWW-Authenticate: Negotiate. When the browser sees theheader it will attempt to fetch a service ticket from theKerberos server for the principal HTTP/[email protected] example, if the domain is example.com andthe realm is COMPANY, then the browser will at-tempt to fetch a service ticket for the principalHTTP/example.com@COMPANY.

Yaws authorization

Yaws has no explicit notion of authorization, if a useris authenticated then he is essentially authorized. Thismeans that if a more sophisticated authorization schemeis needed, the developer will have to design it himself.

4.2.3 Mnesia

Kreditor uses Mnesia as their backend database, Mnesiais a distributed DataBase Management System (DBMS)written in Erlang. It was developed at Ericsson to beused in soft real-time, distributed, and high-availabilityapplications. Mnesia was designed to solve the typicaldata management problems of telecommunications appli-cations. Data is stored in tables similarly to relationaldatabases, with the difference that the data is schemafree. The data is stored as {Key, Value} pairs and lookupsare done based on the key. The values can be of any for-mat.

4.2.4 Kerberos

The Kerberos realm at Kreditor is calledinternal.machines, it runs on the MIT Kerberosimplementation4.

4http://web.mit.edu/Kerberos/

4.2.5 LDAP

Kreditor has two LDAP servers to achieve redun-dancy. If one server crashes, the other server willremain operational. Because the second server isa replication of the first server, the content onthe two servers is identical. The base of the di-rectory is DN=INTERNAL.MACHINES. Underthe base are OU=People and CN=Groups. Em-ployees are placed under People, while the differ-ent departments are placed under Groups. Forexample, the employee John might have the DNUID=john,OU=People,DN=INTERNAL.MACHINES.Employees can become members of groups by havingtheir DNs added to the uniquemember field of the group.An illustration of the directory layout can be seen inFigure 4.3.

Figure 4.3: Kreditor LDAP layout.

4.3 Specification

The requirements from Kreditor were loosely formulated.The core requirement was integration of authenticationand authorization in kred with the existing network in-frastructure. SSO was desirable, but not absolutely nec-essary, which allowed more freedom in the design of thesolution. The goal for the design was to allow for SSOand to capture the advantages of SSO while mitigatingthe disadvantages.

17

Page 18: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

4.4 Design

In this section we describe the design that was presentedto Kreditor. The design uses the existing Kerberos andLDAP servers at Kreditor to perform authentication andauthorization. The solution has been implemented andtested. Below we will describe how the different goals ofcentralized authentication, authorization and SSO wereachieved.

4.4.1 Authentication

Since Yaws already included support for SPNEGO, theprotocol was quickly included in the design, which meantthe design allowed for SSO from the start. However,Kreditor required that there be a fallback method so thatusers without access to the Kerberos server could still lo-gin using their username and password. One potentialsolution to this problem was to use the PAM support inYaws, together with a Kerberos PAM module, to authen-ticate usernames and passwords. A flowchart of the fullauthentication process used in this design can be seen inFigure 4.4.

One problem with this design was that Yaws version1.81 did not allow for multiple authentication methodsto be used concurrently. However, since Yaws is open-source, it was possible to write a patch that would addthis feature. Writing the patch would also give an oppor-tunity to get acquainted with Erlang.

Another problem was related to the fact that the PAMsupport in Yaws uses HTTP Basic authentication. WithBasic authentication, the client authenticates its identityusing a username and password. The web browser asksthe user for a username and password and then sends anew request that includes this information in the HTTPheaders. If the username and password is correct, theweb server responds with status 200 and the requestedcontent.

The problem is that the prompt that the web browserdisplays to the user does not allow feedback to be passedback to the user. A better approach is to use a login pageto provide user feedback and allow for an overall morepleasant experience. However, in Yaws 1.81 it was notpossible to change the content shown with HTTP status401. This feature would have to be added as well. Se-quence diagrams of how SPNEGO and PAM authentica-tion works can be seen in Figure 4.5 and 4.6 respectively.

To encrypt all the traffic and mitigate the disadvan-tages of Basic authentication, all traffic is sent using Se-cure Socket Layer(SSL). The fallback method is less se-

Figure 4.4: Flowchart of the login process.

18

Page 19: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

cure since the username and password has to be sent everytime a user wants to authenticate themselves to kred.

4.4.2 Authorization

In Yaws there is no real notion of authorization separatefrom authentication: if a user is authenticated then he isauthorized. This means that in order to get a more flex-ible authorization scheme, a developer will have to addit. Because kred already had a working authorizationscheme, it could be extended to integrate with the LDAPserver. Authorization in kred is based on the informa-tion stored in four different Mnesia tables called kuser,kuser level, kuser group and kuser page. The finest gran-ularity that authorization can be based on in kred is atthe kuser page level. Kuser pages represent the pages inthe GUI and are stored as Erlang atoms5, but could in

5An Erlang atom is essentially a named constant.

Figure 4.7: ER diagram the authorization scheme in kred.

theory represent any item or concept. Each kuser pageis mapped to at most one kuser group. The kuser groupson the other hand can map to more than one kuser page.

The kuser groups have an attribute called bit thatis used to uniquely identify the group. Since Erlangsupports arbitrarily large integers, there is no limit tothe number of groups. The next level of granularityis at the kuser levels layer, kuser levels map to one ormore kuser groups. Kuser levels have the ability to in-herit groups from other kuser levels, which means thatkuser levels can easily be extended. The kuser levels alsohave a bit number used to uniquely identify the level.

Finally, each user in kred is associated with a kuserrecord. The kuser records contain attributes such as user-name, password and the kuser levels that the user hasaccess to.

19

Page 20: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Figure 4.5: SPNEGO authentication in kred.

Figure 4.6: username/Password authentication in kred using PAM.

20

Page 21: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

An entity-relationship diagram with the relationshipsbetween the tables can be seen in Figure 4.7. Thekuser level has an attribute called perms; this is a bitmapwhere the groups that map to that level have their ID bitset to 1. Kusers are mapped to kuser levels using thesame method.

To illustrate how this works, we will outline whathappens when a user wants to visit a page called sam-ple page.yaws. First the user has to be authenticated,which is done by matching a username and passwordagainst the entries in the kuser table. Every user ses-sion is associated with a site state that is stored in kred.The site state contains the permissions of the user. If au-thentication is successful then a bitmap with the groupIDs that the user has access to is built and stored in thesite state.

First all the kuser levels that the user has access toare retrieved, then all the groups that are mapped to thelevels. The ID bits of the groups the user has access toare set to 1 to construct a bitmap, which is then storedin the site state. When the user visits sample page.yaws,that page is mapped to a group. If the bit associatedwith that group is 1 in the bitmap, then authorization isgranted.

The easiest way to extend this scheme, with the goalof integration with the LDAP server, would have been toadd an attribute to kuser level that maps a kuser level toa LDAP group. However, to update the kuser level table,the table would have to be locked down. On a live systemthis is very problematic. Instead, the solution proposedwas to add a new table called kuser ldap map that wouldmap a kuser level to a set of LDAP groups. This relationis included on Figure 4.7.

4.4.3 Single sign-on

Adding SSO proved to be an easy task because Yaws in-cluded support for SPNEGO. When the web browser seesWWW-Authenticate in the HTTP headers, it automati-cally fetches a Kerberos ticket. For this to work, SP-NEGO must be enabled in the web-browser. Instructionson how to enable SPNEGO in Firefox and Internet Ex-plorer can be found in Appendix A.

4.5 Implementation

The implementation proceeded smoothly and took 7-8weeks. The first step was to set up a test server thatcould be used to test the patch needed for Yaws. Setting

up Yaws, Kerberos and Pam took longer than expected,Kerberos especially was difficult to set up. When thepatch was finished, Yaws had the features needed to im-plement the design.

One interesting problem was that Firefox does notseem to pick the strongest authentication method pro-vided in the HTTP headers. Instead Firefox seems toalways pick the first method provided, regardless of whatother methods are available.

The patch for Yaws was officially released with Yawsversion 1.82 and the details can be found at GitHub6.GitHub is a web-based hosting service for projects thatuse the Git revision control system.

The next problem was to run kred with the new ver-sion of Yaws. The version of Yaws used in kred was amodified version of 1.52. Upgrading to 1.82 introducedsome bugs that had to be fixed before the system couldbe fired up. After some tweaking, both SPNEGO andPAM authentication worked.

Authorization required less time to implement. Theimplementation follows the design described in section4.4.2. Some Erlang libraries that can be used for authen-tication and authorization are briefly described in Ap-pendix B. The Eldap library was used to communicatewith the LDAP servers at Kreditor. Because of the wayauthorization was designed, the information stored in theLDAP server is not modified by kred.

4.5.1 Optimization

One problem with the initial implementation was thatconstructing a list of all users was extremely slow, butrequired for the GUI administration page. The first naiveimplementation took roughly 14 seconds to return a listof all users. Two optimizations were implemented thatdrastically improved performance.

The first problem with the naive implementation wasthat the kuser records were populated in a very in-efficient way. The result from a LDAP query is re-turned in the form of a property list: [{property1,value1},...,{propertyN, valueN}]. The naive ver-sion simply conducted a simple lookup of the propertyit was adding to the kuser record. This meant that forevery attribute, the entire property list could potentiallybe traversed. This gives a complexity of O(n ∗m), wheren is the number of attributes in the record and m is thelength of the list returned from the LDAP query. The al-gorithm was changed so that the property list is traversed

6http://github.com/klacke/yaws/commit/c1cea992847be923ddce1338c115a0f820755f62

21

Page 22: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

once and the record attributes are set as they are found.Since setting an attribute in a record is a constant-timeoperation, populating a record now had a complexity ofm, where m is the length of the attribute list. This mod-ification cut the total retreival time down from 14 to 9seconds, a reduction of 35%.

The second problem was that, because user entrieswere retrieved sequentially, there was a lot of networkoverhead. The retrieval was re-factored so that all entriesare fetched in one query. The entries are then put in anErlang dictionary for constant lookup. The dictionaryis used for the cross matching of LDAP group member-ship and kuser level membership to construct the accessbitmap. This cuts the total computation time down fur-ther to 1.4 seconds, thus giving a total reduction of 90%compared to the initial implementation. In Figure 4.8we can see a comparison of the three different revisions.One improvement that could further improve the perfor-mance would be to parallelize the population of the kuserrecords.

Figure 4.8: Chart of time to create list of all users.

4.5.2 Mapping of usernames

Another problem was that the usernames in the kusertable and the LDAP directory were not exact matches.While most usernames in both cases were of the formfirst-name.last-name, there were some exceptions. Un-fortunately, renaming the usernames was not an optionbecause the usernames were linked to entries in the audit

logs. That link would have been lost if the usernameswere renamed. Instead, every username in the directorywas mapped to their Kreditor Online username.

4.5.3 Character encoding

The next problem was that the data from the OpenLDAPserver is sent encoded in UTF-8 while Erlang primarilyuses Latin-1. UTF-8 is an encoding format of Unicode,which is itself an attempt to standardize character rep-resentation. The primary advantage of UTF-8 is that itkeeps compatibility with ASCII by using one byte to rep-resent the most common characters. Unicode support isnot one of Erlang’s strong points, even though it has beenimproved in the latest version. The character encodingproblem was solved by first converting the data into Uni-code and then from Unicode to Latin-1.

4.5.4 Redundancy

The new authentication scheme introduced a single pointof failure, which had to be mitigated. Kerberos is set upso that it employs two servers. If kred cannot connectto the first Kerberos server, it attempts to connect tothe second server. If kred fails to connect to the secondserver, an alarm will be sent out. There are two LDAPservers, kred tries to connect to both before giving up andsending out an alarm.

4.5.5 Testing

Kreditor use integration testing to enhance the quality oftheir code. Two test suites were developed to test the au-thentication and authorization code. One test suite calledldap SUITE, tests all exported functions in the LDAPmodule such as retrieving and populating kuser records.The second test suite, gui test SUITE uses the HTTP li-brary in Erlang to test the web-interface. The outputtedweb-page is not parsed to check the content, but the testensures that the server does not crash during the request.

22

Page 23: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Chapter 5

Conclusion

Adding SSO to an existing network is a very complexproblem. It is also a problem that has not been com-prehensively studied. Perhaps more studies that examinethe costs and potential savings of adding SSO are needed.The few cost estimations that exist indicate that there arepotentially huge savings for companies that implementgood solutions [5] [16].

In this paper we have shown a case study at a com-pany called Kreditor where SSO was added to an existingnetwork. More specifically, a service written in Erlangwas modified to use existing network infrastructure forauthentication and authorization. The implementationwas successful and the requirements from Kreditor weremet. We present a design that can be used to provideSSO for web services, by integrating the web service witha Kerberos server. We also show how to provide a fall-back method for when the user does not have a Kerberosticket. The design also gives an example of how a set ofusernames and passwords pairs can be integrated with aLDAP directory.

Some of the problems encountered during the designand implementation are described. Problems associatedwith optimization, username mapping, character encod-ing and redundancy, are likely to be encountered whenattempting to integrate a similar service. Despite theproblems, the move from design to implementation wassuccessful.

Because the service at Kreditor was written in Er-lang, the implementation details of this case study areparticularly interesting. Erlang is a functional program-ming language that is becoming more and more popular1.Working with Erlang has been a very pleasant experience.Libraries exist for most needs, but they can sometimes behard to find, unless you know exactly what you’re lookingfor. Appendix B lists some Erlang libraries that can be

1http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

used for authentication and authorization.

5.1 Improvements

While the design in this thesis was an improvement onthe existing situation, there is still room for improve-ment. What seems to be the biggest problem is thatthe authorization scheme is very closely tied to the pagesin the GUI. A better solution would be to tie access tothe actual resources in the system. Overall the authoriza-tion decisions are too coarse-grained to fit a medium-sizedcompany. By using the resources in the system as a basefor authorization decisions, it would be possible to havedifferent access rules for different operations. This would,for example, make it possible to give one person read ac-cess to a resource while another person is given write ac-cess. Separating out the authorization logic should alsomake the upcoming redesign of the GUI easier.

23

Page 24: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Bibliography

[1] Fredrik Ahlborg and Johnny Halsjo. A study in theuse of single sign-on in swedish public sector. 2008.

[2] Joe Armstrong. A history of erlang. In HOPL III:Proceedings of the third ACM SIGPLAN conferenceon History of programming languages, pages 6–1–6–26, New York, NY, USA, 2007. ACM.

[3] Joe Armstrong. Programming Erlang: Software for aConcurrent World. Pragmatic Bookshelf, July 2007.

[4] John Barkley. Comparing simple role based accesscontrol models and access control lists. In RBAC’97: Proceedings of the second ACM workshop onRole-based access control, pages 127–132, New York,NY, USA, 1997. ACM.

[5] Kris Brittain and Gartner Group, 2004. What Is theRight IT Service Desk Staff Size and Structure?

[6] Matt Butcher. Mastering OpenLDAP: Configuring,Securing and Integrating Directory Services. PacktPublishing, 2007.

[7] Joris Claessens, Valentin Dem, Danny De Cock, BartPreneel, and Joos Vandewalle. On the security of to-day’s online electronic banking systems. Computers& Security, 21(3):253 – 265, 2002.

[8] Jason Garman. Kerberos: The Definitive Guide.O’Reilly & Associates, Inc., Sebastopol, CA, USA,2003.

[9] Dieter Gollmann. Computer security. John Wiley &Sons, Inc., New York, NY, USA, 1999.

[10] M. E. Kabay. Identification, authentication and au-thorization on the world wide web. http://www.

mekabay.com/infosecmgmt/iaawww.pdf, 1997.

[11] Pauli Kaila. From end-to-end to trust-to-trust. InPROCEEDINGS OF THE SEMINAR ON NET-WORK SECURITY, pages 18–22, 2008.

[12] NAC. Enterprise-wide security: Authentication andsingle sign-on. http://www.alameda-tech-lab.com/

portfolio/samples/Old_Papers/NACSEC02.pdf, 1996.

[13] Vipin Samar. Single sign-on using cookies for web ap-plications. In WETICE ’99: Proceedings of the 8thWorkshop on Enabling Technologies on Infrastruc-ture for Collaborative Enterprises, pages 158–163,Washington, DC, USA, 1999. IEEE Computer So-ciety.

[14] Gary Tagg. Implementing a kerberos single sign-oninfrastructure, 2000.

[15] A. Volchkov. Revisiting single sign-on: a pragmaticapproach in a new context. IT Professional, 3(1):39–45, Jan/Feb 2001.

[16] Roberta Witty, Kris Brittain, Ant Allan, and Gart-ner Group, 2004. Justify Identity Management In-vestment With Metric.

[17] Si Xiong. Web single sign-on system for wrl company.Master’s thesis, KTH Royal institude of Technology,June 2005.

[18] J. Yan, A. Blackwell, R. Anderson, and A. Grant.Password memorability and security: empirical re-sults. Security & Privacy Magazine, IEEE, 2(5):25–31, 2004.

24

Page 25: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Appendix A

Client Setup

All major browsers support SPNEGO, but it’s typ-ically not enabled by default. This appendix describeshow to enable SPNEGO for Mozilla Firefox and MicrosoftInternet Explorer. The clients need to hold TGTs for SP-NEGO to work. The web-server also needs to be config-ured correctly.

A.1 Mozilla Firefox

To enable SPNEGO in Firefox you have to change the ad-vanced settings, they can be found by typing about:configin the address field of the browser. Ignore the warning andchange the setting network.negotiate-auth.trusted-uris tothe name of your domain, for example, acme.com. FigureA.1 shows the advanced configuration window.

Figure A.1: Enabling SPNEGO in Firefox.

By typing network.n in the filter field it becomes easy

to find the relevant options. These instructions weretested with Mozilla Firefox version 3.0.10 but should workwith other versions as well.

25

Page 26: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

A.2 Internet Explorer

To enable SPNEGO in Internet Explorer you first haveto add your domain to the list of local intranet sites. Youhave to:

1. Start Internet Explorer.

2. In the menu, select Tools → Internet Options →Security.

3. Select the Local intranet icon and click Sites.

Figure A.2: Adding your domain to local intranet sites

4. Make sure the Automatically detect intranet net-work checkbox is ticked.

5. Click Advanced.

6. Enter the URL of your site and click add, for exam-ple https://example.com.

See Figure A.2 for an illustration of these steps. Nextyou have to enable SPNEGO. Click on Internet Options→ Advanced and scroll down to security settings.

26

Page 27: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Make sure that the Enable Integrated Windows Au-thentication box is selected, see Figure A.3 for an illus-tration. These instructions were tested with Internet Ex-plorer 8 but should be similar with other versions.

Figure A.3: Enabling SPNEGO in Internet Explorer.

27

Page 28: Authentication and Authorization - uu.diva-portal.org344199/FULLTEXT01.pdf · ti cation, authentication and authorization on the World ... 1 6. written an informative paper describing

Appendix B

Libraries

Below is a collection of some of the authentication andauthorization protocols that have existing Erlang imple-mentations. There exist implementations for many pro-tocols, but they can sometimes be hard to find. This listshould help anyone who wants to add authentication orauthorization in Erlang.

B.1 Egssapi

Egssapi is an implementation of the GSS-API protocoldescribed in section 3.2.1, it can be found here: http:

//github.com/danw/egssapi/tree/master.

B.2 PAM

While there is no independent release of an Erlang PAMlibrary, both Yaws and Ejabberd have implementedsupport for PAM. These implementations should providea good reference for anyone who wants to add PAM sup-port to their application. The Ejabberd implementationcan be found at:http://github.com/processone/ejabberd/blob/

5463478632f5c09cd694b548845f90a2549afedf/src/

ejabberd_auth_pam.erl.

The Yaws implementation can be found here:http://github.com/klacke/yaws/blob/

3655d576ed510071b441c0f6fc621d8f888374f2/src/yaws_

pam.erl.

B.3 Eldap

Eldap is the Erlang implementation of the LDAP protocoland it is the library that was used in this case study. Seesection 3.3 for a description of LDAP. The API is easy to

understand and includes an example. Eldap can be foundhere: http://github.com/etnt/eldap/tree/master.

B.4 EOpenID

OpenID is a federated authentication protocol. OpenIDmakes it possible for users to login with their credentialsfrom any compatible provider that support the OpenIDprotocol. An Erlang OpenID library can be found here:http://github.com/etnt/eopenid/tree/master.

B.5 Erlang-oauth

Oauth is a relatively new, but very interesting proto-col. The OAuth API allows secure authorization in asimple and standardized form. Oauth makes it possi-ble for service providers to delegate resource access tothird parties, called consumers. The Erlang implementa-tion can be found here: http://github.com/tim/erlang-

oauth/tree/master.

28