Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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]
2. Wiki Web Collaboration 5
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.
2. Wiki Web Collaboration 6
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].
3. Authentication and Authorization in Web Collaborative Applications 9
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.
3. Authentication and Authorization in Web Collaborative Applications 10
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. Authentication and Authorization in Web Collaborative Applications 11
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
3. Authentication and Authorization in Web Collaborative Applications 12
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].
3. Authentication and Authorization in Web Collaborative Applications 13
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.
3. Authentication and Authorization in Web Collaborative Applications 14
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
3. Authentication and Authorization in Web Collaborative Applications 15
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.
3. Authentication and Authorization in Web Collaborative Applications 16
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. Authentication and Authorization in Web Collaborative Applications 17
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
3. Authentication and Authorization in Web Collaborative Applications 18
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
3. Authentication and Authorization in Web Collaborative Applications 19
• 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
3. Authentication and Authorization in Web Collaborative Applications 20
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.
3. Authentication and Authorization in Web Collaborative Applications 21
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.
3. Authentication and Authorization in Web Collaborative Applications 22
• (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. Authentication and Authorization in Web Collaborative Applications 23
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. Authentication and Authorization in Web Collaborative Applications 24
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
3. Authentication and Authorization in Web Collaborative Applications 25
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.
3. Authentication and Authorization in Web Collaborative Applications 26
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. Authentication and Authorization in Web Collaborative Applications 27
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
3. Authentication and Authorization in Web Collaborative Applications 28
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.
3. Authentication and Authorization in Web Collaborative Applications 29
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:
4. TWiki Enterprise 32
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]:
4. TWiki Enterprise 33
• 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
4. TWiki Enterprise 34
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]:
4. TWiki Enterprise 35
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. TWiki Enterprise 36
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].
4. TWiki Enterprise 37
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
5. Spiral Software Development 40
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,
5. Spiral Software Development 41
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
6. Analyses, Implementation and Test 44
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. Analyses, Implementation and Test 45
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
6. Analyses, Implementation and Test 46
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.
6. Analyses, Implementation and Test 47
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
6. Analyses, Implementation and Test 48
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
6. Analyses, Implementation and Test 49
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.
6. Analyses, Implementation and Test 50
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.
6. Analyses, Implementation and Test 51
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.
6. Analyses, Implementation and Test 52
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:
6. Analyses, Implementation and Test 53
• 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.
6. Analyses, Implementation and Test 54
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
6. Analyses, Implementation and Test 55
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
6. Analyses, Implementation and Test 56
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. Analyses, Implementation and Test 57
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 }
6. Analyses, Implementation and Test 58
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 ) ) {
6. Analyses, Implementation and Test 59
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
6. Analyses, Implementation and Test 60
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.
6. Analyses, Implementation and Test 61
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/ ){
17 $ur l =˜ s/view/ viewauth /g ;
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
6. Analyses, Implementation and Test 62
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
6. Analyses, Implementation and Test 63
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. Analyses, Implementation and Test 64
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. Analyses, Implementation and Test 65
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.
6. Analyses, Implementation and Test 66
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. Analyses, Implementation and Test 67
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
6. Analyses, Implementation and Test 68
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
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).
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.
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.
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.
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 ) ;
A. ADFSUserMapping.pm 81
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/){
57 $ur l =˜ s/view/ viewauth /g ;
58 i f ( $u r l =˜ m/ viewauth \//){
59 return $ur l ;
60 }
61 else { $ur l = 0 ;}
62 }
A. ADFSUserMapping.pm 82
63
64 i f ( defined ( $denyTextWeb ) ){
65 $ur l =˜ s/view/ viewauth /g ;
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
A. ADFSUserMapping.pm 83
87 # i . e . : ”Main . UserA , UserB , Main . UserC # something
e l s e ”
88 $ u s e r l i s t =˜ s/(<[ˆ>]∗>)//go ; # Remove HTML tag s
89
90 return 0 unless defined $cUID ;
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
A. ADFSUserMapping.pm 84
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. ADFSUserMapping.pm 85
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 ”
8 $ u s e r l i s t =˜ s/(<[ˆ>]∗>)//go ; # Remove HTML tag s
9
10 return 0 unless defined $cUID ;
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%)\ . / / ;
15 next unless $ ident ;
16 my $identCUID = $th i s−>getCanonicalUserID ( $ ident
) ;
17 i f ( defined $identCUID ) {
18 return 1 i f ( $identCUID eq $cUID ) ;
19 }
20 i f ( $ th i s−>isGroup ( $ ident ) ) {
21 return 1 i f ( $ th i s−>i sInGroup ( $cUID , $ ident
) ) ;
22 }
A. ADFSUserMapping.pm 86
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$/ ) {
B. Concerned Modules 89
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 ’ ) ;
B. Concerned Modules 90
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 ) ) {
75 $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 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
B. Concerned Modules 91
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 ) ) {
87 $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 web ’ ) ;
88 print STDERR $th i s−>{ f a i l u r e } . ”\n” i f
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 ) ) {
99 $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 root ’ ) ;
100 print STDERR $th i s−>{ f a i l u r e } . ”\n” i f
MONITOR;
B. Concerned Modules 92
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 ’ ) ;
109 print STDERR $th i s−>{ f a i l u r e } . ”\n” i f
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 ;
B. Concerned Modules 93
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
6 # i . e . : ”Main . UserA , UserB , Main . UserC # something
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) \ . / / ;
15 next unless $ ident ;
16 i f ( $ th i s−>isGroup ( $ ident ) ) {
17 my $ i t = $th i s−>eachGroupMember ( $ ident ) ;
18 while ( $ i t−>hasNext ( ) ) {
19 push( @l , $ i t−>next ( ) ) ;
20 }
21 } else {
B. Concerned Modules 94
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.
2. 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 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.
Figure C.2: TWiki Use Case 3
(a) User clicks on a link to a protectedtopic.
(b) TWikiSession checks the web for accesscontrol
(c) TWikiSession requests user authentica-tion
(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
4. A user wants to read a protected topic and is asked to login using the
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.
Figure C.3: TWiki Use Case 4
(a) User clicks on a link to a protectedtopic.
(b) TWikiSession checks the web for accesscontrol
(c) TWikiSession requests user authentica-tion
(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) Topic is displayed to the user.
C. Use Cases 98
5. A user wants to read a protected topic and is asked to login using the
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.
Figure C.4: TWiki Use Case 5
(a) User clicks on a link to a protectedtopic.
(b) TWikiSession checks the web for accesscontrol
(c) TWikiSession requests user authentica-tion
(d) TWikiSession checks the TWikiNameagainst access control settings in theweb
(e) User has no access rights to the web
(f) Error message is displayed to the user.
C. Use Cases 99
6. A user wants to read a protected topic and is asked to login using the
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.
Figure C.5: TWiki Use Case 6
(a) User clicks on a link to a protectedtopic.
(b) TWikiSession checks the web for accesscontrol
(c) TWikiSession requests user authentica-tion
(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
7. A user wants to read a protected topic and is asked to login using the
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.
Figure C.6: TWiki Use Case 7
(a) User clicks on a link to a protectedtopic.
(b) TWikiSession checks the web for accesscontrol
(c) TWikiSession requests user authentica-tion
(d) User registered, but log on with secondaccount (mail address)
(e) TwikiRegistration is displayed to theuser
(f) User confused
C. Use Cases 101
8. A user wants to read a protected topic and is asked to login using the
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.
Figure C.7: TWiki Use Case 8
(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
(e) TwikiRegistration is displayed to theuser
(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