Authentication, Authorization and Security Aspects of

DIPLOMA THESIS

Authentication, Authorization andSecurity Aspects of Collaborative WebApplications - Case: TWiki and Single

Sign-On

prepared for theSalzburg University of Applied Sciences

Degree ProgramInformation Technology & Systems Management

submitted by:Alexander Bernegger

Head of Faculty: FH-Prof. DI Dr. Gerhard JochtlSupervisor: Simon Kranzer

Salzburg, May 2010

Affidavit

Herewith I, Alexander Bernegger, declare that I have written the presentdiploma thesis fully on my own and that I have not used any other sourcesapart from those given.

Alexander Bernegger Matrikelnummer

ii

Acknowledgement

Experience is the name every one gives to their mistakes.Oscar Wilde (1854-1900)

First I’d like to thank my colleagues from CERN’s IT - PES Department, ina very special way to Peter Jones and Nils Himyr for helping me write thisThesis and giving me steady support. Furthermore, I’d like to thank SimonKranzer for his guidance and supervision during this Thesis work.

iii

Details

First Name, Surname: Alexander BerneggerUniversity: Salzburg University of Applied SciencesDegree Program: Information Technology & Systems Manage-

mentTitle of Thesis: Authentication, Authorization and Security

Aspects of Collaborative Web Applications -Case: TWiki and Single Sign-On

Academic Supervisor: Simon KranzerCompany Supervisor: Peter Jones, Nils Høimyr

Keywords

1st Keyword: Collaborative Networks2nd Keyword: Authentication3nd Keyword: Single Sign On4nd Keyword: Security

iv

Abstract

This Thesis work reflects the author’s internship at CERN during the 7th

semester of Information Technologies and System Management (ITS). The

subject is collaborative networks in large environmental computing facilities

and will treat its security mechanisms and its integration to existing identity

and access managing systems.

CERN employs more than 10.000 users and scientists. Many of these employ-

ees work together on projects and therefore need a platform to share knowledge

and information amongst them. TWiki is a web-based, open source enterprise

collaboration software with access control mechanism. This is important to

protect from unauthorized viewing, among other reasons. To control access

for each single user in TWiki would have time-consuming detrimental effects.

At CERN every employee has a centralized account in order to access the com-

puter systems. In these accounts, user-specific information such as membership

in workgroups is stored. This information can be used to protect TWiki web

pages by giving access to those specific workgroups instead to each specific user.

This Thesis provides a solution on how to facilitate TWiki usage by integrating

CERN’s workgroups to TWiki’s access control mechanism.

v

Contents

Affidavit ii

Acknowledgement iii

Details iv

Keywords iv

Abstract v

Table of Contents vi

List of Figures x

List of Tables xii

1 Introduction 1

2 Wiki Web Collaboration 3

2.1 Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Authentication and Authorization in Web Collaborative Ap-

plications 7

3.1 Identity and Access Management . . . . . . . . . . . . . . . . . 8

vi

3.2 Authentication, Authorization, Accounting . . . . . . . . . . . 11

3.2.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 IAM Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Authentication using Single Sign-On . . . . . . . . . . . . . . . 17

3.4.1 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.2 Types of SSO Models . . . . . . . . . . . . . . . . . . . . 19

3.4.2.1 Circle of Trust . . . . . . . . . . . . . . . . . . 19

3.4.2.2 Centralized Sign-on Server . . . . . . . . . . . . 20

3.4.3 SSO Authentication Methods . . . . . . . . . . . . . . . 21

3.4.4 Authentication Token . . . . . . . . . . . . . . . . . . . . 23

3.5 Single Sign-On at CERN . . . . . . . . . . . . . . . . . . . . . . 24

3.5.1 Identity Provider . . . . . . . . . . . . . . . . . . . . . . 24

3.5.2 Service Provider . . . . . . . . . . . . . . . . . . . . . . . 27

3.5.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.4 Implementation Problems . . . . . . . . . . . . . . . . . 29

4 TWiki Enterprise 30

4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Extentions . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 User Management and Authentication . . . . . . . . . . . . . . 32

4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.1 Default Access Control . . . . . . . . . . . . . . . . . . . 34

4.3.2 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 TWiki at CERN . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii

4.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Spiral Software Development 38

5.1 SDLC Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Analyses, Implementation and Test 42

6.1 ADFS User Mapping . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2 ADFS User Mapping Development . . . . . . . . . . . . . . . . 43

6.2.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.1.1 Problem Definition . . . . . . . . . . . . . . . . 43

6.2.1.2 Improvement . . . . . . . . . . . . . . . . . . . 43

6.2.1.3 Timeline . . . . . . . . . . . . . . . . . . . . . . 45

6.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.2.1 E-Groups Analysis . . . . . . . . . . . . . . . . 45

6.2.2.2 TWiki Analysis . . . . . . . . . . . . . . . . . . 46

6.2.3 Development and Implementation . . . . . . . . . . . . . 56

6.2.3.1 Module Development . . . . . . . . . . . . . . . 57

6.2.3.2 DENY View Problem . . . . . . . . . . . . . . 60

6.2.3.3 Other Changes . . . . . . . . . . . . . . . . . . 62

6.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3.1 System Testing . . . . . . . . . . . . . . . . . . . . . . . 64

6.3.2 Program Testing . . . . . . . . . . . . . . . . . . . . . . 65

6.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Conclusion 69

7.1 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

viii

Bibliography 71

List of Abbreviations 76

Appendix 78

A ADFSUserMapping.pm 79

A.1 Original isInList function . . . . . . . . . . . . . . . . . . . . . . 85

B Concerned Modules 87

B.1 CheckAccessPermission Changes . . . . . . . . . . . . . . . . . . 87

B.2 ExpandUserList Changes . . . . . . . . . . . . . . . . . . . . . . 93

C Use Cases 95

D Plugin Test 102

E Test Results 104

ix

List of Figures

3.1 Architecture of CERN’s IAM process[1] . . . . . . . . . . . . . . 10

3.2 Circle of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Centralized Single Sign-On . . . . . . . . . . . . . . . . . . . . . 21

3.4 SSO Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 CERN’s Identity Provider . . . . . . . . . . . . . . . . . . . . . 25

3.6 CERN’s Service Provider . . . . . . . . . . . . . . . . . . . . . . 28

4.1 TWiki Main Web . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Growth of the total number of TWiki files[2] . . . . . . . . . . . 37

5.1 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 TWiki at CERN Roadmap snippet . . . . . . . . . . . . . . . . 45

6.2 Environment Variables . . . . . . . . . . . . . . . . . . . . . . . 46

6.3 Flowchart of User Interaction . . . . . . . . . . . . . . . . . . . 47

6.4 Entity Relationship Model . . . . . . . . . . . . . . . . . . . . . 48

6.5 TWiki Use Case 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.6 TWiki Use Case 8 . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.7 TWiki Topic Access Flowchart . . . . . . . . . . . . . . . . . . . 54

C.1 TWiki Use Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 95

x

C.2 TWiki Use Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 96

C.3 TWiki Use Case 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.4 TWiki Use Case 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C.5 TWiki Use Case 6 . . . . . . . . . . . . . . . . . . . . . . . . . . 99

C.6 TWiki Use Case 7 . . . . . . . . . . . . . . . . . . . . . . . . . . 100

C.7 TWiki Use Case 8 . . . . . . . . . . . . . . . . . . . . . . . . . . 101

D.1 Test ADFSUserMapping Module with Installed Plugins . . . . . 103

E.1 Results for Topic and Web Restrictions . . . . . . . . . . . . . . 105

E.2 Results for Two Session Testing . . . . . . . . . . . . . . . . . . 106

E.3 Results for E-groups in TWikiGroups Testing . . . . . . . . . . 107

xi

List of Tables

2.1 Overview Web Collaboration Platforms . . . . . . . . . . . . . . 4

3.1 Lookup Table of Access Rights[1] . . . . . . . . . . . . . . . . . 9

3.2 IAM Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Standard TWiki Webs[3] . . . . . . . . . . . . . . . . . . . . . . 32

6.1 Class actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2 Comparing Table . . . . . . . . . . . . . . . . . . . . . . . . . . 60

xii

1

Introduction

CERN is a European research facility for Physics and has about 10.000 sci-

entists working on different experiments throughout the world. The idea of

having a centralized platform where users can share information was born in

the early days of the web. Wikis became a popular method for online collab-

oration in the mid 1990s. CERN IT introduced TWiki in 2003 as a follow-up

to requests from software developers facing communication problems.

TWiki is collaboration software designed for corporative usage with access

control mechanism and revision control. The CERN installation is used by

7000 users and has about 58000 topics. These numbers are increasing every

month. A network of such a large scale requires defined proper access control

mechanism and user handling.

Access to TWiki is handled by CERN’s Single Sign-On system, a security

system with centralized account databases and a single log-on portal. Due to

the fact that the two components are not fully integrated, although the log-on

procedure is done via Single Sign-On, access control in TWiki is not synchro-

nized with the central information database and therefore must be managed

manually.

1

1. Introduction 2

Since the group of different users working with Twiki is enormous, a solution

must be found to facilitate this administrative work. This Thesis describes

the conception, development, implementations and testing of a module that

combines authentication and access information in the database with TWiki’s

access control mechanism.

The Thesis is separated into two parts. The first part can be taken as the

background part with a general introduction to the different systems that will

be used. This will cover questions about handling security in large user en-

vironments and the method used to develop and test the necessary software

components. Its goal is to provide a solid base for the second part of the thesis,

the technical analysis, suggested improvements and implementation. In these

sections, the existing systems will be analyzed and new software developed to

enhance TWiki’s functionalities. At the end of this work, a conclusion will be

given to summarize the work done and to cover potential questions.

2

Wiki Web Collaboration

Today, information is a very important item in business, work and project-life.

On the one hand, the quality of information is determined by its accessibility.

Information needs to be reliably distributed to members in a team. If the

forwarding is interrupted, information may not reach every person in a project

team or become varied if someone’s notices are not correct. On the other hand,

the speed of spreading information could affect business processes and might

lead to the deterioration of an item’s value.

The term Web Collaboration (WC) describes the idea of simplifying a com-

munity’s communication and exchange of information. In [4] WC is defined

as:

Web collaboration is when two or more individuals collaborate to

conduct some business activity enabled by web technologies.

This form of collaboration using a computer network can be done within a

Wiki. Precisely, Wikis are a form of WC which are easy to use and to manage.

Web Collaboration with Wiki can be seen as an option for disseminating infor-

mation to a user group and to provide data to related persons. The advantages

of a web based platform are significant[5]. Some of the main advantages in-

clude:

3

2. Wiki Web Collaboration 4

• Users can easily share information amongst themselves

• Contents can be created quickly

• Topics can be modified ’on the fly’

• Collaborative working

• No client software needed

• World wide availability

One of the most famous web collaboration platform is Wikipedia - a free,

web-based, collaborative, multilingual encyclopedia project1, which is built up

from a MediaWiki, a custom-made, free and open source wiki software plat-

form written in PHP and built upon a MySQL database2. Other well known

web collaboration platforms are MS SharePoint and Google Groups. Table

2.1 provides a short overview about collaboration platforms; however there are

many more available.

Platform Scope Costs SpecificationMediaWiki Private / Enterprise No Easy to use, ”on the fly” pages[7]TimeBridge Enterprise Yes Coordinate meetings, SMS /

iPhone feature[8]Google Groups Private / Enterprise No News Groups, Calendar[9]Textflow Enterprise Yes Quick document editing, MS

Word importable[10]Present.io Private / Enterprise No File sharing, real time web

presentations[11]Wikipedia Private No Web encyclopedia + Wiki[6]TWiki Enterprise No Structured Wiki, restrictable,

open source[3]Microsoft Share-Point

Enterprise Yes MS Server 2003/8 addon,CMS, calendar, blogs, accesscontrols[12]

Table 2.1: Overview Web Collaboration Platforms

1Wikipedia Enzyclopedia[6]2MediaWiki[7]


Due to the fact that the implementation done in this work is using a Wiki

for WC, the following section describes the concepts Wiki are based on and

chapter 4 provides an overview of TWiki, the platform used at CERN.

Besides Wikis, WC can be done using one of the platforms shown in table

2.1. More information on WC can be found in [4] and [5]

2.1 Wikis

Howard ”Ward’ G. Cunningham, the founder and developer of the first Wiki

[13], defined Wiki as:

Wiki is a piece of server software that allows users to freely create

and edit Web page content using any Web browser. Wiki supports

hyperlinks and has a simple text syntax for creating new pages and

crosslink between internal pages on the fly.

Following by that, the idea behind a Wiki is to create a free collaboration

platform, open to and editable by everybody to share information with other

participants[14]. A Wiki can be seen as a Content Management System (CMS),

designed to facilitate planning and documenting work. It can get used as a

knowledgebase of results from researches, for example. The name Wiki comes

from the Hawaiian word ”Wiki-Wiki”, which means quick or hurry-on. This

is what Wikis are known for, the speed and ease with which content can be

created or changed. The WikiWikiWeb-Server technology allows nonlinear

hypertext structure for navigation. A user can choose from the next cross

reference and is not constrained to following page-per-page references. Fur-

thermore, a Wiki user can create and edit existing topics ”on-the-fly”. This

means the user is able to use a Wiki without installing additional software.


The concept of Wiki is free collaboration for everybody

Giving each user the opportunity to read and change can be dangerous, es-

pecially in protected areas such as companies or research facilities. The re-

quirements of corporate collaboration cannot be fulfilled using conventional

Wikis; there are no proper control, - security, - and audit trail mechanisms

available[15]. For this reason, an enterprise solution is prefereable when using

collaborative software in companies. Enterprise Wikis have the same function-

alities as normal Wikis but include additional optimized enhancements such as

access and reversion controls for replicability and are able to address the inter-

nal challenges of business processes. Besides the usual Wiki features, enterprise

software in corporate collaborations should also cover proper communication

and conferencing tools, a document handling system as well as access and ver-

sion control mechanisms[15].

An API Interface gives the possibility of including enhancements such as plug-

ins if the standard features don’t meet the needs. From the original Wiki,

a lot of derivates are available (see Figure 2.1). The TWiki3 Enterprise col-

laboration is a Perl-based structured Wiki application designed for large user

environments and has restriction mechanisms to prohibit users from unau-

thorized viewing. It is a web-based platform which fosters information flows

within an organization and helps to facilitate the distribution of project team.

Because of its fine grained access controls, it is optimal for sensible data col-

laborations in corporate environments[15].

TWiki and its features will be covered in more depth in chapter 4.

3TWiki is short for ”TakeFive Wiki” founded by Peter Thoeny in ’98

3

Authentication and

Authorization in Web

Collaborative Applications

The previous chapter provided a brief overview on how web collaboration in

corporations can be done using Wikis. The following chapter deals with au-

thentication and authorization in a web collaborative environment and will

give an overview of a secure identity network using Single Sign-On.

The ever-rising complexity of present day corporate webs has lead to an in-

creased risk of computer security vulnerabilities. Software vendors and hard-

ware manufacturers are continuously optimizing their products to deal with

emerging needs. However, it is not only the technical weakness of a system that

makes services vulnerable. There are two further aspects to consider: social

engineering and identity management. Social engineering can be considered

the weakest point in a security chain. For example, a user who is required to

remember numerous login and password pairs is tempted to write down this

sensitive information in order not to forget it[1]. To minimize the social engi-

neering problem, basic rules can be defined by work contracts. An example of

7

3. Authentication and Authorization in Web Collaborative Applications 8

preventing the writing down of password can be talking about internal com-

pany policies or having employees sign statement clauses.

Identity management in combination with access rights handling makes a se-

curity system efficient and will be discussed in a later section.

The following section focuses on identity management and which problems

may occur when security aspects do not address substantial requirements.

3.1 Identity and Access Management

The term ”identity” includes all information about a person’s singularity. Iden-

tity is a term defining somebody or something. To ensure a person’s identity

when registering to a system, it must be proven in an accurate way to prevent

fraud later. This can be solved by bringing evidence such as identity docu-

ments like passport or personal ID card. Once a person has been registered

as a valid user, the validation can always rely on this official, approved data.

Identity management (IM) describes how to handle these processes.

IM begins when an employee begins work at a company by entering all rele-

vant personal information such as name, social insurance number, department,

position and technical objects such as network printers, internal processes and

procedures. IM in combination with Access Management (AM) becomes ”Iden-

tity and Access Management” (IAM), where AM describes the actions a user

is allowed to do in a system. (e.g.: Checks who ”I AM” and provides access).

AM can be done using a database with personalized entries which are set up at

the beginning of a user’s employment relationship. In these lookup tables (see

Table 3.1), time- or location-dependent information such as read- and write-

settings, access to applications, accounts, printers or even rooms is saved[1].


Resource Right Subjectcn=Floor1, ou=printer print cn user=JohnDoe, o=cern, c=chcn=AFS, ou=directory read/write cn group=IT-DEP, o=cern, c=chcn=Root, ou=folder write cn group=sysadmin, o=cern, c=chcn=Bldg 31, ou=rooms enter cn user=JohnSmith, o=cern, c=ch

Table 3.1: Lookup Table of Access Rights[1]

Table 3.1 is an example of a lookup table for managing an employee’s access

and rights on resources. For example, in the first row user ”John Doe” is a

member of CERN in Switzerland and is able to use the printer in Floor 1. His

right is defined by ”print” for this particular action. In the second row read

and write access on a directory is granted to all members of the group ”IT-

DEP”. In such a case, groups are a logical aggregation of members or groups,

which allow to pool identities.


Figure 3.1: Architecture of CERN’s IAM process[1]

Figure 3.1 shows an architectural example of an IAM process[1]. When a

person starts a working contract, the administration stores all relevant infor-

mation in the Human Resources (HR) database. This data is validated by

the person’s ID documents and can be used for further authentication. In

the Account Database, the employee’s privileges are stored as shown in Table

3.1. Additionally, every employee is placed into work-related groups, so called

E- Groups. These groups allow the simplification of access management by

giving privileges to a whole group instead of a single person. When a user

wants access to a restricted service, the systems authorization process checks

if the user or the user’s e-group is permitted. By using a validation method

such as typing the credentials to a login-screen, the IAM framework checks

the correctness of the request. If the entries of the lookup table are set for the

requested service, access is granted.

The next section provides an overview of how identities can be managed in

a secure network.


3.2 Authentication, Authorization, Account-

ing

The ”genuineness” of a user’s identity must be controlled to ensure that it is

original and true. The process known as Authentication, Authorization, Ac-

counting (AAA) describes such a guideline of architectures and handles the

requirements of an IAM procedure[16].

Although these three parts are independent of each other, when taken in com-

bination they are an important security in network environments[1]. This

procedure will be explained in the following section.

3.2.1 Authentication

Authentication is the first step in proving a user’s identity when a system logon

appears. This step must reference to the identity management database. The

confidential login data provided to the employee upon registration is compared

with the data in the look-up tables, where personalized information is stored.

This means that every user’s initiated process has its own ”label” with the

name of the person who requests[1].

Authentication services can be realized in several implementations. The most

common technique is to use a user/password phrase pair as a login procedure.

As mentioned in the introduction part of this section, this traditional method

has potential weak points (such as the writing down of passwords). There are

more secure ways to examine the correctness of a person’s identity:

A Two Factor Authentication (2FA) is an authentication procedure which

has more than one check-routine. A standard user/password method can be

enhanced with additional electronic certificates, smartcards, hardware tokens

or even biometric techniques to grant access to a user. A 2FA is separated into


three basic factors:

• Something the user knows (e.g. pin, key, password)

• Something a user has (hardware token, smart card)

• Something a user is (fingerprint, biometric information)

At least, two of these factors must be combined to get a two factor authenti-

cation; ”a something you have” and ”a something you know” concept is the

most used authentication system[17].

Example - Pin with One Time Password (OTP):

A user wants to access a specific service. To login, the user’s known secret

password and a randomized password from a token must be entered. An OTP

token has a predefined set of passwords and chooses one randomly by activat-

ing it. The user types in both the secret password and the token generated

one. The authentication instance on the service side checks these passwords

against the same list the token has defined. If the token password is found

and the user password matches the account entry, access is granted. The used

OTP password then loses its validity[18].


A Public Key Infrastructure explains the method of using digital certifi-

cates which are generated, saved and distributed in the background of a sys-

tem. These digital signatures combine a public key with an identity and can

be used as an individual certificate to validate a user. In many PKI schemes

a centralized service takes the role of certification. These services are called

”Certificate Authority” (CA) or ”Registration Authority” (RA) and can be

seen as ”trusted-third-parties” [19].

PKI functions[20]:

Public Key Cryptography is reliable for generation, distribution and con-

trol of cryptographic keys.

Certificate Issuance the binding instance, joins a public key with a private

individual, organization or other entity.

Certificate Validation verifies the existence and the validity of a trust re-

lationship certificate.

Certificate Revocation handles expired certificates and manages Certificate

Revocation Lists (CRL)1.

PKI Example[20]:

1. Alice and Bob generate a public / private key pair

2. Both publish their public keys to a registration authority

3. RA validates their credentials and transmits the information to the CA

4. CA then generates certificates for Alice’s and Bob’s public keys and signs

them with the CA’s private key

1CRLs are lists generated by CA, to manage revoked certificates.


5. As a result, both Alice and Bob have a public / private key pair and a

public key certificate

6. Data can now be signed with a digital signature to assure confidentiality

and integrity

Kerberos is a computer network authentication protocol, which secures trans-

fer flows between server and client by verifying each other’s identity. Kerberos

uses symmetric-key cryptography and incorporates the advantages of a CA[21].

It is based on ticketing, which is responsible for proving the user’s identity.

Kerberos Functions[22]:

Key Distribution Center (KDC) manages a secret key database. Every

entity in a network exchanges secret keys with KDC. If one entity wants to

communicate with another, the KDC creates a session key, which is generated

out of both secret keys and delivers a ticket (Kerberos ticket) with the session

key to the communication partners. Both partners are validated and can es-

tablish a connection.

Authentication Server (AS) authenticates the entities in a network envi-

ronment.

Ticket granting Server (TGS) supports authentication without password

re-entry.

Ticket Cache stores authentication tickets during a session. This step is

important for single sign on solutions operating over a ticketing service..

3.2.2 Authorization

The authorization section of the triple AAA procedure defines how to grasp on

resources. Authorization is a part of a login routine where identity has already


been validated and the authentication process has been passed through. It can

be seen as a predefined set of policies describing what proven users are able

to do in a system[1]. These policies are maintained by system administrators

and are often called Access Control Lists (ACL). If a user wants to have access

to a certain resource, a token or ticket mechanism checks the user’s unique

identifier against an access list to prove its permissiveness. Authorization can

be implemented either by the system (native functionality of an operating sys-

tem) or by an application, which adopts the requirements. The user’s privilege

entities of access lists can be defined as read/write rights to files, directories,

accounts, as well as physical access to rooms, buildings or archives. Session

dependent entries, such as ”access in work hours only”, can also be regulated

in authorize - ACLs.

3.2.3 Accounting

This part of the framework is responsible for tracking the user’s actions in an

information system; it is a journal of what users did while they were logged on

(who, when, where, what). Traceability is an essential item in terms of incident

handling. This process has become increasingly refined in recent years. Early

accounting systems were only able to track a user’s access to specific systems;

today the process is able to record single menu items or even database cells[23].

3.3 IAM Use Case

Table 3.2 shows a summary of an IAM process. For example, before a person

comes to CERN to start a work relationship, s/he must verify their identity by

sending a copy of their passport. Using this personal data, the HR department

creates an account containing all work related groups and access regulations.


The username is then a combination of the first letter from first name and seven

letters from the surname. On the first work day, the user gets a document with

this username and a password and a demand note to change the password to

a personal secret word. From now on, every action the user performs with

his/her username will get tracked for traceability.

Provided by Answer the questions: AttributesIdentity user ”who are you?” Public assertionAuthentication user ”How can you prove it?” Secret responseAuthorization system ”What can I do?” Access controlAccounting system ”Tracking my actions” Traceability

Table 3.2: IAM Summary


3.4 Authentication using Single Sign-On

Today, a variety of platforms are available to facilitate our work in computer

aided environments. At the beginning of a typical working day, the very first

action a user has to perform is to start up a workstation and login to the oper-

ating system. After this process, a plethora of sessions and program start-ups

follows. This could include a login to an email program, terminal services,

external databases and administrative applications which all entail calls to

several password requesting services. Even leaving the computer for a coffee

break would later require a release of the desktop lock by entering a password.

Such a wide range of systems brings with it a vast amount of username /

password pairs to remember. The credentials in many cases are given as a

secret word at the startup of an application and since humans are tempted to

forget things, these credentials are noted down on reminder stickers or other

unsecure media which can be accessible to anyone[24].

The next chapter is related to a solution to the above problem and will outline

a single platform where users only have to login once to get access to a variety

of different applications.

3.4.1 Single Sign-On

When administering a user environment, the work is increased by the number

of applications that are implemented. These systems often have their own user

accounts and authentication procedures. In general, a coherent authentication

strategy or a solid authentication framework is missing[25].

The idea of a Single Sign-On (SSO) platform address the problem by using


only one unique central account database and one login procedure to trans-

act authentication to different software systems. It handles access controls for

multiple, related but independent applications. A user is able to login to one

system and gains admission to all applications within an SSO environment

(circle of trust) without being prompted to login again when changing plat-

forms.

Ideally, the requestor has only one username and only needs to pass the iden-

tity check process once to be able to access all network resources. The reverse

process is called Single Sign Off; with one click, the user opts out from every

opened platform he called during a session[26].

Generally, an SSO solution brings benefits by making work easier for the user

and closes potential leaks or reduces security holes by avoiding multiple creden-

tials. On top of this, it facilitates administrative work. Privileges for groups

can be changed quickly or a new user can acquire access to all systems by one

single entry in the database. In the opposite manner, excluding or blocking a

user from the circle of trust can be performed in seconds.

Changing a running system by introducing a new mechanism has advantages

and disadvantages. Before a new system can get installed, it must be evalu-

ated to see whether or not there is an end benefit. The following list shows

the advantages and disadvantages of SSO.

Advantages[25]:

• Improved user productivity

• Simple administration

• One unique central account database

• One authentication process per session


• Reduce ”password fatigue2”

• Multiple applications, portals, systems

• User group management for authorization

• Reduce labor and monetary costs

The universal access can also be seen as a negative feature. This might be

an interest point for hacking (single point of attack). Another negative is the

need to adapt existing systems. This is most likely connected with additional

costs[25].

3.4.2 Types of SSO Models

A SSO model can be realized in different ways. The best model is chosen

according to need and technical feasibility.

3.4.2.1 Circle of Trust

In the space of a Single Sign-On infrastructure, a Circle of Trust (CoT) de-

scribes virtual separated application communities. A user granted access to

one service is then able to move between the services inside a circle of trust

without being prompted to for a second login[27]. The user authenticates at

the first site and is issued a ticket which is valid for all other locations inside

the CoT.

Figure 3.2 shows a simplified diagram of a CoT model. A user is able to login

at any client and if the authentication is accepted, the user is able to move

freely within the CoT.

2writing down passwords


Figure 3.2: Circle of Trust

3.4.2.2 Centralized Sign-on Server

A centralized Single Sign-On server is a model that acts like a CoT model,

but has a dedicated authentication server which handles all user information

and controls tickets or tokens. The client logs on to the server and gets a

circle-wide valid ticket to access applications within boundaries[27].

Figure 3.3 shows a simplified example of a centralized Single Sign-on architec-

ture.

Every request to a service is first directed to the central SSO server. The

user logs on with credentials and gains a circle-wide personal ticket. SSO for-

wards the client’s request to the desired service by using return addresses from

the service. The application verifies the given ticket and, if correct, grants

access.


Figure 3.3: Centralized Single Sign-On

3.4.3 SSO Authentication Methods

When introducing an SSO model to an existing environment, security increases

when the human-driven ”password fatigue” factor is reduced to a minimum.

Although this increases security, it also makes it possible for intruders to access

all areas by entering only one site. The new weak point in the security chain is

the portal where Single Sign-On takes place. To combat the security weakness

of a single entry point, SSO infrastructure provides different authentication

models with different security levels[24]:

• (weak) Classic Web Form: A standard web page with username /

password pair to login. Possibility to store credentials in browser cookies

for later use.

• (medium) Windows Integrated Authentication: from the current

logon to a windows operating system, a token is used to verify the user’s

genuineness and to authenticate to other systems. Absolutely required:

desktop lock when leaving the workspace.


• (strong) Certificates: Authentication can be enhanced by incorporat-

ing a Certificate Authority (CA) to the process. The user gets a verified

certificate from a trusted third party to authenticate when requests on

resources appear.

• (strong+) Combination: More factor authentication, as explained in

in the chapter on authentication (see 3.1.3.1 Authentication), increases

security levels by combining certificates with smartcard tokens or other

additional methods.

• (very strong) Biometrics: enhancement of combination. Using hu-

man biometric information, such as eye-scans, fingerprint scan or voice

recording authentication methods additional to a CoT.


3.4.4 Authentication Token

When a user successfully logs in to a system, an instance combines the re-

quested address of a service with a session-dependent token. With this token,

the user is able to access all services within the trusted circle. Every resource

must check the validity of the token prior to access being granted. If the va-

lidity has expired or there is not yet a token in the HTTP header, a redirect

to the login page appears.

Figure 3.4: SSO Infrastructure

Figure 3.4 shows a general overview of a SSO infrastructure. (drawn at

gliffy.com) A user enters a trusted circle by calling an application. The ac-

cess control instance checks if there is a token within the request and whether

or not the token is valid. If the token is not valid, the user must authenticate

and is then forwarded to the requested service.


3.5 Single Sign-On at CERN

There are several ways to realize a SSO model as explained above. In large

part, this depends on the requirements of the network and how it will be used

when it is installed[28]. This section will give information about CERN’s SSO

infrastructure; it is a real model and will be used as an example here. Other

models will not be explained further because it would go beyond the scope of

this thesis.

CERN’S Single Sign-On has two main components: the Identity Provider and

the Service Provider. It uses a token-based system, which communicates over

SAML3[24].

3.5.1 Identity Provider

The identity provider (IdP) is the main actor in an SSO structure. It is respon-

sible for authentication and for generating user-specific attributes. Its software

checks the user’s identity against a database when a logon appears. IdP sup-

ports several authentication methods and provides communication protocols

like SAML[29] or Kerberos. After verification of the user’s credentials, it loads

the specific information for the requested service or application and delivers it

to the service provider (SP). These attributes can be different for every appli-

cation, depending on the security level of each one[24].

3Security Assertion Markup Language: a XML-dialect for exchanging authentication andauthorization information between domains


Figure 3.5: CERN’s Identity Provider

CERN’ identity provider is realized by a software, a specification and a proto-

col component.

Software:

For the identity provider, CERN uses Microsoft’s Active Directory Federation

Service (ADFS). This is an extension of Microsoft’s Active Directory authen-

tication database for Web Services Architectures (WS-Federation4). ADFS is

a component in Windows Server 2003 R2 which provides Web single-sign-on

(SSO) technologies to authenticate a user to multiple Web applications over the

life of a single online session. ADFS accomplishes this by securely sharing dig-

ital identity and entitlement rights across security and enterprise boundaries.

(http://technet.microsoft.com/en-us/library/cc755828%28WS.10%29.aspx)

ADFS provides federation and Web SSO. When using Active Directory ser-

vices, the benefit of SSO solution through Windows integrated authentication

4WS-Federation is a identity federation specification, defines mechanisms for allowingdisparate security realms to broker information on identities, identity attributes and au-thentication.

http://technet.microsoft.com/en-us/library/cc755828%28WS.10%29.aspx


ends at the boundaries of an organization. ADFS extends functionalities to web

applications and includes ”light-weight” users such as partners, contributors, or

customers using the same facilities as organizational members. Further- more,

ADFS employs the federation specification of WS-Federation, which makes

it possible for environments to use federated identity management solutions.

For communication between services, ADFS supports the security assertion

markup language (SAML) and provides Kerberos authentication. ADFS’s

extensibility facilitates incorporating an existing security infrastructure and

current business policies[30].

Specification:

The WS-Federation Passive Requester Profile (PRP) is an MS ADFS sup-

ported specification regulating how cross trust realm identity5, authentication

and authorization can be used by passive requestors like web browsers[31].

Protocol:

For communication, CERN has implemented SOAP Web Services (Simple

Object Access Protocol), a protocol specification for exchanging information

within Web Services in computer networks. It uses XML as its message format

and the application layer protocol for transmission[32]. It describes how infor-

mation can be packaged into an XML document, how entities have to process

SOAP messages and in which way it should be transported with HTTP and

SMTP service[33].

5A Trust Domain/Realm is a security space in which the target of a request can determinewhether particular sets of credentials from a source satisfy the relevant security policies ofthe target.


3.5.2 Service Provider

The service provider (SP) gets the verified user information from the identity

provider and allows access to the requested web applications. It is the client

side of an SSO infrastructure and can be done either by Microsoft’s Internet

Information Service (IIS) or Apache’s web server module.

On Linux /Apache hosted web sites, CERN uses the Shibboleth module: Shib-

boleth is Open Source middleware software, which allows applications to make

informed authorization decisions for individual access of protected online re-

sources in a privacy-preserving manner. It uses federated identity standards

and provides extended privacy functionality[34].

Shibboleth Single Sign-on provides a reduction of multiple passwords to mul-

tiple applications. The security aspect will improve by preventing ”password

write-down” and at the same time it causes a minimization of account manage-

ment work. Further, it allows interoperability within and across organizational

boundaries and enables service providers to control access to their resources.

As an example, CERN uses Win Services, Terminal Services, AFS (Andrew

File System), DFS (Distributed File System) and NICE6 (see Figure 3.6) as

Service Provider Applications.

6NICE: Providing a consistent environment through which Windows users at CERN canobtain resources, applications and managed operating system services


Figure 3.6: CERN’s Service Provider

3.5.3 Procedure

Example: a user wants to have access to a CERN service, e.g. mailbox infor-

mation. This web application is part of circle of trust and needs authentication.

The IIS module checks the requestor’s HTTP header to see if there is a token

and if it is valid. The user is requested to log in since s/he has successfully

logged off from last session. The user is redirected to the central SSO web

page (https://login.cern.ch/adfs/ls/?wa=wsignin1.0) and is asked to

type in the credentials. ADFS checks the information against a unique ac-

count database - the user’s active directory entry. If the comparison returns

true, the user gets an authentication token and will be redirected to the called

service. The IIS module performs another control of the HTTP header and

the valid token. If correct, the mailbox information will be displayed.

(https://login.cern.ch/adfs/ls/?wa=wsignin1.0)


3.5.4 Implementation Problems

As CERN uses an SSO solution for most of its services, problems appeared

while implementing the SSO to the existing system. Mr. Pete Jones from the

Platform and Engineering Services (PES) group defined the problems when

introducing TWiki to SSO. The version upgrade from TWiki4.1 to TWiki4.2

was not possible due to SSO incompatibilities, such as former user identifiers

needing to be changed (usernames). Since the SSO authentication procedure

was introduced, the TWiki identifier is the user’s email address. However,

as email addresses change regularly, there were many user complaints that

they could no longer authenticate. There was a lot of downtime caused by

dependency problems (Oracle or MySQL). Also, there was a different clustering

with Shibboleth’s daemon (shibd).

4

TWiki Enterprise

TWiki (twiki.org) is a Wiki variant. It is a project-oriented Wiki implementa-

tion targeted for corporate intranets by incorporating restriction mechanisms

and revision controls. TWiki is a Perl-based Wiki that was developed by Take

Five and is GNU general public licensed software[35].

TWiki Enterprise Collaboration is completely written in the Perl Object Ori-

ented programming language. Contrary to MediaWiki, a php based structured

Wiki, TWiki has no relational database for the storage of information, but

saves data directly into the storage system files[14]. As with most other Wikis,

one of TWiki’s advantages is its revision control system (RCS), which make

rollbacks to previous versions of files possible.

Another benefit is the built-in access control mechanism. This allows restrict-

ing files from unauthorized viewing.

Because TWiki is under General Public License (GNU) and the structure is

written in an object oriented way, it is easy to modify its components for per-

sonal use. The modification is often useful for other TWiki administrators,

allowing everyone the freedom to collaborate on development and publishing

in Twiki.org. These contributions are called Plugins, Addons, or Contribs[3].

30

4. TWiki Enterprise 31

Figure 4.1: TWiki Main Web

Fig 4.1 shows a TWiki Main Web. Editing mode: By clicking on edit, a ”What-

You-See-Is-What-You-Get” (WYSIWYG) editor opens the file in editing mode

( 1©). Menu-list: In this section, a list of webs and topics can be displayed

( 2©). It also screens the current Web. Content area ( 3©). Action bar: Several

actions are available, including rollback to previous versions ( 4©).

4.1 Structure

TWiki topics (known as documents or pages) are contained in areas known as

”Webs” and a user can read these TWiki topics from a web browser, which

retains user information for the current session[36]. The surface is the Main

Web. This front page is the starting point from which all other Webs and

Topics are accessible. The standard configuration comes with three webs:


Web UsageMain Front-Page of TWikiTWiki Configuration Web. Settings for entire TWikiSandbox Testing area. E.g.: Try and error environment for Plugins.

Table 4.1: Standard TWiki Webs[3]

4.1.1 Extentions

Additional programs are known as Plugins and are developed by interested

persons. Every user is free to contribute ideas to enhance TWiki’s functional-

ities, be they calendars, database access, spreadsheets, or visual themes. The

advantage is that TWiki’s functionalities are extended without altering the

core code by using API interface[37].

4.2 User Management and Authentication

Once a TWiki has been successfully set up on a web server, users are able to

register accounts. When a user logs in to TWiki, their login name is mapped

to their WikiName. A WikiName is a combination of first name and surname

- connected without a space:

Alexander Bernegger = AlexanderBernegger

TWiki authenticate the users’ identity to track actions while working[38]. All

changes on a topic or web are replicable for other users and are signed with

the WikiName of the editor/user. By registering to TWiki, every user gets

space for personal information and is able to manage their own settings.

User management consists of four sections[38]:


• User Registration: Users register accounts to gain TWikiNames. At

CERN, a user has to have an account to create or edit topics / webs. If

a user is not logged in, the user is able to read topics as TWikiGuest.

Most TWiki pages in corporate environment are restricted for guests and

are therefore not readable without registration.

• User Mapping: When login in to TWiki, a mapping from the users

credentials (username) to the users WikiName appears. This step con-

verts ”unfriendly” login names, from external authentication like SSO,

to TWiki-friendly WikiNames.

- Alexander Bernegger -> Main.AlexanderBernegger

- [email protected] -> Main.AlexanderBernegger

• Password Management: The password management defines how the

accounts are protected. In many cases, TWiki accounts are secured by

using username and password pairs to login. TWiki supports the Apache

”htpasswd” password manager and uses .htpasswd files on the server.

Alternatively other authentication methods can be used, for example

CERN’s Single Sign-on infrastructure instead of Apaches’s htpasswd

manager.

• Login Management: The login procedure describes how the user has

to login. Different methods are available: No login, login via TWiki login

page, login using web server authentication or by external authentication

procedures.

4.3 Authorization

Many topics are not protected and in such cases the user does not have to

login. However, TWiki provides access control to topics and webs in order to


restrict sensitive data from unauthorized viewing. A user who is allowed to

read a certain topic but who is not yet logged in is automatically redirected

to TWiki’s default registration page[38] where s/he is able to login or register

for a new account.

4.3.1 Default Access Control

The idea of a Wiki is to provide information for everyone. For example, the

”Wikipedia” Wiki is a collaborative online encyclopedia where users, regis-

tered or not, are free to participate by creating or editing pages and articles

or read all stored topics[6].

As explained above, in a corporate environment not all information should

be available to everyone. Certain projects only share data with members in-

volved. TWiki has the advantage that it can manage restrictions on Topics

or Webs by defining Allow/Deny commands with the respective users or user

groups[39]. Access control is set using the user’s WikiName or a TWikiGroup.

A TWikiGroup is a collection of WikiNames or other TWikiGroups[36]:

Set ALLOWWEBVIEW = TomJones, DickSmith

Set ALLOWWEBCHANGE = TomJones

This restriction example shows how to configure a web to allow two TWiki

users the right to view. The above settings are defined in the web’s preferences

file and in this example both Tom and Dick have read access but only Tom

has the right to edit topics. In case of many users, TWikiGroups facilitate this

process. For example, if Tom and Dick belong to a project along with many

other people, the following example shows how a TWikiGroup can be used to

manage access control[36]:


Set ALLOWWEBVIEW = ProjectOneGroup

Set ALLOWWEBCHANGE = TomJones

In this example, ProjectOneGroup refers to a TWiki topic that contains a list of

project members including Tom and Dick. Similar settings can be added inside

individual topics and for finer control one can also use DENY settings[36]:

Set DENYWEBVIEW = TWikiGuest

With this setting, all unregistered users are restricted from viewing the topics

of this web. In this case, a guest gets redirected to the registration page so

s/he can register or login.

4.3.2 Sessions

Once a user is successfully logged in, a walk around within the TWiki board-

ers is possible. When changing a protected Web or Topic, the access con-

trol mechanism checks the assigned privileges each time a switch takes place.

TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to

track sessions[38].

The user, once logged in, is not asked to login again unless the user opts out

by clicking ”sign off” or the session cookie loses its validity by timeout.

Cookies are used to store user specific information on the client’s computer.

This is a common way in TWiki to pass session information by holding a

unique session identifier from a TWiki server database lookup.


4.4 TWiki at CERN

At CERN, a large number of scientists work together on different projects.

One main project is the Large Hadron Collider (LHC), built by physicists and

engineers to search for answers to open questions in physics. One of the big

experiments of the LHC is the Compact Moun Solnoid (CMS) detector which

records what happens when the LHC ring smashes together protons travelling

at the speed of light. The aim is to find the mysterious Higgs-Boson particle,

a hypothetical massive scalar elementary particle which is the missing puzzle

piece of elementary physics - how do particles gain mass[40].

For organizations such as CERN, TWiki allows collaborations between users

located in different buildings, cities or even countries, providing a convenient

way of working together on projects and documents.

TWiki has been used at CERN since 2003 and has grown in popularity.

The statistics from December 2009 show over 7000 registered editors and

nearly 58000 topics (see Figure: 4.2). TWiki culture lends to open freeform

editing and most pages are world readable and editable by CERN authenti-

cated users However, access control is possible and is used to protect sensitive

documents[36].


Figure 4.2: Growth of the total number of TWiki files[2]

4.4.1 Authentication

Login and access to the TWiki installation at CERN is done via the CERN

Single Sign On authentication system, combined with the standard TWiki user

registration and TWiki user mapping. With the current setup, access control

to content in TWiki is provided via TWikiGroups which are edited manually

by local TWiki web administrators.

All registered TWiki users are mapped via the file TWikiUsers, which con-

tains the user names and email address mapping as seen from the CERN SSO

when the user registers.

4.4.2 Authorization

By default, registered CERN TWiki users have write access to all open TWiki

webs, such as the Sandbox. This open approach is very democratic, works well

and is a key contributor to the success of TWiki at CERN. However, for some

TWiki webs, it is desirable to restrict access to a list of authorized users.

Authorization in CERN’s TWiki is traditionally done via the default access

control of TWiki.

5

Spiral Software Development

When creating new software or new features of an existing program, a guideline

will help to measure everything concerning the development. The guideline is

needed to fulfill the important requirements within the estimated costs and

time. In terms of software engineering, different methodologies can be taken

as guidelines.

In this case, the method is oriented on a spiral development model, as simply

depicted in Figure 5.1. It is a model within the Software Development Life

Circle (SDLC) methodology1 and allows incremental and iterative project work

with continuous improvement, analysis of the ongoing progress and is strongly

connected to prototyping[41].

The SDLC is separated in four stages[41]:

• Planning: defining the problem, specification of new software features.

• Analysis: system study, understanding the existing system.

• Design and Implementation: defining the processes and data for the

new system, program software, building data files.

• Testing: Test the program for its functionality and figure out errors and

bugs.

1Methodology: is a recommended way of developing a software system[41].

38

5. Spiral Software Development 39

Figure 5.1: Spiral Model

Figure 5.1 shows the spiral model ADFSUserMapping development is oriented

to. It observes the following steps[42]:

The first stage in the life circle is to identify the requirements and objectives

of the software. In this part, the planning of costs - time, personnel or money

- takes place. The next step is to determine alternatives to implement a sys-

tem which fulfills the planned requirements. After this is done, the next step

is to choose one of the alternatives and to analyze its risks. If the risks are

manageable, the next part is to start the development of a prototype with

minimum effort. A validation must be performed if the prototype fulfills the

requirements and if the objectives are as planned. For the further round, the

feedback and experiences from test-users must be collected. After the first


round is done the first stage starts again. Here is important to determine new

alternatives and to see if the goals with the prototype are feasible or not. If

everything is as it shall, the improvement of the prototype can proceed. The

circle is active till the software is finished.

Every methodology and its models have advantages and disadvantages. De-

pending on the needs of a project and on the aim it should reach.

The advantage of spiral model development is that errors and bugs are found

in early stages. Contrary to the waterfall model, important issues can be dis-

covered earlier. The correction of bugs in finished products costs 100 times

more than in an analysis and development phase[43]. Furthermore, the spiral

model allows a flexible change management, what means that the software

structure or the design is easy to adapt with the next round of circle. Another

advantage is prototyping. In the early stages, a test device gets developed and

is constantly improved thereafter. It allows constructive feedback from users

who are testing the prototype[42]. On the other hand, the spiral model can be

too ceomplex for small and quick projects and may inhibit their development.

Moreover, this model is application-related and therefore needs different mod-

els for each application. The risk evaluation must be performed by experts if it

is to be considered, and this can often be more expensive than the development

itself.

5.1 SDLC Stages

Planning:

The first stage to develop new software is to plan the requirements by defining

the problem or the need for improvement of an existing system. However,


the new features of the system must be specified. This part is also called

preliminary investigation stage. From this investigation, goals, requirements,

milestones and costs get defined. The aim is to evaluate risk and project

feasibility[41].

Analysis:

The analysis part in the SDLC is separated into two different views, the static

and the dynamic. The static view is the analysis of the static model of a

system using class hierarchy and composition diagrams. It captures the generic

and essential features of a system. The dynamic view represents the system

behavior during a session, using objects and operation diagrams[41].

Development and Implementation:

In this stage, all relevant programming such as code writing, data file building

and the resolving of dependencies is performed. Furthermore, implementation

of new software may include adaption of other already existing software to be

executable.

Testing:

The testing part of the Software Development Life Circle is to find bugs and

errors and to figure out how the new program interacts with the existing

system[41].

For this procedure, a Testplan shall give a coordinated walkthrough to test all

possible actions. After this, the program should work without any problems.

6

Analyses, Implementation and

Test

While the first four chapters of this thesis have pointed out the necessary

theoretical background and the involved parts of CERN’s infrastructure, this

chapter deals with analysis and development of an interface module to enhance

the existing systems.

6.1 ADFS User Mapping

ADFSUserMapping describes an approach to incorporate e-group verification

in an existing TWiki Access Control system by introducing a new mapping

module. The goal of this module is to re-use group information from the

CERN SSO / ADFS service to facilitate maintenance of local TWiki user

groups. The following sections give an outline of the current setup and define

entry points for the development.

42

6. Analyses, Implementation and Test 43

6.2 ADFS User Mapping Development

ADFSUserMapping is a module, written in Perl Object - Oriented Program-

ming Language, to enhance TWiki’s access control mechanism by introducing

e-group alignment. It shall facilitate the administrative work of Web / Topic

owners, in order to handle access for user groups.

6.2.1 Planning

As explained in the Spiral Software Development section, planning is necessary

to handle the requirements and to create a projects life circle.

6.2.1.1 Problem Definition

For CERN, managing access control using the default method is straight for-

ward. The drawback is that the access control lists or TWikiGroups have to

be kept up to date, also for those experiments where the number of users con-

cerned can run into the thousands[36]. Since the start-up of the LHC, more

and more user groups are requesting finer control for read and write access.

It would be more convenient and secure to use the knowledge of user groups

from centrally managed e-groups. These groups could be directly applied to

protect content in TWiki instead of having to pass via an intermediate step

of making and maintaining local TWikiGroups within the scope of the TWiki

system only.

6.2.1.2 Improvement

CERN has implemented a SSO solution based on Microsoft Active Directory

Federation Services (ADFS). The SSO allows centralized authentication to dif-

ferent computing resources and web applications at CERN, thus simplifying


user logins and improving application security with a single, secure login in-

frastructure. Authorization and access to computing resources is provided via

ADFS groups, which are managed via E-groups application that allows users

and local administrators to define groups of persons for mailing lists and ac-

cess to resources[36]. Furthermore, E-groups reflecting organizational groups

at CERN are generated automatically from data in CERN’s HR database. To

connect the E-groups with the TWiki installation, ADFSUserMapping shall be

a module which takes the ADFS information and checks it against restriction

control entry in a TWiki Topic.

Instead of the standard restricting method:

Set ALLOWTOPICVIEW = <comma-delimited list: Users, Groups>

Would be enhanced as follows:

Set ALLOWTOPICVIEW = <comma-delimited list: Users, Groups, ADFS-Groups>

To fulfill this requirement, analysis of TWiki’s Access Control modules and

Apaches environment variables had to be done.


6.2.1.3 Timeline

The development timeline of ADFSUserMapping module takes place in a gen-

eral TWiki at CERN Roadmap, where milestones and project dates are in-

cluded. In this roadmap, all work concerning TWiki is planned.

Figure 6.1: TWiki at CERN Roadmap snippet

6.2.2 Analysis

The analysis part in the life circle is the most important step. Before any

development can be done, the system has to be well studied. Furthermore,

entry points have to be figured out where new changes can be introduced

without affecting or damaging the existing system. The next two sections

cover the analysis of both systems; the ADFS / E-Groups and the TWiki.

6.2.2.1 E-Groups Analysis

When authenticated to the CERN SSO, a user creates a cookie and a session

from the Shibboleth authentication provider. This session contains a number


of environment variables, among them the user name, his/her coordinates and

group membership. Thus in the environment variables from the web server,

all information about E-group membership of the user is available.

Figure 6.2: Environment Variables

Figure 6.2 shows a snippet of environment variable information which comes

from ADFS server. The environment variable HTTP_ADFS_GROUP contains all

the active directory groups and mailing lists of which the user is a member.

This user specific information is stored in the human resource database (see

Figure 3.1) and is called upon when a user logs on to a system within the circle

of trust.

In TWiki’s Perl code, the variable HTTP_ADFS_GROUP is accessible by call-

ing Apache’s ENV{variable_name}. ENV is a standard Perl module, which

imports environment variables as scalars or arrays[44].

6.2.2.2 TWiki Analysis

In this analysis, the SDLC theory of analyzing the model in a static and a

dynamic view will get used.


Static View

Any modification to the TWiki engine must coexist with the default access

control methods. A grammatical parse of the description of the current system

shows the following classes and operations for a static view.

Figure 6.3: Flowchart of User Interaction

Figure 6.3 shows the concept of the problem domain and the inter-relationships

of the classes. This scheme gets used when a user logs on to TWiki.

In each class, different actions are done by the engine. Every action is related

to a specific function. Before table 6.1 lists the classes and their functions, a

list of actions and related functions is given:

• getWebDir : returns current web directory

• getReadProtectedInfo : shows protected read information

• getWikiName : get the Wikiname to display for a canonical user iden-

tifier (cUID)

• getEmailAddress : reuturns the users E-mail address

• getCERNaccount : gets information from ADFS server

• getUserGroups : returns the users groupmemberships

• allowAccess : set allow access to a cUID


Topic getWebDir, getReadProtectedinfo, getWriteProtected-info, getRenameProtectedinfo

Web getReadProtectedinfo, getWriteProtectedinfo, getRe-nameProtectedinfo

User getTWikiName, getEmailAddress, getUserGroups,getCERNaccount

TWikiGroup getTWikiName, getTWikiGroupTWikiSession getTWikiName, allowAccess

Table 6.1: Class actions

All these functions are defined in TWikiUserMapping Perl Module and are

called upon when TWiki runs through its login routines.

Figure 6.4 shows how aggregation and generalization is done in this TWiki

static view.

Figure 6.4: Entity Relationship Model

This ER model shows the inter-relationship of the classes in TWiki. The next

part in the analysis section is the dynamic view. Use case scenarios show how


TWiki users interact with the system and models the dynamic view of the

system and will be explained in the following.

Dynamic View (Use Cases)

Use case scenarios show potential weak points and provide an idea on how to

react to different cases. Below, two use cases are shown: one showing a suc-

cessful routine, one showing a problem domain. All use cases to this analysis

can be found in Appendix C.


UseCase 4: A user wants to read a protected topic and is asked to login using

the SSO account. The page has some access control and this user is allowed

to view the topic. The topic is displayed. TWiki retains the user’s TWikiName.

Figure 6.5: TWiki Use Case 4

1. User clicks on a link to a protectedtopic.

2. TWikiSession checks the web for accesscontrol.

3. TWikiSession requests user authentica-tion.

4. TWikiSession checks the TWikiNameagainst access control settings in theweb.

5. TWikiSession checks the topic for ac-cess control.

6. TWikiSession checks the TWikiNameagainst access control settings in thetopic.

7. Topic is displayed to the user.

Use Case 4 shows a standard procedure of a login with TWiki access restric-

tions.


UseCase 8: A user wants to read a protected topic and is asked to login

using his/her SSO account. Although s/he uses the correct account, the email

address has changed and there is a mismatch between SSO and TWiki regis-

tration. The user is asked to register and is confused, since s/he believes that

s/he is already registered.

Figure 6.6: TWiki Use Case 8

1. User clicks on a link to a protectedtopic.

2. TWikiSession checks the web for accesscontrol.

3. TWikiSession requests user authentica-tion.

4. User registered, but email address haschanged

5. Mismatch between SSO and TWikiregistration

6. TwikiRegistration is displayed to theuser

7. User confused

Use Case 8 handles a problem domain. The unique identifier in CERN’s TWiki

installation is the user’s e-mail address. The user is able to change this iden-

tifier in TWiki and in SSO. Although those systems are not synchronized and

if the user changes the address only in SSO, he/she will not be able to access

TWiki anymore.

This problem can be solved by incorporating the SSO identifier (See Figure

3.6, CERN’s Service Provider) into TWiki. Thus, a hybrid solution has to be

found since lightweight users, who have no SSO account at CERN, are then

no longer able to login. A possible solution to this issue is provided in 7.1.


Concerned TWiki Modules

From the static view (see figure 6.3), the modules for authorization can be iden-

tified. The ”hasAccess” and ”isMember” are done by TWiki’s Access.pm Perl

module and TWikiUserMapping.pm Perl module. (see Appendix B for code ex-

tract).

The mapping from a username to a TWikiName is done by following mod-

ules:

TWiki::Users::BaseUserMapping

TWiki::Users::TWikiUserMapping

TWiki::UserMapping

TWiki::Users

TWiki::Access

TWiki::Users::TWikiUserMapping is the base class for user mapping. This

class has to be integrated in the new mapping module to inherit all its vari-

ables for further usage.

In Access.pm, a subroutine called TWiki::Access::checkAccessPermission

is reliable for proving a users permission to a Topic or Web. This subroutine

reads the topic settings (ALLOW / DENY) and checks the user’s TWikiName

to see whether or not it is in a list.

By call-up, checkAccessPermission sends the TWikiName to another sub-

routine, called isInList, which is located in TWiki::Users. It is the real

comparator. The subroutine returns true (1) when the user’s TWikiName is

in an ALLOW / DENY list, or false (0) when not. checkAccessPermission

receives this value and decides what to do:


• For the cases allow and true, the user will be granted and the Topic /

Web displayed. (see Figure 6.5).

• For the cases allow and false, the user will get redirected to an ”Oops -

Access Denied” webpage.

• For the cases deny and true, the user will get redirected to an ”Oops -

Access Denied” webpage.

• For the cases deny and false, the user will be granted access and the

Topic / Web displayed.

According to the static view, an enhancement of access control while checking

the settings against TWikiNames must take place. Therefore, the isInList

subroutine from TWikiUserMapping is the important piece of code for e-group

alignment and needs to be altered for further treatment.


TWiki Access Control Flowchart

To analyze the TWiki access control flows, a flowchart helps to visualize con-

cerned modules of these processes.

Figure 6.7: TWiki Topic Access Flowchart


Figure 6.7 shows a flowchart of how TWiki handles access control from a static

view. When a user clicks on a Topic or Web the Access.pm module first checks

if the user is logged in. If not, a redirect to CERN’s SSO login webpage fol-

lows. The user is now requested to login. After a correct sign-on, the mapping

module maps the user’s login credential to a TWikiName and Apache loads all

relevant information from ADFS server. (e.g. HTTP_ADFS_GROUP, See Figure

6.2).

After this step, checkAccessPermission reads out the Topic / Web settings

and checks if the user fulfills this. The first stage of this alignment is a DENY

Topic check (see checkAccessPermission.pm in Appendix B.1). If the user is

denied, a redirect to TWiki’s ”Oops - Access Denied” webpage appears. If

there are no DENY settings, it checks the ALLOW Topic. Since the Topic

settings overrides the Web ones, a further ALLOW Web check has to be done

if Topic is not set. A last alignment, to check if the user has root access, must

be executed. In such a case, a Web and Topic restriction loses their validity.

checkAccessPermission handles Web check in the same way as Topic check.

View vs. Viewauth

View and Viewauth are read modes in TWiki. View is the open, not restricted,

access on topics and webs. A guest can read all data as long as there is no

Viewauth set. Viewauth forces TWiki to change to authentication mode. For

example, a topic which is restricted to a certain group of users forces the ses-

sion to change the URL when an ALLOW or DENY command is stored.

As guest, the URL comes with a view.

”https://twiki.cern.ch/twiki/bin/view/Main/WebHome”

If the requestor is not logged in yet, the registration page - or at CERN, the


SSO login page - gets displayed before any further actions can be done. If the

requestor is already logged in, an isInList check will get executed to see if

the user is in an ALLOW or DENY list.

A restricted Topic, comes with a Viewauth in URL.

”https://twiki.cern.ch/twiki-beta/bin/viewauth/Main/RestrictedArea”

The RestrictedArea Topic is set with an ALLOW view command:

Set ALLOWTOPICVIEW = Main.AlexanderBernegger.

The change from View to Viewauth is important for this development be-

cause only in Viewauth modemode is the E-group data from SSO available in

Apache’s ENV. The next section is the development and implementation of

the module.

6.2.3 Development and Implementation

In this development and improvement section, the information gained from

the analysis section will be used. The coding is done in Perl Object Oriented

Programming language to be compatible with the TWiki code and is written

on Linux editor ”gedit” and eclipse integrated development environment (IDE)

with EPIC1 plugin.

1Eclipse Perl Integration


6.2.3.1 Module Development

First, a new empty module with the name ADFSUserMapping.pm is created.

This module is stored in the TWiki directory /twiki/lib/TWiki/Users/ on

Apache’s web server (or IIS when using Microsoft).

Please find the complete module listing in Appendix A. For readability rea-

sons, only the important code pieces will get shown in the listing 6.1.

1 #/ tw i k i / l i b /TWiki/Users/ADFSUserMapping .pm

2 #Per l Module f o r TWiki Enterpr i s e

3

4 package TWiki : : Users : : ADFSUserMapping ;

5 use base ’TWiki : : Users : : TWikiUserMapping ’ ;

6 use s t r i c t ;

7

8 use vars qw ( $u r l $names $names2 $ ident $ad f s g roups

$ a d f s u s e r $ a d f s g r o u p s l i s t ) ;

9

10 sub TWiki : : Users : : i s I n L i s t {

11 my( $ th i s , $cUID , $ u s e r l i s t , $user ) = @ ;

12

13 my $ur l = TWiki : : Users : : ADFSUserMapping : :

r ed i r ec tV iew ( ) ; #subrou t ine c a l l to change Twiki

in viewauth mode when DENY i s s e t .

14 i f ( $u r l ne 0){

15 $th i s−>TWiki : : Func : : r ed i rectCg iQuery ( $ur l , 1) ;

#re d i r e c t to u r l in viewauth mode .

16 }


17

18 #comma de l im i t e d l i s t o f user s or groups

19 # i . e . : ”Main . UserA , UserB , Main . UserC # something

e l s e ”

20 $ u s e r l i s t =˜ s/(<[ˆ>]∗>)//go ; # Remove HTML tag s

21

22 return 0 unless defined $cUID ;

23

24 foreach my $ ident ( sp l i t ( /\ ,/ , $ u s e r l i s t ) ) { #

s p l i t w i thout space / [\ ,\ s ]+/

25

26 $ad f s g roups = $ENV{HTTP ADFS GROUP} ;

27 next unless $ENV{HTTP ADFS GROUP} ;

28 $names2 = $TWiki : : Users : : TWikiUserMapping : :

names2 ;

29

30 # Compare ADFS Groups wi th Access Contro l S e t t i n g s

31 foreach $ a d f s g r o u p s l i s t ( sp l i t ( / [ ; ] / ,

$ad f s g roups ) ){

32 next unless $ a d f s g r o u p s l i s t ;

33 $ ident =˜s/ˆ\ s ∗ ( .∗ ? ) \s∗$/$1 / ; #trim

34 i f ( $ a d f s g r o u p s l i s t =˜ m/ˆ $ ident$ / i ) {

35 return 1 ;

36 }

37

38 # Compare ADFS Groups wi th Access Contro l S e t t i n g s in

TWikiGroups

39 foreach $names ( sp l i t ( / [ , ] / , $names2 ) ) {


40 next unless $names ;

41 $names =˜s/ˆ\ s ∗ ( .∗ ? ) \s∗$/$1 / ; #trim

42 i f ( $ a d f s g r o u p s l i s t =˜ m/ˆ$names$/ i ){

43 return 1 ;

44 }

45 }

46 }

47

48 }

49 return 0 ;

Listing 6.1: ADFSUserMapping Development Listing

The above shown listing is the modified isInList function. By defining the

whole path (TWiki::Users::isInList) as subroutine name, the new routine

overrides the old one in Users.pm.

TWiki::Users::TWikiUserMapping is the base class for this module and in-

herits all its attributes. The first part of the subroutine is a DENY check.

It reads out the settings from redirectView() and returns true value ($url)

or false value (0 ). The built-in function redirectCgiQuery is a program to

change the URL, here from view to viewauth (see section 6.2.2.2).

The next part is the main isInList comparator. It gets the values from

$userlist (TWiki Topic setting) and splits the names in single entries into

$ident. The ADFS values can be imported From Apache’s environment vari-

ables, for example with the command HTTP_ADFS_GROUPS.

$names2 is a variable coming from _expandUserList function to be able to

work with settings in TWikiGroups (These settings are encapsulated and must


first be expanded).

After all the important values have been uploaded, the comparison can take

place. This is a regular expression with pattern matching. If the ADFS group’s

settings matches the TWiki Topic settings, a true (1 ) will get returned to

checkAccessPermission function.

$adfs groups list $ident True?IT-DEP CERN Users NoAustrians at CERN CERN Users NoCERN Users CERN Users yes

Table 6.2: Comparing Table

The same happens with the next comparison, the check against TWikiGroup

settings. If all fail, a Perl false 0 value is returned to the requesting function.

6.2.3.2 DENY View Problem

The implementation shown above works well for ALLOW view settings in

Topics and Webs. When a DENY command is set, no change from View to

Viewauth appears. This is because DENY is stricter than ALLOW. For exam-

ple, a Web or Topic owner can exclude TWiki Guests from viewing by defining

a DENY command for them. For a DENY, no further action, such as forc-

ing to Viewauth, has to be done. The denied person just receives an ”Oops

webpage” as a result and gets redirected to the last public page s/he came from.

To use DENY settings for SSO E-groups, an additional step is relevant to

bypass this problem. In the following development (listing 6.2), an artificial

Viewauth force gets implemented.


1 sub r ed i r ec tV iew {

2 #This sub rou t ine i s needed to face the DENYview problem .

DENY won ’ t change view to viewauth au t oma t i c a l l y .

3

4 my $ t h i s ;

5 my $denyTextTopic = $TWiki : : Access : : t ext2 ; # =

f i l t e r out deny from Topicpre f s

6 my $denyTextWeb = $TWiki : : Access : : t ext3 ; # =

f i l t e r out deny from Webprefs − only i f

denyweb i s s e t .

7

8 my $ur l = $ENV{REQUEST URI} ;

9 i f ( $denyTextTopic =˜ m/DENY/){

10 $ur l =˜ s/view/ viewauth /g ;

11 i f ( $u r l =˜ m/ viewauth \//){

12 return $ur l ;

13 }

14 }

15

16 i f ( $denyTextWeb =˜ /\S/ ){


18 i f ( $u r l =˜ m/ viewauth \//){

19 return $ur l ;

20 }

21 }

22 return 0 ;

23 }

Listing 6.2: ADFSUserMapping Development DENY View Solution


Listing 6.2 shows a new subroutine in ADFSUserMapping.pm module.

This subroutine faces the problems with DENY settings. In the first part,

values from checkAccessPermission get imported. These variables contain

the TWiki Topic settings. If the word DENY appears, the current URL will get

replaced with the authentication version viewauth and returned to isInList

subroutine. If no DENY is in the setting text, a false value will get returned

and no URL replacement occurs.

6.2.3.3 Other Changes

Next to the module development, this enhancement affects other parts of the

source code. To get a successful improvement, additional changes have to be

done.

The new mapping module must being activated by changing the system con-

figuration settings in TWiki/lib/LocalSite.cfg. This setting is configured

to TWiki’s standard UserMapper:

$TWiki::cfg{UserMappingManager} = ’TWiki::Users::TWikiUserMapping’;

To guide the compiler to the new mapper, the path after the equal sign has to

be modified:

$TWiki::cfg{UserMappingManager} = ’TWiki::Users::ADFSUserMapping’;

According to the DENY view problem, checkAccessPermission in Access.pm

and _expandUserList in TWikiUserMapping.pm needs to be altered in or-

der to read out variables at runtime. (see listing 6.2 DENY View Prob-

lem: variable $denyTextTopic, $denyTextWeb). Please find the modified

checkAccessPermission / _expandUserList subroutines in Appendix B.1


After these changes, ADFSUserMapping has its full functionality and is ready

for use. The next chapter handles the testing phase. It is needed to find bugs

within the code and to check if the module is working for all possible situations.


6.3 Testing

As stated in section 5.1 of this thesis, the last stage in SDLC is testing. After

discussing development and implementation in the last sections, the coming

paragraphs point out tests done for the module ADFSUserMapping after which

the results of this testing are presented. In order to not to interfere with

the production system, all tests are first planned and done on an identical

test-server and the module is only transferred into production if all possible

problems are fixed. After the successful installation of the module on the test-

server, a testing plan is made to cover all possible positive and negative effects

on the system. The next section describes the testing plan developed.

6.3.1 System Testing

This testing covers the module implementation on the existing system.

Test if the module works and monitor Apache’s error and warning logs while

running. Check if all TWiki functionalities (log on/off, create / edit /move /

rename topic and web, test WYSIWYG) work as they should.

All installed TWiki Plugins have to be tested to see if they work in com-

bination with the new ADFSUserMapping module (see Results in Appendix

D). After the system has been tested and no errors or warnings occurred, the

program itself has to be tested for its features and its compatibility.


6.3.2 Program Testing

This testing plan covers the program’s behavior during a normal execution.

Access control set in a TWiki topic:

The first tests with the new module are the restriction settings. The settings

ALLOWTOPICVIEW, ALLOWTOPICCHANGE, DENYTOPICVIEW, DENY-

TOPICCHANGE in combination with an E-group must be tested in a TWiki

Topic. For this scenario, a TWiki Topic with the name ”RestrictedArea” was

generated and the settings placed in as standard commands. For each test

run, only one of the four settings was activated. The next tests were to set a

command with a user in a TWiki Group and with a user in an E-group. This

test shows if it is possible to use the new module in combination with standard

restriction of TWiki groups (e.g.: Set ALLOWTOPICVIEW = TWikiAdmin-

Group, CERN E-groups). If the test is successful, another test with a setting

of DENY for one E-group and ALLOW for another E-group has to be done.

The important thing is to find out which command is stronger, or which com-

mand gets executed first. The question: ”What happens if the user is in

both groups?” helps provide an answer to the previous question as well. To

last, the first test with the different settings must be performed again with

e-groups written in uppercase, lowercase, mixed upper and lowercase, frag-

mentary spelled, misspelled and as an email address.

All this tests were done in a TWiki Topic. The next test plan is specific

for TWiki Web restrictions.

Access control set in TWiki WebPreferences:

Since the Web restrictions are concerning the same permission routines, all the

tests done in RestrictedArea Topic can be executed in Web settings as well.


Therefore, a test Web with the name MainWeb gets generated. In its pref-

erences, the restriction settings are already set with whitespace. This means

everybody is allowed, no one is restricted. For the ongoing tests, the whites-

pace has to be exchanged to a user, a TWiki group or an E-group.

In addition to the tests in a Topic, an equal restriction method, one in Web

and one in Topic, must be set to discover if the WebPreferences are overwritten

by Topic settings as they should be. (see Figure 6.7).

Miscellaneous testing in Topic and Web:

For this part of the test plan, miscellaneous testing of both Web and Topic

will be executed. The first is to try ALLOWWEBVIEW for E-group it-dep-des

AND DENYWEBVIEW for TWikiGuest AND DENYTOPICVIEW for Twiki

user AlexanderBernegger. This will provide information about what happens

when AlexanderBernegger is not a guest, but denied for Topic and allowed for

Web. Furthermore, a test with DENY and ALLOW in one Topic with the

same E-group shall test the compiling order. Which is stronger than the other

one? The same must be done in Web preferences.

Two sessions testing, logged in and as TWiki Guest

The test for two different sessions is used to figure out if ADFSUserMapping

module works in both cases. As done in the previous test parts, the standard

restriction settings have to be tested here as logged-in user and as a guest.

E-groups in TWiki groups

The E-groups in TWiki groups tests shall show if encapsulated E-group in

Twiki groups also can be used for restricting access.


6.4 Results

The development of ADFSUserMapping module has been an iterative process.

After the first round of the Software Development Life Circle stages, the testing

of the developed prototype showed that the restricting method DENY won’t

work in combination with ADFS groups. This was detected while running

program specific tests as explained in 6.3. In the test ”Test ADFS groups with

Restriction Settings”, the DENY mode erroneous allowed the restricted ADFS

group. Due to the urgent need for this module, a first version was installed

on production server to be able to operate only in ALLOW mode. It was dis-

covered that the ALLOW mode is more important for restricting than DENY

because allowing only one special group means an automatic refusal for all

others. This was a first solution for the LHC project group CMS in November

2009.

As shown in section 6.2.3.2 of this thesis the DENY view problem was solved

by introducing a new subroutine (redirectView) to ADFSUserMapping mod-

ule. This piece of code changes into the important authentication mode and

DENY was from now on able to work with ADFS groups. Furthermore, the

encapsulated restriction of TWikiGroups which contain ADFS E-groups was

also not possible due to TWiki’s - users in TWikiGroups - handling. To be

able to use the encapsulated information, the function _expandUserList has

to be implemented to grab these values.

The most difficult part was to find the concerning functions for each prob-

lem. Since TWiki has about 630 files in its library2 and each file has numerous

amounts of built in subroutines and functions, many analyzing periods were

necessary between the development and testing phase.

2checked on TWiki-4.3.2, Georgetown


After all, the module worked as planned in section 6.2.1 and was ready for

installation on production server.

Please find all testing results in Appendix E.

7

Conclusion

This Diploma Thesis gives an outline of how TWiki can be combined with a

Single Sign-On solution. The goal was to incorporate security aspects to the

TWiki installation by regulating its access over CERN SSO accounts.

The approach, to incorporate e-group verification in existing TWiki Access

Control system, was successfully done by installing the developed ADFSUserMap-

ping module to the production TWiki. After the e-groups in TWikiGroups and

the DENY View problem was solved, all standard restriction settings worked

with ADFS e-groups as they should. The defined goals of this Thesis have been

achieved and the module can be installed and used for every TWiki installation.

In terms of OpenSource, the ADFSUserMapping module is made available in

the TWiki Extensions Repository on TWiki.org and can be used by everyone

for further development.

69

7. Conclusion 70

7.1 Outlook

According to the TWikiAtCern Roadmap (See Figure 6.1), the ADFSUserMap-

ping module for e-group alignment is a part of a larger project. The roadmap

contains ideas to remove the necessity of the TWiki user lists and use the spe-

cific information from CERN SSO accounts instead. This will facilitate user

handling because the current unique identifier is a user’s mail address which

has to be kept up-to-date. Every time a user changes the mail address only

in SSO environment, a TWiki administrator must change the TWiki address

manually too (See Use Case no. 8 in figure: 6.6).

The switch to this step has to be discussed first since users who do not have

a CERN account (so called light-weight users), would then no longer be able

to use the TWiki collaboration. A hybrid solution, using CERN accounts

as unique identifier and TWiki userlists for non-CERN-Personnel, can be a

conceivable solution to this problem.

Bibliography

[1] A Pace. Identity Management. oai:cds.cern.ch:1054162. Technical Report

CERN-IT-Note-2007-005, CERN, Geneva, Sep 2007.

[2] Pete Jones. CERN TWiki Statistics. https://twiki.cern.ch/twiki/

bin/view/Main/CERNTWikiStatistics.

[3] Peter Thoeny. TWiki.org, Main Page. http://twiki.org (1998-2009).

[4] Bill McCreary. Web Collaboration How It Is Impacting Business. http:

//www.bsu.edu/mcobwin/majb/?p=600.

[5] AllConferenceServices.com. Web Collaboration. http://www.

allconferenceservices.com/web-collaboration.html.

[6] Wikipedia Enzyclopedia. Wikipedia. http://en.wikipedia.org/wiki/

Wikipedia.

[7] MediaWiki. MediaWiki. http://www.mediawiki.org/wiki/MediaWiki/

de.

[8] TimeBridge. Web Collaboration Platform. http://www.timebridge.

com/pages/features-overview.

[9] Google Groups. Web Collaboration Platform. http://groups.google.

com/intl/de/googlegroups/tour3/index.html#?lnk=hptt.

71

https://twiki.cern.ch/twiki/bin/view/Main/CERNTWikiStatistics

https://twiki.cern.ch/twiki/bin/view/Main/CERNTWikiStatistics

http://twiki.org

http://www.bsu.edu/mcobwin/majb/?p=600

http://www.bsu.edu/mcobwin/majb/?p=600

http://www.allconferenceservices.com/web-collaboration.html

http://www.allconferenceservices.com/web-collaboration.html

http://en.wikipedia.org/wiki/Wikipedia

http://en.wikipedia.org/wiki/Wikipedia

http://www.mediawiki.org/wiki/MediaWiki/de

http://www.mediawiki.org/wiki/MediaWiki/de

http://www.timebridge.com/pages/features-overview

http://www.timebridge.com/pages/features-overview

http://groups.google.com/intl/de/googlegroups/tour3/index.html#?lnk=hptt

http://groups.google.com/intl/de/googlegroups/tour3/index.html#?lnk=hptt

Bibliography 72

[10] TextFlow. Web Collaboration Platform. http://www.nordicriver.com/

#main.

[11] Present.io. Web Collaboration Platform. http://drop.io/about.

[12] Microsoft SharePoint. Collaboration Tool. http://sharepoint.

microsoft.com/de-at/Seiten/default.aspx.

[13] Ward Cunningham. Wiki. http://wiki.org/wiki.cgi?WhatIsWiki.

[14] A. Ebersbach. WikiTools. Springer, Berlin, 2007.

[15] Peter Thoeny. Wiki Collaboration and Wiki Applications for the

Enterprise. LinuxWorld; http://twiki.org/cgi-bin/view/Codev/

TWikiPresentation11Aug2005 (11 Aug 2005).

[16] SearchSecurit.com. Authorization, Authentication, Accounting.

http://searchsecurity.techtarget.com/sDefinition/0,,sid14_

gci514544,00.html (01.07.2007).

[17] Topbits.com. Two Factor Authentication. http://www.topbits.com/

two-factor-authentication.html (2010).

[18] RSA Security. One Time Password. ftp://ftp.rsasecurity.com/pub/

otps/kerberos/draft-ietf-krb-wg-otp-preauth-10.html.

[19] M. WP3, Edited by: Gasson, M. Meints, and Warwick K. D3.2: A study

on PKI and biometrics. Future of Identity in the Information Society,

July 2005.

[20] JoelWeise. Public Key Infrastructure, Overview. Sun Microsystems, Inc.,

July 2005.

[21] MIT. MIT Kerberos. http://web.mit.edu/kerberos/www/ (2010).

http://www.nordicriver.com/#main

http://www.nordicriver.com/#main

http://drop.io/about

http://sharepoint.microsoft.com/de-at/Seiten/default.aspx

http://sharepoint.microsoft.com/de-at/Seiten/default.aspx

http://wiki.org/wiki.cgi?WhatIsWiki

http://twiki.org/cgi-bin/view/Codev/TWikiPresentation11Aug2005

http://twiki.org/cgi-bin/view/Codev/TWikiPresentation11Aug2005

http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci514544,00.html

http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci514544,00.html

http://www.topbits.com/two-factor-authentication.html

http://www.topbits.com/two-factor-authentication.html

ftp://ftp.rsasecurity.com/pub/otps/kerberos/draft-ietf-krb-wg-otp-preauth-10.html

ftp://ftp.rsasecurity.com/pub/otps/kerberos/draft-ietf-krb-wg-otp-preauth-10.html

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

Bibliography 73

[22] C Neumann. Kerberos: An Authentication Service for Computer Net-

works. Technical Report Volume 32, Number 9, pages 33-38, IEEE, Sep

1994.

[23] Topbits.com. Accounting. http://www.topbits.com/accounting.html

(2010).

[24] Emmanuel Ormancey. CERN Single Sign On Solution.

oai:cds.cern.ch:1054179. Technical Report CERN-IT-Note-2007-006,

CERN, Geneva, Sep 2007.

[25] C. Dunne. Build and implement a single sign-on solution. IBM Technical

Library, September 2003. Internet Magazine (https://www.ibm.com/

developerworks/web/library/wa-singlesign/#ibm-pcon).

[26] Developer Tutorials. Single Sign On. http://www.developertutorials.

com/tutorials/java/single-sign-on/page7.html.

[27] O. Rummeyer and J. Dsterhaus. SSO frei Haus. Entwickler Maga-

zin, 1(5), September 2006. Internet Magazine (http://entwickler.de/

zonen/portale/psecom,id,101,online,910,p,0.html).

[28] R. Muldoon and S. Fullerton. Web Initial Sign-on (WebISO)

- requirements. Internet2 Draft, December 2001. Internet

Magazine (http://middleware.internet2.edu/webiso/docs/

draft-internet2-webiso-requirements-07.html).

[29] SSOCircle. SSOCircle Identity Provider. http://www.ssocircle.com/

de/idp.shtml.

[30] Microsoft Corporation. Overview of ADFS. Technical report, Microsoft

TechNet Library, Redmond, CA., Aug 2005.

http://www.topbits.com/accounting.html

https://www.ibm.com/developerworks/web/library/wa-singlesign/#ibm-pcon

https://www.ibm.com/developerworks/web/library/wa-singlesign/#ibm-pcon

http://www.developertutorials.com/tutorials/java/single-sign-on/page7.html

http://www.developertutorials.com/tutorials/java/single-sign-on/page7.html

http://entwickler.de/zonen/portale/psecom,id,101,online,910,p,0.html

http://entwickler.de/zonen/portale/psecom,id,101,online,910,p,0.html

http://middleware.internet2.edu/webiso/docs/draft-internet2-webiso-requirements-07.html

http://middleware.internet2.edu/webiso/docs/draft-internet2-webiso-requirements-07.html

http://www.ssocircle.com/de/idp.shtml

http://www.ssocircle.com/de/idp.shtml

Bibliography 74

[31] Microsoft Corporation. WS-Federation: Passive Requestor Profile. Tech-

nical report, Microsoft TechNet Library, Redmond, CA., Jul 2003.

[32] G. Martin and M. Hadley. SOAP Version 1.2 Part 1: Messaging Frame-

work (Second Edition). W3C Recommendation, April 2007. Internet Mag-

azine (http://www.w3.org/TR/soap12-part1/).

[33] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services. Springer,

Berlin, 2004.

[34] Internet2 Middleware. Shibboleths. http://shibboleth.internet2.

edu/about.html.

[35] Pete Jones. TWiki facilitates collaborative information handling at

CERN. CERN Computer Newsletter (CNL) http://cerncourier.com/

cws/article/cnl/27095.

[36] P. Jones, A. Bernegger, and N. Hoimyr. Integrating CERN e-groups into

TWiki access control. CERN IOP Publishing, April 2010.

[37] Peter Thoeny. TWiki Plugins. http://twiki.org/cgi-bin/view/

TWiki/TWikiPlugins.

[38] Peter Thoeny. TWiki Authentication. http://twiki.org/cgi-bin/

view/TWiki/TWikiUserAuthentication.

[39] Peter Thoeny. TWiki Access Control. http://twiki.org/cgi-bin/

view/TWiki/TWikiAccessControl.

[40] David Barney. Compact Muon Solenoid (CMS). http://visits.web.

cern.ch/visits/guides/tools/manual/deutsch/CMS.html.

[41] Everett, G. and McLeod, R. Software Testing. IEEE Press, 2007.

http://www.w3.org/TR/soap12-part1/

http://shibboleth.internet2.edu/about.html

http://shibboleth.internet2.edu/about.html

http://cerncourier.com/cws/article/cnl/27095

http://cerncourier.com/cws/article/cnl/27095

http://twiki.org/cgi-bin/view/TWiki/TWikiPlugins

http://twiki.org/cgi-bin/view/TWiki/TWikiPlugins

http://twiki.org/cgi-bin/view/TWiki/TWikiUserAuthentication

http://twiki.org/cgi-bin/view/TWiki/TWikiUserAuthentication

http://twiki.org/cgi-bin/view/TWiki/TWikiAccessControl

http://twiki.org/cgi-bin/view/TWiki/TWikiAccessControl

http://visits.web.cern.ch/visits/guides/tools/manual/deutsch/CMS.html

http://visits.web.cern.ch/visits/guides/tools/manual/deutsch/CMS.html

Bibliography 75

[42] Capretz, L. and Capretz, M. Object Oriented Software: Design and Main-

tenance. World Scientific Publishing Co., 1996.

[43] Heistracher, T. Software Engineering, SWE-08-M2-Current UML Intro.

http://www.users.fh-sbg.ac.at/~theistra/.

[44] Perldoc. Perl Programming Documentation: ENV. http://perldoc.

perl.org/Env.html.

http://www.users.fh-sbg.ac.at/~theistra/

http://perldoc.perl.org/Env.html

http://perldoc.perl.org/Env.html

List of Abbreviations

2FA . . . . . . . . . . . . . . . . . . . Two Factor Authentication

AAA . . . . . . . . . . . . . . . . . . Authentication, Authorization, Accounting

ACL . . . . . . . . . . . . . . . . . . . Access Control List

ADFS . . . . . . . . . . . . . . . . . Active Directory Federation Service

AFS . . . . . . . . . . . . . . . . . . . Andrew File System

AM . . . . . . . . . . . . . . . . . . . . Access Management

AS . . . . . . . . . . . . . . . . . . . . . Authentication Server

CA . . . . . . . . . . . . . . . . . . . . Certificate Authority

CERN . . . . . . . . . . . . . . . . . Conseil Europen pour la Recherche Nuclaire

CMS . . . . . . . . . . . . . . . . . . . Compact Moun Solonoid

CoT . . . . . . . . . . . . . . . . . . . Circle of Trust

CRL . . . . . . . . . . . . . . . . . . . Certificate Revocation List

DFS . . . . . . . . . . . . . . . . . . . Distributed File System

IDE . . . . . . . . . . . . . . . . . . . Integrated Development Environment

ENV . . . . . . . . . . . . . . . . . . . Environment Variables

GNU . . . . . . . . . . . . . . . . . . General Public License

HR . . . . . . . . . . . . . . . . . . . . Human Resource

IAM . . . . . . . . . . . . . . . . . . . Identity & Access Management

IdP . . . . . . . . . . . . . . . . . . . . Identity Provider

IIS . . . . . . . . . . . . . . . . . . . . . Internet Information Services

IM . . . . . . . . . . . . . . . . . . . . . Identity Management

76

List of Abbreviations 77

KDC . . . . . . . . . . . . . . . . . . Key Distribution Center

LHC . . . . . . . . . . . . . . . . . . . Large Hadron Collider

OTP . . . . . . . . . . . . . . . . . . . One Time Password

PES . . . . . . . . . . . . . . . . . . . Platforms and Engineering Tools

PRP . . . . . . . . . . . . . . . . . . . Passive Requestor Profile

RA . . . . . . . . . . . . . . . . . . . . Registration Authority

RCS . . . . . . . . . . . . . . . . . . . Revision Control System

SAML . . . . . . . . . . . . . . . . . Security Assertion Markup Language

SDLC . . . . . . . . . . . . . . . . . Software Development Life Circle

shibd . . . . . . . . . . . . . . . . . . Shibboleth Daemon

SP . . . . . . . . . . . . . . . . . . . . . Service Provider

SSO . . . . . . . . . . . . . . . . . . . Single Sign-On

TGS . . . . . . . . . . . . . . . . . . . Ticket Granting Server

TWiki . . . . . . . . . . . . . . . . . Take-Five Wiki

WS . . . . . . . . . . . . . . . . . . . . Web Services

WYSIWYG . . . . . . . . . . . . What-You-See-Is-What-You-Get

Appendix

78

A

ADFSUserMapping.pm

1 # Users Module o f TWiki Ente rpr i s e Co l l a bo ra t i on

Platform , h t t p ://TWiki . org /

2 # Author : Alexander Bernegger

3 # Al l Righ ts Reserved . TWiki Cont r i bu tor s

4 # are l i s t e d in the AUTHORS f i l e in the roo t o f t h i s

d i s t r i b u t i o n .

5 # NOTE: Please extend t ha t f i l e , not t h i s no t i c e .

6 #

7 # This program i s f r e e so f tware ; you can r e d i s t r i b u t e i t

and/or

8 # modify i t under the terms o f the GNU General Pub l i c

License

9 # as pub l i s h ed by the Free Sof tware Foundation ; e i t h e r

ve r s i on 2

10 # of the License , or ( at your opt ion ) any l a t e r ve r s i on .

For

11 # more d e t a i l s read LICENSE in the roo t o f t h i s

d i s t r i b u t i o n .

12 #

13 # This program i s d i s t r i b u t e d in the hope t ha t i t w i l l

be u s e f u l ,

14 # but WITHOUT ANY WARRANTY; wi thou t even the imp l i ed

warranty o f

79

A. ADFSUserMapping.pm 80

15 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

16 #

17 # As per the GPL, removal o f t h i s no t i c e i s p r o h i b i t e d .

18

19 =pod

20 −−−+ package TWiki : : Users : : ADFSUserMapping

21 This package prov ide s an extended UserMapping proce s s .

22 Groups , wich are p r ede f i n ed in an ADFS database , can now

be used

23 to g ive a c c e s s to t o p i c s in Twiki .

24 Just d e f i n e ALLOWTOPICVIEW = ADFSGroupName .

25 The matching i s case i n s e n s i t i v e .

26

27

28 use Func : : writeDebug for debugging .

29

30 =cut

31

32 package TWiki : : Users : : ADFSUserMapping ;

33 use base ’TWiki : : Users : : TWikiUserMapping ’ ;

34 use base ’TWiki : : Access ’ ;

35 use s t r i c t ;

36 use TWiki ;

37

38

39

40 use vars qw ( $u r l $names $names2 $ ident $debug

$ad f s g roups $ a d f s u s e r $ a d f s g r o u p s l i s t $rmuser ) ;


41

42 $debug = 1 ;

43

44 sub r ed i r ec tV iew {

45 #This sub rou t ine i s needed to face the DENYview problem .

DENY won ’ t change

46 #view to viewauth au t oma t i c a l l y .

47

48 my $ t h i s = sh i f t ;

49 my $denyTextTopic = $TWiki : : Access : : t ext2 ; # =

f i l t e r out deny from Topicpre f s

50 my $denyTextWeb = $TWiki : : Access : : t ext3 ; # =

f i l t e r out deny from Webprefs − only i f

denyweb i s s e t .

51

52 #TWiki : : Func : : writeDebug (” t o p i c : $denyTextTopic

”) i f $debug ;

53 #TWiki : : Func : : writeDebug (”Web: $denyTextWeb ”) i f

$debug ;

54

55 my $ur l = $ENV{REQUEST URI} ;

56 i f ( $denyTextTopic =˜ m/DENY/){


58 i f ( $u r l =˜ m/ viewauth \//){

59 return $ur l ;

60 }

61 else { $ur l = 0 ;}

62 }


63

64 i f ( defined ( $denyTextWeb ) ){


66 i f ( $u r l =˜ m/ viewauth \//){

67 return $ur l ;

68 }

69 else { $ur l = 0 ;}

70 }

71

72 return 0 ;

73 }

74

75 sub TWiki : : Users : : i s I n L i s t {

76

77 my( $ th i s , $cUID , $ u s e r l i s t , $user ) = @ ;

78

79 my $ur l = TWiki : : Users : : ADFSUserMapping : :

r ed i r ec tV iew ( ) ; #subrou t ine c a l l to change

Twiki in viewauth mode when DENY i s s e t .

80 i f ( $u r l ne 0){

81 $th i s−>TWiki : : Func : : r ed i rectCg iQuery ( $ur l , 1) ;

#re d i r e c t to u r l in viewauth mode .

82 }

83

84 return 0 unless $ u s e r l i s t ;

85

86 #comma de l im i t e d l i s t o f user s or groups



e l s e ”


89


91

92 foreach my $ ident ( sp l i t ( /\ ,/ , $ u s e r l i s t ) ) {

#s p l i t w i thou t space / [\ ,\ s ]+/

93

94 #Dump the user s web s p e c i f i e r i f userweb

95 $ ident =˜ s /ˆ( $TWiki : : c f g {UsersWebName}|%

USERSWEB%|%MAINWEB%)\ . / / ;

96 next unless $ ident ;

97 my $identCUID = $th i s−>getCanonicalUserID ( $ ident

) ;

98 i f ( defined $identCUID ) {

99 return 1 i f ( $identCUID eq $cUID ) ;

100 }

101 i f ( $ th i s−>isGroup ( $ ident ) ) {

102 return 1 i f ( $ th i s−>i sInGroup ( $cUID , $ ident

) ) ;

103 }

104

105 $ad f s g roups = $ENV{HTTP ADFS GROUP} ;

106 next unless $ENV{HTTP ADFS GROUP} ;

107 $names2 = $TWiki : : Users : : TWikiUserMapping : :

names2 ;

108


109

110 foreach $ a d f s g r o u p s l i s t ( sp l i t ( / [ ; ] / ,

$ad f s g roups ) ){

111 next unless $ a d f s g r o u p s l i s t ;

112 $ ident =˜s/ˆ\ s ∗ ( .∗ ? ) \s∗$/$1 / ; #trim

113 i f ( $ a d f s g r o u p s l i s t =˜ m/ˆ $ ident$ / i ) {

114 return 1 ;

115 }

116

117 foreach $names ( sp l i t ( / [ , ] / , $names2 ) ) {

118 next unless $names ;

119 $names =˜s/ˆ\ s ∗ ( .∗ ? ) \s∗$/$1 / ; #trim

120 i f ( $ a d f s g r o u p s l i s t =˜ m/ˆ$names$/ i ){

121 return 1 ;

122 }

123

124 }

125 }

126

127 }

128 return 0 ;

129 }

130

131

132 1 ;

Listing A.1: ADFSUserMapping Module


A.1 Original isInList function

1 sub i s I n L i s t {

2 my( $ th i s , $cUID , $ u s e r l i s t ) = @ ;

3

4 return 0 unless $ u s e r l i s t ;

5

6 # comma de l im i t e d l i s t o f user s or groups

7 # i . e . : ”%USERSWEB%.UserA , UserB , Main . UserC #

something e l s e ”


9


11

12 foreach my $ ident ( sp l i t ( / [\ ,\ s ]+/ , $ u s e r l i s t ) )

{

13 # Dump the user s web s p e c i f i e r i f userweb

14 $ ident =˜ s /ˆ( $TWiki : : c f g {UsersWebName}|%

USERSWEB%|%MAINWEB%)\ . / / ;


16 my $identCUID = $th i s−>getCanonicalUserID ( $ ident

) ;

17 i f ( defined $identCUID ) {

18 return 1 i f ( $identCUID eq $cUID ) ;

19 }


21 return 1 i f ( $ th i s−>i sInGroup ( $cUID , $ ident

) ) ;

22 }


23

24

25 }

26 return 0 ;

27 }

Listing A.2: Original isInList Subroutine

B

Concerned Modules

B.1 CheckAccessPermission Changes

1 our ( $text2 , $text3 ) ; # new g l o b a l v a r i a b l e

2

3 sub checkAccessPermiss ion {

4 my( $ th i s , $mode , $user , $text , $meta , $topic , $web

) = @ ;

5

6 $text2 = $text ; # new g l o b a l v a r i a b l e

7

8 undef $th i s−>{ f a i l u r e } ;

9

10 print STDERR ”Check $mode a c c e s s $user to ” . ( $web | |

’ undef ’ ) . ’ . ’ . ( $ top i c | | ’ undef ’ ) . ”\n” i f MONITOR;

11 #TWiki : : Func : : writeDebug (”Check $mode acces s $user

to ” . ( $web | | ’ undef ’ ) . ’ . ’ . ( $ t o p i c | | ’ undef ’ ) .”\n

”) i f $debug ;

12 # super admin i s a lways a l l owed

13 i f ( $ th i s−>{s e s s i o n}−>{use r s}−>isAdmin ( $user ) ) {

14 print STDERR ” $user − ADMIN\n” i f MONITOR;

15 return 1 ;

16 }

17

87

B. Concerned Modules 88

18 $mode = uc ( $mode ) ; # upper case

19

20 my $ p r e f s = $th i s−>{s e s s i o n}−>{p r e f s } ;

21

22 my $al lowText ;

23 my $denyText ;

24

25 # ex t r a c t the ∗ Set (ALLOWTOPIC|DENYTOPIC)$mode

26 i f ( defined $text ) {

27 # over r i d e t o p i c permiss ions .

28 $al lowText = $pre f s−>getTextPre fe rencesValue (

29 ’ALLOWTOPIC’ . $mode , $text , $meta , $web ,

$ top i c ) ;

30 $denyText = $pre f s−>getTextPre fe rencesValue (

31 ’DENYTOPIC’ . $mode , $text , $meta , $web ,

$ top i c ) ;

32

33 } e l s i f ( $ top i c ) {

34 $al lowText = $pre f s−>getTopicPre fe rencesVa lue ( ’

ALLOWTOPIC’ . $mode , $web , $ top i c ) ;

35 $denyText = $pre f s−>getTopicPre fe rencesVa lue ( ’

DENYTOPIC’ . $mode , $web , $ top i c ) ;

36 }

37

38

39 # Check DENYTOPIC

40 i f ( defined ( $denyText ) ) {

41 i f ( $denyText =˜ /\S$/ ) {


42 i f ( ( $ th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t (

$user , $denyText ) ) ) {

43 $th i s−>{ f a i l u r e } = $th i s−>{s e s s i o n}−>

i18n−>maketext ( ’ a c c e s s denied on

top i c ’ ) ;

44 print STDERR $th i s−>{ f a i l u r e } . ” (

$denyText )\n” i f MONITOR;

45 return 0 ;

46 }

47 } else {

48 # I f DENYTOPIC i s empty , don ’ t deny anyone

49 print STDERR ”DENYTOPIC i s empty\n” i f

MONITOR;

50 return 1 ;

51 }

52 }

53

54 # Check ALLOWTOPIC. I f t h i s i s de f i ned the user

must be in i t

55 i f ( defined ( $al lowText ) && $allowText =˜ /\S/ ) {

56 i f ( $ th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t ( $user ,

$al lowText ) ) {

57 print STDERR ” in ALLOWTOPIC\n” i f MONITOR;

58 return 1 ;

59 }

60 $th i s−>{ f a i l u r e } = $th i s−>{s e s s i o n}−>i18n−>

maketext ( ’ a c c e s s not a l lowed on top i c ’ ) ;


61 print STDERR $th i s−>{ f a i l u r e } . ” ( $al lowText )\n”

i f MONITOR;

62 return 0 ;

63 }

64

65 # Check DENYWEB, but on ly i f DENYTOPIC i s not s e t (

even i f i t

66 # i s empty − empty means ”don ’ t deny anybody ”)

67 unless ( defined ( $denyText ) ) {

68 $denyText =

69 $pre f s−>getWebPreferencesValue ( ’DENYWEB’ .

$mode , $web ) ;

70

71 $text3 = $denyText ; # new g l o b a l v a r i a b l e

72

73 i f ( defined ( $denyText ) &&

74 $th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t ( $user

, $denyText ) ) {


maketext ( ’ a c c e s s denied on web ’ ) ;

76 print STDERR $th i s−>{ f a i l u r e } . ”\n” i f

MONITOR;

77 return 0 ;

78 }

79 }

80

81 # Check ALLOWWEB. I f t h i s i s d e f i ned and not

overr idden by


82 # ALLOWTOPIC, the user must be in i t .

83 $al lowText = $pre f s−>getWebPreferencesValue ( ’

ALLOWWEB’ . $mode , $web ) ;

84

85 i f ( defined ( $al lowText ) && $allowText =˜ /\S/ ) {

86 unless ( $ th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t (

$user , $al lowText ) ) {


maketext ( ’ a c c e s s not a l lowed on web ’ ) ;


MONITOR;

89 return 0 ;

90 }

91 }

92

93 # Check DENYROOT and ALLOWROOT, but on ly i f web i s

not de f ined

94 unless ( $web ) {

95 $denyText =

96 $pre f s−>ge tPre f e r ence sVa lue ( ’DENYROOT’ . $mode ,

$web ) ;

97 i f ( defined ( $denyText ) &&

98 $th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t ( $user

, $denyText ) ) {


maketext ( ’ a c c e s s denied on root ’ ) ;


MONITOR;


101 return 0 ;

102 }

103

104 $al lowText = $pre f s−>ge tPre f e r ence sVa lue ( ’

ALLOWROOT’ . $mode , $web ) ;

105

106 i f ( defined ( $al lowText ) && $allowText =˜ /\S/

) {

107 unless ( $ th i s−>{s e s s i o n}−>{use r s}−> i s I n L i s t (

$user , $al lowText ) ) {

108 $th i s−>{ f a i l u r e } = $th i s−>{s e s s i o n}−>

i18n−>maketext ( ’ a c c e s s not a l lowed on

root ’ ) ;


MONITOR;

110 return 0 ;

111 }

112 }

113 }

114

115 i f ( MONITOR ) {

116 print STDERR ”OK, permitted \n” ;

117 print STDERR ”ALLOW: $al lowText\n” i f defined

$al lowText ;

118 print STDERR ”DENY: $denyText\n” i f defined

$denyText ;

119 }

120 return 1 ;


121 }

Listing B.1: new checkAccessPermission Subroutine

B.2 ExpandUserList Changes

1 our $names2 ; # new g l o b a l v a r i a b l e

2 sub expandUserList {

3 my( $ th i s , $names ) = @ ;

4 $names | |= ’ ’ ;

5 # comma de l im i t e d l i s t o f user s or groups


e l s e ”

7 $names =˜ s/(<[ˆ>]∗>)//go ; # Remove HTML tag s

8

9 $names2 = $names ; #new g l o b a l v a r i a b l e

10

11 my @l ;

12 foreach my $ ident ( sp l i t ( / [\ ,\ s ]+/ , $names ) ) {

13 # Dump the web s p e c i f i e r i f userweb

14 $ ident =˜ s /ˆ( $TWiki : : c f g {UsersWebName } |Main |

Main) \ . / / ;



17 my $ i t = $th i s−>eachGroupMember ( $ ident ) ;

18 while ( $ i t−>hasNext ( ) ) {

19 push( @l , $ i t−>next ( ) ) ;

20 }

21 } else {


22 # Might be a w ik i name ( w ik i names may map

to s e v e r a l cUIDs)

23 my %namel i s t = map { $ => 1 }

24 @{ $th i s−>{s e s s i o n}−>{use r s}−>

findUserByWikiName ( $ ident ) } ;

25 # May be a l o g i n name ( l o g i n names map to a

s i n g l e cUID)

26 my $cUID = $th i s−>{s e s s i o n}−>{use r s}−>

getCanonicalUserID (

27 $ ident ) ;

28 $namel i s t {$cUID} = 1 i f $cUID ;

29 push( @l , keys %namel i s t ) ;

30 }

31 }

32

33 return \@l ;

34 }

Listing B.2: new expandUserList Subroutine

C

Use Cases

1. A user wants to read a protected topic and is asked to login using the

SSO account. The user has access the topic is then displayed. TWiki

retains the users TWikiName.


SSO account. The page has some access control and this user is al-

lowed to view the topic. The topic is displayed. TWiki retains the users

TWikiName.

Figure C.1: TWiki Use Case 2

(a) User clicks on a link to a protectedtopic.

(b) TWikiSession checks the topic for ac-cess control

(c) TWikiSession requests user authentica-tion

(d) TWikiSession checks the TWikiNameagainst access control settings in thepage

(e) Topic is displayed to the user.

95

C. Use Cases 96

3. A user wants to read a protected topic and is asked to login using the SSO

account. The page has some access control and this user can not view

the topic. An error is displayed. TWiki retains the users TWikiName.



(b) TWikiSession checks the web for accesscontrol


(d) TWikiSession checks the TWikiNameagainst access control settings in theweb

(e) TWikiSession checks the topic for ac-cess control

(f) TWikiSession checks the TWikiNameagainst access control settings in thetopic

(g) User has no access rights to the topic

(h) Error message is displayed to the user.

C. Use Cases 97


SSO account. The web that contains the topic has some access control

and this user is able view pages in this web. The topic is displayed.

TWiki retains the users TWikiName.






(e) TWikiSession checks the topic for ac-cess control

(f) TWikiSession checks the TWikiNameagainst access control settings in thetopic

(g) Topic is displayed to the user.

C. Use Cases 98


SSO account. The web that contains the topic has some access control

and this user can not view pages in this web. An error is displayed.

TWiki retains the users TWikiName.






(e) User has no access rights to the web

(f) Error message is displayed to the user.

C. Use Cases 99


SSO account. The user has not yet registered and is asked to register.

Following registration the user continues as above. TWiki retains the

users TWikiName.





(d) User not registered

(e) TwikiRegistration is displayed to theuser

(f) TWikiSession checks the TWikiNameagainst access control settings in theweb

(g) TWikiSession checks the topic for ac-cess control

(h) TWikiSession checks the TWikiNameagainst access control settings in thetopic

(i) Topic is displayed to the user.

C. Use Cases 100


SSO account. He authenticates using an account that is different from

the one registered in TWiki. The user is then asked to register and is

confused as he thinks that he is already registered.





(d) User registered, but log on with secondaccount (mail address)


(f) User confused

C. Use Cases 101


SSO account. He uses the correct account but the email address has

changed and there is a mismatch between SSO and TWiki registration.

The user is asked to register and is confused as he thinks that he is

already registered.


(a) TWikiSession checks the web for accesscontrol

(b) TWikiSession requests user authentica-tion

(c) User registered, but email address haschanged

(d) Mismatch between SSO and TWikiregistration


(f) User confused

D

Plugin Test

102

D. Plugin Test 103

Figure D.1: Test ADFSUserMapping Module with Installed Plugins

E

Test Results

104

E. Test Results 105

Figure E.1: Results for Topic and Web Restrictions

E. Test Results 106

Figure E.2: Results for Two Session Testing

E. Test Results 107

Figure E.3: Results for E-groups in TWikiGroups Testing

Documents

Authentication, Authorization and Security Aspects of