Authentication, Authorization and
Security Aspects of Collaborative Web
Applications - Case: TWiki and Single
Sign-On
prepared for the
Salzburg University of Applied Sciences
Degree Program
Information Technology & Systems Management
submitted by:
Alexander Bernegger
Head of Faculty:
FH-Prof. DI Dr. Gerhard J¨ochtlSupervisor:
Simon KranzerHerewith I, Alexander Bernegger, declare that I have written the present diploma thesis fully on my own and that I have not used any other sources apart from those given.
Alexander Bernegger Matrikelnummer
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, in a very special way to Peter Jones and Nils Himyr for helping me write this Thesis and giving me steady support. Furthermore, I’d like to thank Simon Kranzer for his guidance and supervision during this Thesis work.
University: Salzburg University of Applied Sciences Degree Program: Information Technology & Systems
Manage-ment
Title of Thesis: Authentication, Authorization and Security Aspects of Collaborative Web Applications -Case: TWiki and Single Sign-On
Academic Supervisor: Simon Kranzer
Company Supervisor: Peter Jones, Nils Høimyr
Keywords
1st Keyword: Collaborative Networks
2nd Keyword: Authentication 3nd Keyword: Single Sign On
4nd Keyword: Security
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.
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.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
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
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
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.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
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
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.
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.
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:
• 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 Specification
MediaWiki 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, access controls[12]
Table 2.1: Overview Web Collaboration Platforms
1Wikipedia Enzyclopedia[6] 2MediaWiki[7]
Due to the fact that the implementation done in this work is using a Wiki for WC, the following section describes the concepts Wiki are based on and chapter 4 provides an overview of TWiki, the platform used at CERN.
Besides Wikis, WC can be done using one of the platforms shown in table 2.1. More information on WC can be found in [4] and [5]
2.1
Wikis
Howard ”Ward’ G. Cunningham, the founder and developer of the first Wiki [13], defined Wiki as:
Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslink between internal pages on the fly.
Following by that, the idea behind a Wiki is to create a free collaboration platform, open to and editable by everybody to share information with other participants[14]. A Wiki can be seen as a Content Management System (CMS), designed to facilitate planning and documenting work. It can get used as a knowledgebase of results from researches, for example. The name Wiki comes from the Hawaiian word ”Wiki-Wiki”, which means quick or hurry-on. This is what Wikis are known for, the speed and ease with which content can be created or changed. The WikiWikiWeb-Server technology allows nonlinear hypertext structure for navigation. A user can choose from the next cross reference and is not constrained to following page-per-page references. Fur-thermore, a Wiki user can create and edit existing topics ”on-the-fly”. This means the user is able to use a Wiki without installing additional software.
The concept of Wiki is free collaboration for everybody
Giving each user the opportunity to read and change can be dangerous, es-pecially in protected areas such as companies or research facilities. The re-quirements of corporate collaboration cannot be fulfilled using conventional Wikis; there are no proper control, - security, - and audit trail mechanisms available[15]. For this reason, an enterprise solution is prefereable when using collaborative software in companies. Enterprise Wikis have the same function-alities as normal Wikis but include additional optimized enhancements such as access and reversion controls for replicability and are able to address the inter-nal challenges of business processes. Besides the usual Wiki features, enterprise software in corporate collaborations should also cover proper communication and conferencing tools, a document handling system as well as access and ver-sion control mechanisms[15].
An API Interface gives the possibility of including enhancements such as plug-ins if the standard features don’t meet the needs. From the original Wiki, a lot of derivates are available (see Figure 2.1). The TWiki3 Enterprise
col-laboration is a Perl-based structured Wiki application designed for large user environments and has restriction mechanisms to prohibit users from unau-thorized viewing. It is a web-based platform which fosters information flows within an organization and helps to facilitate the distribution of project team. Because of its fine grained access controls, it is optimal for sensible data col-laborations in corporate environments[15].
TWiki and its features will be covered in more depth in chapter 4.
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
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 idenIden-tity when registering to a system, it must be proven in an accurate way to prevent fraud later. This can be solved by bringing evidence such as identity docu-ments like passport or personal ID card. Once a person has been registered as a valid user, the validation can always rely on this official, approved data. Identity management (IM) describes how to handle these processes.
IM begins when an employee begins work at a company by entering all rele-vant personal information such as name, social insurance number, department, position and technical objects such as network printers, internal processes and procedures. IM in combination with Access Management (AM) becomes ”Iden-tity and Access Management” (IAM), where AM describes the actions a user is allowed to do in a system. (e.g.: Checks who ”I AM” and provides access). AM can be done using a database with personalized entries which are set up at the beginning of a user’s employment relationship. In these lookup tables (see Table 3.1), time- or location-dependent information such as read- and write-settings, access to applications, accounts, printers or even rooms is saved[1].
Resource Right Subject
cn=Floor1, ou=printer print cn user=JohnDoe, o=cern, c=ch cn=AFS, ou=directory read/write cn group=IT-DEP, o=cern, c=ch cn=Root, ou=folder write cn group=sysadmin, o=cern, c=ch cn=Bldg 31, ou=rooms enter cn user=JohnSmith, o=cern, c=ch
Table 3.1: Lookup Table of Access Rights[1]
Table 3.1 is an example of a lookup table for managing an employee’s access and rights on resources. For example, in the first row user ”John Doe” is a member of CERN in Switzerland and is able to use the printer in Floor 1. His right is defined by ”print” for this particular action. In the second row read and write access on a directory is granted to all members of the group ”IT-DEP”. In such a case, groups are a logical aggregation of members or groups, which allow to pool identities.
Figure 3.1: Architecture of CERN’s IAM process[1]
Figure 3.1 shows an architectural example of an IAM process[1]. When a person starts a working contract, the administration stores all relevant infor-mation in the Human Resources (HR) database. This data is validated by the person’s ID documents and can be used for further authentication. In the Account Database, the employee’s privileges are stored as shown in Table 3.1. Additionally, every employee is placed into work-related groups, so called E- Groups. These groups allow the simplification of access management by giving privileges to a whole group instead of a single person. When a user wants access to a restricted service, the systems authorization process checks if the user or the user’s e-group is permitted. By using a validation method such as typing the credentials to a login-screen, the IAM framework checks the correctness of the request. If the entries of the lookup table are set for the requested service, access is granted.
The next section provides an overview of how identities can be managed in a secure network.
3.2
Authentication, Authorization,
Account-ing
The ”genuineness” of a user’s identity must be controlled to ensure that it is original and true. The process known as Authentication, Authorization, Ac-counting (AAA) describes such a guideline of architectures and handles the requirements of an IAM procedure[16].
Although these three parts are independent of each other, when taken in com-bination they are an important security in network environments[1]. This procedure will be explained in the following section.
3.2.1
Authentication
Authentication is the first step in proving a user’s identity when a system logon appears. This step must reference to the identity management database. The confidential login data provided to the employee upon registration is compared with the data in the look-up tables, where personalized information is stored. This means that every user’s initiated process has its own ”label” with the name of the person who requests[1].
Authentication services can be realized in several implementations. The most common technique is to use a user/password phrase pair as a login procedure. As mentioned in the introduction part of this section, this traditional method has potential weak points (such as the writing down of passwords). There are more secure ways to examine the correctness of a person’s identity:
A Two Factor Authentication (2FA) is an authentication procedure which has more than one check-routine. A standard user/password method can be enhanced with additional electronic certificates, smartcards, hardware tokens or even biometric techniques to grant access to a user. A 2FA is separated into
three basic factors:
• Something the user knows (e.g. pin, key, password) • Something a user has (hardware token, smart card) • Something a user is (fingerprint, biometric information)
At least, two of these factors must be combined to get a two factor authenti-cation; ”a something you have” and ”a something you know” concept is the most used authentication system[17].
Example - Pin with One Time Password (OTP):
A user wants to access a specific service. To login, the user’s known secret password and a randomized password from a token must be entered. An OTP token has a predefined set of passwords and chooses one randomly by activat-ing it. The user types in both the secret password and the token generated one. The authentication instance on the service side checks these passwords against the same list the token has defined. If the token password is found and the user password matches the account entry, access is granted. The used OTP password then loses its validity[18].
A Public Key Infrastructure explains the method of using digital certifi-cates which are generated, saved and distributed in the background of a sys-tem. These digital signatures combine a public key with an identity and can be used as an individual certificate to validate a user. In many PKI schemes a centralized service takes the role of certification. These services are called ”Certificate Authority” (CA) or ”Registration Authority” (RA) and can be seen as ”trusted-third-parties” [19].
PKI functions[20]:
Public Key Cryptography is reliable for generation, distribution and con-trol of cryptographic keys.
Certificate Issuance the binding instance, joins a public key with a private individual, organization or other entity.
Certificate Validation verifies the existence and the validity of a trust re-lationship certificate.
Certificate Revocation handles expired certificates and manages Certificate Revocation Lists (CRL)1.
PKI Example[20]:
1. Alice and Bob generate a public / private key pair
2. Both publish their public keys to a registration authority
3. RA validates their credentials and transmits the information to the CA 4. CA then generates certificates for Alice’s and Bob’s public keys and signs
them with the CA’s private key
5. As a result, both Alice and Bob have a public / private key pair and a public key certificate
6. Data can now be signed with a digital signature to assure confidentiality and integrity
Kerberos is a computer network authentication protocol, which secures trans-fer flows between server and client by verifying each other’s identity. Kerberos uses symmetric-key cryptography and incorporates the advantages of a CA[21]. It is based on ticketing, which is responsible for proving the user’s identity.
Kerberos Functions[22]:
Key Distribution Center (KDC) manages a secret key database. Every entity in a network exchanges secret keys with KDC. If one entity wants to communicate with another, the KDC creates a session key, which is generated out of both secret keys and delivers a ticket (Kerberos ticket) with the session key to the communication partners. Both partners are validated and can es-tablish a connection.
Authentication Server (AS) authenticates the entities in a network envi-ronment.
Ticket granting Server (TGS) supports authentication without password re-entry.
Ticket Cache stores authentication tickets during a session. This step is important for single sign on solutions operating over a ticketing service..
3.2.2
Authorization
The authorization section of the triple AAA procedure defines how to grasp on resources. Authorization is a part of a login routine where identity has already
been validated and the authentication process has been passed through. It can be seen as a predefined set of policies describing what proven users are able to do in a system[1]. These policies are maintained by system administrators and are often called Access Control Lists (ACL). If a user wants to have access to a certain resource, a token or ticket mechanism checks the user’s unique identifier against an access list to prove its permissiveness. Authorization can be implemented either by the system (native functionality of an operating sys-tem) or by an application, which adopts the requirements. The user’s privilege entities of access lists can be defined as read/write rights to files, directories, accounts, as well as physical access to rooms, buildings or archives. Session dependent entries, such as ”access in work hours only”, can also be regulated in authorize - ACLs.
3.2.3
Accounting
This part of the framework is responsible for tracking the user’s actions in an information system; it is a journal of what users did while they were logged on (who, when, where, what). Traceability is an essential item in terms of incident handling. This process has become increasingly refined in recent years. Early accounting systems were only able to track a user’s access to specific systems; today the process is able to record single menu items or even database cells[23].
3.3
IAM Use Case
Table 3.2 shows a summary of an IAM process. For example, before a person comes to CERN to start a work relationship, s/he must verify their identity by sending a copy of their passport. Using this personal data, the HR department creates an account containing all work related groups and access regulations.
The username is then a combination of the first letter from first name and seven letters from the surname. On the first work day, the user gets a document with this username and a password and a demand note to change the password to a personal secret word. From now on, every action the user performs with his/her username will get tracked for traceability.
Provided by Answer the questions: Attributes Identity user ”who are you?” Public assertion Authentication user ”How can you prove it?” Secret response Authorization system ”What can I do?” Access control Accounting system ”Tracking my actions” Traceability
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].
only one unique central account database and one login procedure to trans-act authentication to different software systems. It handles access controls for multiple, related but independent applications. A user is able to login to one system and gains admission to all applications within an SSO environment (circle of trust) without being prompted to login again when changing plat-forms.
Ideally, the requestor has only one username and only needs to pass the iden-tity check process once to be able to access all network resources. The reverse process is called Single Sign Off; with one click, the user opts out from every opened platform he called during a session[26].
Generally, an SSO solution brings benefits by making work easier for the user and closes potential leaks or reduces security holes by avoiding multiple creden-tials. On top of this, it facilitates administrative work. Privileges for groups can be changed quickly or a new user can acquire access to all systems by one single entry in the database. In the opposite manner, excluding or blocking a user from the circle of trust can be performed in seconds.
Changing a running system by introducing a new mechanism has advantages and disadvantages. Before a new system can get installed, it must be evalu-ated to see whether or not there is an end benefit. The following list shows the advantages and disadvantages of SSO.
Advantages[25]:
• Improved user productivity • Simple administration
• One unique central account database • One authentication process per session
• Reduce ”password fatigue2”
• Multiple applications, portals, systems • User group management for authorization • Reduce labor and monetary costs
The universal access can also be seen as a negative feature. This might be an interest point for hacking (single point of attack). Another negative is the need to adapt existing systems. This is most likely connected with additional costs[25].
3.4.2
Types of SSO Models
A SSO model can be realized in different ways. The best model is chosen according to need and technical feasibility.
3.4.2.1 Circle of Trust
In the space of a Single Sign-On infrastructure, a Circle of Trust (CoT) de-scribes virtual separated application communities. A user granted access to one service is then able to move between the services inside a circle of trust without being prompted to for a second login[27]. The user authenticates at the first site and is issued a ticket which is valid for all other locations inside the CoT.
Figure 3.2 shows a simplified diagram of a CoT model. A user is able to login at any client and if the authentication is accepted, the user is able to move freely within the CoT.
Figure 3.2: Circle of Trust 3.4.2.2 Centralized Sign-on Server
A centralized Single Sign-On server is a model that acts like a CoT model, but has a dedicated authentication server which handles all user information and controls tickets or tokens. The client logs on to the server and gets a circle-wide valid ticket to access applications within boundaries[27].
Figure 3.3 shows a simplified example of a centralized Single Sign-on architec-ture.
Every request to a service is first directed to the central SSO server. The user logs on with credentials and gains a circle-wide personal ticket. SSO for-wards the client’s request to the desired service by using return addresses from the service. The application verifies the given ticket and, if correct, grants access.
Figure 3.3: Centralized Single Sign-On
3.4.3
SSO Authentication Methods
When introducing an SSO model to an existing environment, security increases when the human-driven ”password fatigue” factor is reduced to a minimum. Although this increases security, it also makes it possible for intruders to access all areas by entering only one site. The new weak point in the security chain is the portal where Single Sign-On takes place. To combat the security weakness of a single entry point, SSO infrastructure provides different authentication models with different security levels[24]:
• (weak) Classic Web Form: A standard web page with username / password pair to login. Possibility to store credentials in browser cookies for later use.
• (medium) Windows Integrated Authentication: from the current logon to a windows operating system, a token is used to verify the user’s genuineness and to authenticate to other systems. Absolutely required: desktop lock when leaving the workspace.
• (strong) Certificates: Authentication can be enhanced by incorporat-ing a Certificate Authority (CA) to the process. The user gets a verified certificate from a trusted third party to authenticate when requests on resources appear.
• (strong+) Combination: More factor authentication, as explained in in the chapter on authentication (see 3.1.3.1 Authentication), increases security levels by combining certificates with smartcard tokens or other additional methods.
• (very strong) Biometrics: enhancement of combination. Using hu-man biometric information, such as eye-scans, fingerprint scan or voice recording authentication methods additional to a CoT.
3.4.4
Authentication Token
When a user successfully logs in to a system, an instance combines the re-quested address of a service with a session-dependent token. With this token, the user is able to access all services within the trusted circle. Every resource must check the validity of the token prior to access being granted. If the va-lidity has expired or there is not yet a token in the HTTP header, a redirect to the login page appears.
Figure 3.4: SSO Infrastructure
Figure 3.4 shows a general overview of a SSO infrastructure. (drawn at gliffy.com) A user enters a trusted circle by calling an application. The ac-cess control instance checks if there is a token within the request and whether or not the token is valid. If the token is not valid, the user must authenticate and is then forwarded to the requested service.
3.5
Single Sign-On at CERN
There are several ways to realize a SSO model as explained above. In large part, this depends on the requirements of the network and how it will be used when it is installed[28]. This section will give information about CERN’s SSO infrastructure; it is a real model and will be used as an example here. Other models will not be explained further because it would go beyond the scope of this thesis.
CERN’S Single Sign-On has two main components: the Identity Provider and the Service Provider. It uses a token-based system, which communicates over SAML3[24].
3.5.1
Identity Provider
The identity provider (IdP) is the main actor in an SSO structure. It is respon-sible for authentication and for generating user-specific attributes. Its software checks the user’s identity against a database when a logon appears. IdP sup-ports several authentication methods and provides communication protocols like SAML[29] or Kerberos. After verification of the user’s credentials, it loads the specific information for the requested service or application and delivers it to the service provider (SP). These attributes can be different for every appli-cation, depending on the security level of each one[24].
3Security Assertion Markup Language: a XML-dialect for exchanging authentication and authorization information between domains
Figure 3.5: CERN’s Identity Provider
CERN’ identity provider is realized by a software, a specification and a proto-col component.
Software:
For the identity provider, CERN uses Microsoft’s Active Directory Federation Service (ADFS). This is an extension of Microsoft’s Active Directory authen-tication database for Web Services Architectures (WS-Federation4). ADFS is a component in Windows Server 2003 R2 which provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing dig-ital identity and entitlement rights across security and enterprise boundaries. (http://technet.microsoft.com/en-us/library/cc755828%28WS.10%29.aspx)
ADFS provides federation and Web SSO. When using Active Directory ser-vices, the benefit of SSO solution through Windows integrated authentication
4WS-Federation is a identity federation specification, defines mechanisms for allowing disparate security realms to broker information on identities, identity attributes and au-thentication.
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 determine whether particular sets of credentials from a source satisfy the relevant security policies of the target.
3.5.2
Service Provider
The service provider (SP) gets the verified user information from the identity provider and allows access to the requested web applications. It is the client side of an SSO infrastructure and can be done either by Microsoft’s Internet Information Service (IIS) or Apache’s web server module.
On Linux /Apache hosted web sites, CERN uses the Shibboleth module: Shib-boleth is Open Source middleware software, which allows applications to make informed authorization decisions for individual access of protected online re-sources in a privacy-preserving manner. It uses federated identity standards and provides extended privacy functionality[34].
Shibboleth Single Sign-on provides a reduction of multiple passwords to mul-tiple applications. The security aspect will improve by preventing ”password write-down” and at the same time it causes a minimization of account manage-ment work. Further, it allows interoperability within and across organizational boundaries and enables service providers to control access to their resources.
As an example, CERN uses Win Services, Terminal Services, AFS (Andrew File System), DFS (Distributed File System) and NICE6 (see Figure 3.6) as
Service Provider Applications.
6NICE: Providing a consistent environment through which Windows users at CERN can obtain resources, applications and managed operating system services
Figure 3.6: CERN’s Service Provider
3.5.3
Procedure
Example: a user wants to have access to a CERN service, e.g. mailbox infor-mation. This web application is part of circle of trust and needs authentication. The IIS module checks the requestor’s HTTP header to see if there is a token and if it is valid. The user is requested to log in since s/he has successfully logged off from last session. The user is redirected to the central SSO web page (https://login.cern.ch/adfs/ls/?wa=wsignin1.0) and is asked to type in the credentials. ADFS checks the information against a unique ac-count database - the user’s active directory entry. If the comparison returns true, the user gets an authentication token and will be redirected to the called service. The IIS module performs another control of the HTTP header and the valid token. If correct, the mailbox information will be displayed.
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).
TWiki Enterprise
TWiki (twiki.org) is a Wiki variant. It is a project-oriented Wiki implementa-tion targeted for corporate intranets by incorporating restricimplementa-tion 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 viewrestrict-ing.
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].
Figure 4.1: TWiki Main Web
Fig 4.1 shows a TWiki Main Web. Editing mode: By clicking on edit, a ”What-You-See-Is-What-You-Get” (WYSIWYG) editor opens the file in editing mode ( 1
). Menu-list: In this section, a list of webs and topics can be displayed ( 2
). It also screens the current Web. Content area ( 3
). Action bar: Several actions are available, including rollback to previous versions ( 4
).
4.1
Structure
TWiki topics (known as documents or pages) are contained in areas known as ”Webs” and a user can read these TWiki topics from a web browser, which retains user information for the current session[36]. The surface is the Main Web. This front page is the starting point from which all other Webs and Topics are accessible. The standard configuration comes with three webs:
Web Usage
Main Front-Page of TWiki
TWiki Configuration Web. Settings for entire TWiki
Sandbox 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 Registration: Users register accounts to gain TWikiNames. At CERN, a user has to have an account to create or edit topics / webs. If a user is not logged in, the user is able to read topics as TWikiGuest. Most TWiki pages in corporate environment are restricted for guests and are therefore not readable without registration.
• User Mapping: When login in to TWiki, a mapping from the users credentials (username) to the users WikiName appears. This step con-verts ”unfriendly” login names, from external authentication like SSO, to TWiki-friendly WikiNames.
- Alexander Bernegger -> Main.AlexanderBernegger
- [email protected] -> Main.AlexanderBernegger • Password Management: The password management defines how the
accounts are protected. In many cases, TWiki accounts are secured by using username and password pairs to login. TWiki supports the Apache ”htpasswd” password manager and uses .htpasswd files on the server. Alternatively other authentication methods can be used, for example CERN’s Single Sign-on infrastructure instead of Apaches’s htpasswd manager.
• Login Management: The login procedure describes how the user has to login. Different methods are available: No login, login via TWiki login page, login using web server authentication or by external authentication procedures.
4.3
Authorization
Many topics are not protected and in such cases the user does not have to login. However, TWiki provides access control to topics and webs in order to
restrict sensitive data from unauthorized viewing. A user who is allowed to read a certain topic but who is not yet logged in is automatically redirected to TWiki’s default registration page[38] where s/he is able to login or register for a new account.
4.3.1
Default Access Control
The idea of a Wiki is to provide information for everyone. For example, the ”Wikipedia” Wiki is a collaborative online encyclopedia where users, regis-tered or not, are free to participate by creating or editing pages and articles or read all stored topics[6].
As explained above, in a corporate environment not all information should be available to everyone. Certain projects only share data with members in-volved. TWiki has the advantage that it can manage restrictions on Topics or Webs by defining Allow/Deny commands with the respective users or user groups[39]. Access control is set using the user’s WikiName or a TWikiGroup. A TWikiGroup is a collection of WikiNames or other TWikiGroups[36]:
Set ALLOWWEBVIEW = TomJones, DickSmith Set ALLOWWEBCHANGE = TomJones
This restriction example shows how to configure a web to allow two TWiki users the right to view. The above settings are defined in the web’s preferences file and in this example both Tom and Dick have read access but only Tom has the right to edit topics. In case of many users, TWikiGroups facilitate this process. For example, if Tom and Dick belong to a project along with many other people, the following example shows how a TWikiGroup can be used to manage access control[36]:
Set ALLOWWEBVIEW = ProjectOneGroup Set ALLOWWEBCHANGE = TomJones
In this example, ProjectOneGroup refers to a TWiki topic that contains a list of project members including Tom and Dick. Similar settings can be added inside individual topics and for finer control one can also use DENY settings[36]:
Set DENYWEBVIEW = TWikiGuest
With this setting, all unregistered users are restricted from viewing the topics of this web. In this case, a guest gets redirected to the registration page so s/he can register or login.
4.3.2
Sessions
Once a user is successfully logged in, a walk around within the TWiki board-ers is possible. When changing a protected Web or Topic, the access con-trol mechanism checks the assigned privileges each time a switch takes place. TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions[38].
The user, once logged in, is not asked to login again unless the user opts out by clicking ”sign off” or the session cookie loses its validity by timeout.
Cookies are used to store user specific information on the client’s computer. This is a common way in TWiki to pass session information by holding a unique session identifier from a TWiki server database lookup.
4.4
TWiki at CERN
At CERN, a large number of scientists work together on different projects. One main project is the Large Hadron Collider (LHC), built by physicists and engineers to search for answers to open questions in physics. One of the big experiments of the LHC is the Compact Moun Solnoid (CMS) detector which records what happens when the LHC ring smashes together protons travelling at the speed of light. The aim is to find the mysterious Higgs-Boson particle, a hypothetical massive scalar elementary particle which is the missing puzzle piece of elementary physics - how do particles gain mass[40].
For organizations such as CERN, TWiki allows collaborations between users located in different buildings, cities or even countries, providing a convenient way of working together on projects and documents.
TWiki has been used at CERN since 2003 and has grown in popularity. The statistics from December 2009 show over 7000 registered editors and nearly 58000 topics (see Figure: 4.2). TWiki culture lends to open freeform editing and most pages are world readable and editable by CERN authenti-cated users However, access control is possible and is used to protect sensitive documents[36].
Figure 4.2: Growth of the total number of TWiki files[2]
4.4.1
Authentication
Login and access to the TWiki installation at CERN is done via the CERN Single Sign On authentication system, combined with the standard TWiki user registration and TWiki user mapping. With the current setup, access control to content in TWiki is provided via TWikiGroups which are edited manually by local TWiki web administrators.
All registered TWiki users are mapped via the file TWikiUsers, which con-tains the user names and email address mapping as seen from the CERN SSO when the user registers.
4.4.2
Authorization
By default, registered CERN TWiki users have write access to all open TWiki webs, such as the Sandbox. This open approach is very democratic, works well and is a key contributor to the success of TWiki at CERN. However, for some TWiki webs, it is desirable to restrict access to a list of authorized users. Authorization in CERN’s TWiki is traditionally done via the default access control of TWiki.
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) methodology1and 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].
Figure 5.1: Spiral Model
Figure 5.1 shows the spiral model ADFSUserMapping development is oriented to. It observes the following steps[42]:
The first stage in the life circle is to identify the requirements and objectives of the software. In this part, the planning of costs - time, personnel or money - takes place. The next step is to determine alternatives to implement a sys-tem which fulfills the planned requirements. After this is done, the next step is to choose one of the alternatives and to analyze its risks. If the risks are manageable, the next part is to start the development of a prototype with minimum effort. A validation must be performed if the prototype fulfills the requirements and if the objectives are as planned. For the further round, the feedback and experiences from test-users must be collected. After the first
round is done the first stage starts again. Here is important to determine new alternatives and to see if the goals with the prototype are feasible or not. If everything is as it shall, the improvement of the prototype can proceed. The circle is active till the software is finished.
Every methodology and its models have advantages and disadvantages. De-pending on the needs of a project and on the aim it should reach.
The advantage of spiral model development is that errors and bugs are found in early stages. Contrary to the waterfall model, important issues can be dis-covered earlier. The correction of bugs in finished products costs 100 times more than in an analysis and development phase[43]. Furthermore, the spiral model allows a flexible change management, what means that the software structure or the design is easy to adapt with the next round of circle. Another advantage is prototyping. In the early stages, a test device gets developed and is constantly improved thereafter. It allows constructive feedback from users who are testing the prototype[42]. On the other hand, the spiral model can be too ceomplex for small and quick projects and may inhibit their development. Moreover, this model is application-related and therefore needs different mod-els for each application. The risk evaluation must be performed by experts if it is to be considered, and this can often be more expensive than the development itself.
5.1
SDLC Stages
Planning:
The first stage to develop new software is to plan the requirements by defining the problem or the need for improvement of an existing system. However,
the new features of the system must be specified. This part is also called preliminary investigation stage. From this investigation, goals, requirements, milestones and costs get defined. The aim is to evaluate risk and project feasibility[41].
Analysis:
The analysis part in the SDLC is separated into two different views, the static and the dynamic. The static view is the analysis of the static model of a system using class hierarchy and composition diagrams. It captures the generic and essential features of a system. The dynamic view represents the system behavior during a session, using objects and operation diagrams[41].
Development and Implementation:
In this stage, all relevant programming such as code writing, data file building and the resolving of dependencies is performed. Furthermore, implementation of new software may include adaption of other already existing software to be executable.
Testing:
The testing part of the Software Development Life Circle is to find bugs and errors and to figure out how the new program interacts with the existing system[41].
For this procedure, a Testplan shall give a coordinated walkthrough to test all possible actions. After this, the program should work without any problems.
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.
6.2
ADFS User Mapping Development
ADFSUserMapping is a module, written in Perl Object - Oriented Program-ming Language, to enhance TWiki’s access control mechanism by introducing e-group alignment. It shall facilitate the administrative work of Web / Topic owners, in order to handle access for user groups.
6.2.1
Planning
As explained in the Spiral Software Development section, planning is necessary to handle the requirements and to create a projects life circle.
6.2.1.1 Problem Definition
For CERN, managing access control using the default method is straight for-ward. The drawback is that the access control lists or TWikiGroups have to be kept up to date, also for those experiments where the number of users con-cerned can run into the thousands[36]. Since the start-up of the LHC, more and more user groups are requesting finer control for read and write access. It would be more convenient and secure to use the knowledge of user groups from centrally managed e-groups. These groups could be directly applied to protect content in TWiki instead of having to pass via an intermediate step of making and maintaining local TWikiGroups within the scope of the TWiki system only.
6.2.1.2 Improvement
CERN has implemented a SSO solution based on Microsoft Active Directory Federation Services (ADFS). The SSO allows centralized authentication to dif-ferent computing resources and web applications at CERN, thus simplifying
user logins and improving application security with a single, secure login in-frastructure. Authorization and access to computing resources is provided via ADFS groups, which are managed via E-groups application that allows users and local administrators to define groups of persons for mailing lists and ac-cess to resources[36]. Furthermore, E-groups reflecting organizational groups at CERN are generated automatically from data in CERN’s HR database. To connect the E-groups with the TWiki installation, ADFSUserMapping shall be a module which takes the ADFS information and checks it against restriction control entry in a TWiki Topic.
Instead of the standard restricting method:
Set ALLOWTOPICVIEW = <comma-delimited list: Users, Groups> Would be enhanced as follows:
Set ALLOWTOPICVIEW = <comma-delimited list: Users, Groups, ADFS-Groups> To fulfill this requirement, analysis of TWiki’s Access Control modules and
6.2.1.3 Timeline
The development timeline of ADFSUserMapping module takes place in a gen-eral TWiki at CERN Roadmap, where milestones and project dates are in-cluded. In this roadmap, all work concerning TWiki is planned.
Figure 6.1: TWiki at CERN Roadmap snippet
6.2.2
Analysis
The analysis part in the life circle is the most important step. Before any development can be done, the system has to be well studied. Furthermore, entry points have to be figured out where new changes can be introduced without affecting or damaging the existing system. The next two sections cover the analysis of both systems; the ADFS / E-Groups and the TWiki.
6.2.2.1 E-Groups Analysis
When authenticated to the CERN SSO, a user creates a cookie and a session from the Shibboleth authentication provider. This session contains a number
of environment variables, among them the user name, his/her coordinates and group membership. Thus in the environment variables from the web server, all information about E-group membership of the user is available.
Figure 6.2: Environment Variables
Figure 6.2 shows a snippet of environment variable information which comes from ADFS server. The environment variable HTTP_ADFS_GROUP contains all the active directory groups and mailing lists of which the user is a member. This user specific information is stored in the human resource database (see Figure 3.1) and is called upon when a user logs on to a system within the circle of trust.
In TWiki’s Perl code, the variable HTTP_ADFS_GROUP is accessible by call-ing Apache’s ENV{variable_name}. ENV is a standard Perl module, which imports environment variables as scalars or arrays[44].
6.2.2.2 TWiki Analysis
In this analysis, the SDLC theory of analyzing the model in a static and a dynamic view will get used.
Static View
Any modification to the TWiki engine must coexist with the default access control methods. A grammatical parse of the description of the current system shows the following classes and operations for a static view.
Figure 6.3: Flowchart of User Interaction
Figure 6.3 shows the concept of the problem domain and the inter-relationships of the classes. This scheme gets used when a user logs on to TWiki.
In each class, different actions are done by the engine. Every action is related to a specific function. Before table 6.1 lists the classes and their functions, a list of actions and related functions is given:
• getWebDir : returns current web directory
• getReadProtectedInfo : shows protected read information
• getWikiName : get the Wikiname to display for a canonical user iden-tifier (cUID)
• getEmailAddress : reuturns the users E-mail address • getCERNaccount : gets information from ADFS server • getUserGroups : returns the users groupmemberships • allowAccess : set allow access to a cUID
Topic getWebDir, getReadProtectedinfo, getWriteProtected-info, getRenameProtectedinfo
Web getReadProtectedinfo, getWriteProtectedinfo, getRe-nameProtectedinfo
User getTWikiName, getEmailAddress, getUserGroups, getCERNaccount
TWikiGroup getTWikiName, getTWikiGroup TWikiSession getTWikiName, allowAccess
Table 6.1: Class actions
All these functions are defined in TWikiUserMapping Perl Module and are called upon when TWiki runs through its login routines.
Figure 6.4 shows how aggregation and generalization is done in this TWiki static view.
Figure 6.4: Entity Relationship Model
This ER model shows the inter-relationship of the classes in TWiki. The next part in the analysis section is the dynamic view. Use case scenarios show how
TWiki users interact with the system and models the dynamic view of the system and will be explained in the following.
Dynamic View (Use Cases)
Use case scenarios show potential weak points and provide an idea on how to react to different cases. Below, two use cases are shown: one showing a suc-cessful routine, one showing a problem domain. All use cases to this analysis can be found in Appendix C.
UseCase 4: A user wants to read a protected topic and is asked to login using the SSO account. The page has some access control and this user is allowed to view the topic. The topic is displayed. TWiki retains the user’s TWikiName.
Figure 6.5: TWiki Use Case 4
1. User clicks on a link to a protected topic.
2. TWikiSession checks the web for access control.
3. TWikiSession requests user authentica-tion.
4. TWikiSession checks the TWikiName against access control settings in the web.
5. TWikiSession checks the topic for ac-cess control.
6. TWikiSession checks the TWikiName against access control settings in the topic.
7. Topic is displayed to the user. Use Case 4 shows a standard procedure of a login with TWiki access restric-tions.
UseCase 8: A user wants to read a protected topic and is asked to login using his/her SSO account. Although s/he uses the correct account, the email address has changed and there is a mismatch between SSO and TWiki regis-tration. The user is asked to register and is confused, since s/he believes that s/he is already registered.
Figure 6.6: TWiki Use Case 8
1. User clicks on a link to a protected topic.
2. TWikiSession checks the web for access control.
3. TWikiSession requests user authentica-tion.
4. User registered, but email address has changed
5. Mismatch between SSO and TWiki registration
6. TwikiRegistration is displayed to the user
7. User confused
Use Case 8 handles a problem domain. The unique identifier in CERN’s TWiki installation is the user’s e-mail address. The user is able to change this iden-tifier in TWiki and in SSO. Although those systems are not synchronized and if the user changes the address only in SSO, he/she will not be able to access TWiki anymore.
This problem can be solved by incorporating the SSO identifier (See Figure 3.6, CERN’s Service Provider) into TWiki. Thus, a hybrid solution has to be found since lightweight users, who have no SSO account at CERN, are then no longer able to login. A possible solution to this issue is provided in 7.1.
Concerned TWiki Modules
From the static view (see figure 6.3), the modules for authorization can be iden-tified. The ”hasAccess” and ”isMember” are done by TWiki’s Access.pm Perl module and TWikiUserMapping.pm Perl module. (see Appendix B for code ex-tract).
The mapping from a username to a TWikiName is done by following mod-ules: TWiki::Users::BaseUserMapping TWiki::Users::TWikiUserMapping TWiki::UserMapping TWiki::Users TWiki::Access
TWiki::Users::TWikiUserMapping is the base class for user mapping. This class has to be integrated in the new mapping module to inherit all its vari-ables for further usage.
In Access.pm, a subroutine called TWiki::Access::checkAccessPermission is reliable for proving a users permission to a Topic or Web. This subroutine reads the topic settings (ALLOW / DENY) and checks the user’s TWikiName to see whether or not it is in a list.
By call-up, checkAccessPermission sends the TWikiName to another sub-routine, called isInList, which is located in TWiki::Users. It is the real comparator. The subroutine returns true (1) when the user’s TWikiName is in an ALLOW / DENY list, or false (0) when not. checkAccessPermission receives this value and decides what to do:
• For the cases allow and true, the user will be granted and the Topic / Web displayed. (see Figure 6.5).
• For the cases allow and false, the user will get redirected to an ”Oops -Access Denied” webpage.
• For the cases deny and true, the user will get redirected to an ”Oops -Access Denied” webpage.
• For the cases deny and false, the user will be granted access and the Topic / Web displayed.
According to the static view, an enhancement of access control while checking the settings against TWikiNames must take place. Therefore, the isInList subroutine from TWikiUserMapping is the important piece of code for e-group alignment and needs to be altered for further treatment.
TWiki Access Control Flowchart
To analyze the TWiki access control flows, a flowchart helps to visualize con-cerned modules of these processes.
Figure 6.7 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”
