Distributed Architectures for
Laboratory-Based E-Learning

 

 

 

 

 

Inauguraldissertation

der Philosophisch-naturwissenschaftlichen Fakultät

der Universität Bern

 

 

 

vorgelegt von

 

Marc-Alain Steinemann

 

von Bern und Opfertshofen

 

 

 

Leiter der Arbeit:

 

Prof. Dr. T. Braun

 

Institut für Informatik und angewandte Mathematik


 

 

 

 


Distributed Architectures for
Laboratory-Based E-Learning

 

 

 

Inauguraldissertation

der Philosophisch-naturwissenschaftlichen Fakultät

der Universität Bern

 

 

vorgelegt von

 

Marc-Alain Steinemann

 

von Bern und Opfertshofen

 

 

 

Leiter der Arbeit:

 

Prof. Dr. T. Braun

 

Institut für Informatik und angewandte Mathematik

 

 

Von der Philosophisch naturwissenschaftlichen Fakultät angenommen

 

 

 Der Dekan:

Bern, 16. Juni 2005                                                                Prof. Dr. P. Messerli


 

 

 

 


 

 

 

 

 

 

 

 

 

To my true friends

 

 

 

 

 


 

 


 

 

Preface

 

The dissertation presented here is the result of five years of research, beginning in April 2000 at the Computer Networks and Distributed Systems group of the Institute of Computer Science and Applied Mathematics at University of Bern. I would like to take the opportunity to extend my sincere thanks to all those who supported my work and made this thesis to what it is.

My sincerest thanks go to my wise advisor Professor Dr. Torsten Braun, head of the Computer Networks and Distributed Systems group, for the valuable ideas and helpful advices as well as for hosting me in his group. He had a great impact on my scientific development and the research work presented in this thesis. Professor Braun supported my scientific education by encouraging me to publish in journals and conferences.

Special thanks go to Professor Dr. Ulrich Ultes-Nitsche for the fruitful and interesting discussions, especially during the Summer School on Pochtenalp and the good teamwork in common projects. I am truly thankful to him for accepting the “Ko-referat” of my thesis.

I would also like to thank Professor Dr. Hanspeter Bieri for chairing my dissertation defense.

My best thanks go to Attila Weyland for the excellent teamwork in our common projects and to Dr. Florian Baumgartner for the critical advices concerning authentication and authorization issues. I would also like to mention my sincerest appreciation for the late night, alcoholically animated, discussions with Florian and Matthias Scheidegger. Many thanks also for the interesting discussions about projects and scientific articles with Marc Heissenbüttel, my office partner. I will not forget the extended Schilthorn mountain hike with Marc and Marcin Michalak. Many thanks go to Ruy de Oliveira for discussions about work and Brazil. I am also grateful for the good cooperation with Thomas Bernoulli, Thomas Staub, Marc Brogle and Dragan Milic in common projects. Thanks as well go to Dr. Ibrahim Khalil, Dr. Manuel Guenter, Marc Danzeisen, and Markus Wälchli.

Special thanks to Ruth Bestgen, the secretary. She is a big help in organizing and minimizing our administrational workload. I would also like to give her a special thank you for the invitations to the annual Fondue events.

Many thanks go to Prof. Dr. Jacques Viens, Dr. Martin Guggisberg, Dr. Tibor Gyalog, Dr. Cornelia Rizek-Pfister, Christoph Graf, Thomas Lenggenhager, Dr. Martin Sutter, Ueli Kienholz, Valery Tschopp, and Karl Guggisberg. Thanks also to Christian Heim, Roland Trummer, Christoph Glanzmann, and Peter Geiser.

Furthermore many thanks to the five diploma students who indirectly contributed a lot to my work: Thomas Jampen, Stefan Zimmerli, Christine Rosenberger, Thomas Spreng, and Gero Butera. They were great discussion partners and helped in concretizing theoretical ideas in practice.

Finally, I would like thank my family and friends for their patience and support throughout the many years of my education.

 


 


 

Table of Contents

 

1      Introduction................................................................................................... 1

1.1        Overview..................................................................................................................................... 1

1.2        E-Learning Architectures....................................................................................................... 3

1.3        Didactics in E-Learning......................................................................................................... 7

1.4        Contributions.......................................................................................................................... 10

1.5        Outline...................................................................................................................................... 12

2      Related Work:  Discussion and Evaluation............................................ 13

2.1        Introduction............................................................................................................................. 14

2.2        Authentication Issues........................................................................................................... 19

2.2.1     Public Key Infrastructures............................................................................................. 19

2.2.2     Authentication with Kerberos...................................................................................... 28

2.3        Secure Data Transport.......................................................................................................... 33

2.3.1     Internet Protocol Security............................................................................................... 33

2.3.2     Secure Sockets Layer and Transport Layer  Security............................................. 36

2.3.3     Secure Shell........................................................................................................................ 38

2.3.4     Evaluation of the Different Transport Technologies.............................................. 38

2.4        Authentication and Authorization  Infrastructures.................................................... 41

2.4.1     Lightweight Directory Access Protocol...................................................................... 41

2.4.2     Shibboleth........................................................................................................................... 48

2.4.3     Point of Access to Providers of Information............................................................. 53

2.4.4     Remote Authentication Dial-In User Service............................................................ 55

2.4.5     Diameter.............................................................................................................................. 56

2.4.6     Liberty Alliance................................................................................................................. 57

2.4.7     Microsoft Passport........................................................................................................... 60

2.4.8     Evaluation and Comparison of Authentication and Authorization Infrastructures        61

2.5        Summary.................................................................................................................................. 65

2.6        Computer Networks Laboratories.................................................................................... 67

2.6.1     Traditional Laboratory Architecture.......................................................................... 67

2.6.2     E-Learning Laboratories................................................................................................. 68

3      Resource Management Portal................................................................... 73

3.1        Components and Interactions............................................................................................ 73

3.2        Architectural Specifications............................................................................................... 79

3.2.1     Overview............................................................................................................................. 79

3.2.2     Plug-In Concept................................................................................................................ 80

3.2.3     Overall Functionality...................................................................................................... 81

3.2.4     User Roles........................................................................................................................... 96

3.2.5     User Interactions with the Resource Management Portal.................................... 99

3.3        Implementation.................................................................................................................... 102

3.3.1     Introduction..................................................................................................................... 102

3.3.2     AAI Adaptor.................................................................................................................... 103

3.3.3     Resource Adaptors........................................................................................................ 104

3.3.4     Web Application with a Database Backend.......................................................... 106

3.3.5     Database Design............................................................................................................. 107

3.4        Performance Measurements............................................................................................. 109

3.4.1     Measurement Scenarios and Methods..................................................................... 109

3.4.2     Access of a Resource Information Page on  the Resource Management Portal.................. 111

3.4.3     Access of an External Resource Management  Portal Hosted Resource........ 121

3.4.4     Measurement Summary............................................................................................... 130

3.5        Discussion and Conclusions........................................................................................... 132

3.6        Outlook................................................................................................................................... 134

4      Multifunctional E-Learning Architecture............................................. 137

4.1        Introduction.......................................................................................................................... 137

4.2        Architectural Requirements............................................................................................. 138

4.3        Architectural Specifications............................................................................................. 140

4.3.1     Overview........................................................................................................................... 140

4.3.2     Overall Architecture...................................................................................................... 142

4.3.3     User Roles......................................................................................................................... 144

4.3.4     Components..................................................................................................................... 146

4.3.5     Security Issues................................................................................................................. 156

4.4        Implementation.................................................................................................................... 157

4.4.1     Course Platform.............................................................................................................. 157

4.4.2     Resource Management System................................................................................... 158

4.4.3     Laboratory Module Implementation........................................................................ 162

4.5        Discussion and Conclusions........................................................................................... 169

4.6        Outlook................................................................................................................................... 171

5      Extended Multifunctional E-Learning Architecture........................... 173

5.1        Introduction.......................................................................................................................... 173

5.2        Transformation Approach................................................................................................ 174

5.3        Architectural Specifications............................................................................................. 177

5.3.1     Overall Architecture...................................................................................................... 177

5.3.2     User Roles......................................................................................................................... 179

5.3.3     Components..................................................................................................................... 181

5.4        Discussion and Conclusions........................................................................................... 185

5.5        Outlook................................................................................................................................... 186

6      Didactics of Computer Networks Laboratories................................... 187

6.1        Introduction.......................................................................................................................... 187

6.2        Traditional Laboratories................................................................................................... 188

6.3        Didactical Structure of an   E-Learning Laboratory.................................................. 190

6.4        Usability Feedback.............................................................................................................. 196

6.5        Discussion and Conclusions........................................................................................... 198

6.6        Outlook................................................................................................................................... 200

7      Synopsis..................................................................................................... 203

7.1        Conclusions.......................................................................................................................... 203

7.2        Outlook................................................................................................................................... 206

List of Figures................................................................................................... 209

List of Tables..................................................................................................... 215

List of Abbreviations........................................................................................ 217

Bibliography...................................................................................................... 221

Appendices........................................................................................................ 229

Appendix A: Virtual Internet and Telecommunications Laboratory of Switzerland..... 229

Appendix B:  Modules of the Traditional Laboratory.............................................................. 231

Appendix C:  Modules of the E-Learning Laboratory.............................................................. 233

Curriculum Vitae.............................................................................................. 235

 

 

 



 

 

 


 

1       Introduction

1.1       Overview

In the presented thesis, we perform research in the areas of resource access management in the Internet, distributed architectures for laboratory-based e learning and didactics for e-learning laboratories. We propose a novel architecture for resource access management; two novel distributed e-learning architectures and a didactical framework.

The Internet has opened new possibilities in many areas of our daily life. Among others, educational institutions are involved in these changes. Educational institutions own learning resources, which they have made available in a traditional way but now, also have to be made available on the Internet. When we use the term traditional learning throughout this document, we refer to course resources as for example lectures or hands-on trainings held in universities. Hence, the Internet has opened new ways for providing these resources to the student community. The word resource in this context is a generic term, which stands for any kind of courses, lectures, seminars, or trainings.

During this process, a new term has been established: electronic-learning or in brief, e-learning. E-learning is the generic term for imparting any kind of learning resources by the Internet and a new form of distance learning. We use the term e-learning resources throughout this document for all resources users can access with web browsers.

There are two entities interacting in e-learning scenarios: The first entity consists of resource providers and tutors in elementary, secondary and high schools, colleges, and universities as well as in commercial educational institutes. The second entity consists of the students, which belong to the mentioned educational institutes. Some students use the resources as a part of their compulsory curriculum; others desire further education in the process of life long learning, some to achieve a higher grade or to improve their knowledge. Other students are handicapped persons who cannot easily travel around and persons from developing countries with a poor educational infrastructure.

For e-learning users the underlying infrastructure, such as course platforms, reservation systems, authentication systems, databases and more, grouped together in e-learning architectures, should remain almost invisible. Users only get into contact with web interfaces for using these systems. Well-designed e-learning resources offer user-friendly access management to all elements of the architecture. These e-learning resources should provide the necessary access credentials in a user-friendly way. For resource operators, well working interactions between the elements of an e-learning architecture are of fundamental nature. The diversity of the theoretically available protocols and applications in the Internet, usable for an e-learning architecture, raises questions related to the desired interoperability and user-friendliness, which scientists must further investigate.

The production and maintenance of e-learning resources is expensive and it is thus necessary to restrict access to a limited set of subscribed students. In addition to restricting access to the resources, there is also a demand for adding supplementary features. Many traditional resource providers who start activities in e-learning first try to make their existing study materials available on the Internet in a one to one transformation process, instead of applying a didactical framework designed for e-learning resources. They put the content of existing books or scripts on web pages without minimal enhancements or adaptations. This procedure does not use the didactical possibilities of e-learning and the potential for improving the teaching quality. However, it is possible to achieve good results with the application of a didactical framework, which specifies the course structure and the didactical methods.

Chapter 1.2 introduces into the basics of e-learning architectures and resource access management, necessary for the understanding of the investigated problems and approaches. Chapter 1.3 introduces into the basics of didactics in e-learning courses, considered necessary for the later discussion and understanding of the investigated problems and approaches. Chapter 1.4 presents the encountered problems together with our contributions performed in this thesis. Chapter 1.5 gives a brief outline of the thesis.


 

1.2       E-Learning Architectures

When considering a traditional learning resource, for example a textbook, we discover that there are many elements necessary before a student starts learning with the book. An author has to write the text, a printer to make the book, a bookshop to sell the book and a tutor to recommend the book for a lecture. Similar actors, such as the author and an illustrator but also much more technical elements are necessary for the production of an e-learning resource, which consists of a minimal technical infrastructure. We can split up this infrastructure into three parts:

 

Systems for resource providing

Resource providers host their resources on web servers, connected to the Internet. Depending on the resource, the web servers feature different types of services, such as for providing dynamic Hypertext Markup Language (HTML) pages [Bv45 and BC95]. The World Wide Web Consortium (W3C) HTML specification defines the representation format for pages with textual information and Meta information for retrieval and interchange in the Internet. Static HTML pages look identical for all users and dynamic HTML pages depend on the user’s request. The learning content of each resource must be adapted to the Internet and the available applications such as course platforms, web servers, and video servers. Learning content comprises study material and everything else used for teaching, such as interactive animations or audio broadcasts. Tutors and resource producers must have access to utilities that allow the production and operation of the learning content. Resource providers are also responsible for all other technical systems considered necessary for the operation of the resource, such as resource management systems. Resource management systems comprise the user access, resource management and a device reservation system if required. The resource content, software and hardware, has to be maintained, updated, and protected from fraud and data loss. Resource providers have to make sure that they buy enough data transport capacity from their Internet providers.

Systems for data transport

In e-learning, the Internet is typically the part of the infrastructure, which transports the resource data between resources and students and between the elements of a resource. In the strict sense, each computer or device connected to the Internet makes part of it, also the equipment for resource providing and studying. In this context, we refer to the wires, routers [Pr00] and devices between the resource servers and the students, which transport the data. Routers are devices in packet switched networks [Gp80] such as the Internet, which forward data packets to the next hop towards its destination. Internet Service Providers (ISP) supply this part of the infrastructure. Internet service providers are organizations, which sell data transport capacity and Internet services to their customers.

Systems for students and tutors

Students and tutors who use e-learning resources for their study purposes and teaching must have access to a computer with Internet connectivity. Depending on the services offered by the resource provider, the computer must be equipped with applications that allow benefiting from these services. Students have to make sure that their Internet access has enough data transport capacity to be able to use the offered services.

 

Architectures for Internet-based resources describe the design and the functionalities of the future implementations. Consequently, an e-learning architecture is an architecture, which describes the design and the functionalities of all the necessary elements for the operation of an e-learning resource. In other words, e-learning architectures define the data exchange between users, comprising students, tutors and administrators and the elements responsible for the operation of the course system, comprising content servers and course management system.

Figure 1‑1 shows frequently used elements of e-learning architectures whereas Table 1‑1 discusses them. Required elements are clients, which connect via the Internet to the resource elements. Clients contact servers in the technical meaning and utilize services in the technical and commercial meaning. Such clients can be users such as students, tutors, and administrators. The resource management system is another required element in the case of resources with controlled user access. It manages the user accounts for students, tutors and the resource access issues as well as the resource content servers, which provide web pages, audio streams, video streams, and communication services to the students.

One resource content server is at least required in any e-learning architecture and further resource content servers are optional. More than one resource content server is useful for load balancing, for example by geographically distributing the servers around the globe or for forming an e-learning grid, enabling a variety of resource providers to operate their respective servers at their home locations. A single resource provider, which joins such an e-learning grid contributes the own learning content to the community and gets access to the content of the grid partners. This restricts the maintenance and update processes to the own resources. An optional element in an e-learning architecture is a resource reservation system. A resource reservation system is only necessary if certain resources do not exist in sufficient quantities for all the resource students who would like to access the respective resource at the same time.


 

Element

Function

Presence

Resource
management system

User accounts are stored on resource management systems. Resource management systems control user access to connected content servers and reservation systems. The resource management system performs accounting for the user interactions with the single elements of the architecture.

Some resources use applications with a limited user access capacity. In such cases, the resource management system must contain a reservation system. Students have to pre-register (book) their sessions with the reservation system.

Required,
reservation
system
optional

Students, tutors, administrators

Tutors and students access the resource management system and other elements that make part of the resource.

Required

Resource
content
servers

Learning content is stored on resource content servers. At least one resource content server is required in an e-learning architecture. The server can be a part of the resource management system, and then it is a course platform. Distributed resource content servers can provide their content via a resource management system and form one distributed resource.

One
required, more
optional

Table 11: E-learning architecture elements.

 

Figure 11: E-learning architecture elements.

An administrator or tutor registers the students with the resource management system. The resource management system registers those students automatically with the optional resource reservation system and with the resource content servers. Each element of the architecture interacts with the other corresponding elements. Clients, in the meaning of the client/server principle [Cb96 and SRC84] connect to the resource management system, to the resource content servers and to the reservation system. The resource management system interacts with the resource content servers and with the reservation system. Resource content servers, which provide limited software or hardware resources, interact with the reservation system. Students can access resources, which provide limited hardware and software resources only upon anterior reservation.

After the introduction of the general aspects of e-learning architectures, we introduce centralized and distributed content providing architectures, respectively. Many Internet services, used to provide information to users, are physically located on servers in one central location. This is a historical consequence: at the beginning of the computer era, there was one server room per organization and it was not possible to operate servers at other locations. These are centralized architectures. Architectures, integrating servers distributed over multiple locations are distributed architectures. Such distributed architectures, for example in the case of an e-learning architecture, make use of distributed content providing servers, of the resource management system to integrate resource content from the different servers and provide it under one identity to the students. However, the resource management system has to manage the student access for all resource content partners. The resource management system can integrate distributed student registration and access procedures for the connected resource partners, for example performed with their respective administrations. In the distributed architecture, the resource management system and one resource content server are in location X with a second content server in place Y, a third in place Z, whereas in the centralized architecture all servers are in place X. The students, tutors, and administrators can be everywhere where they have Internet connectivity.


 

1.3       Didactics in E-Learning

Didactics is the science of guided education comprising several areas, ranging from general principles and frameworks of educating to special methods for different learning tasks [Gh96]. The didactical framework decides on how successful students finish the course. Most tutors are well educated for teaching in traditional classrooms but not for teaching with e-learning resources. The new teaching environment internationalizes the audience, which bears reasons for conflicts in cultural and social belongings.

There are many details in the design of a resource that can lead to a complete misunderstanding by the students [Ss99], for example, colors can have differing meanings from culture to culture. The design of a resource must also respect the fact that different individuals use different ways for studying [PKR00 and PKRO98]. Additionally, one should consider learning differences caused by religious, ethnic, cultural and gender diversity of students, which influence the process of collaborative activity within groups [CGLO02]. Thus, authors have to design their resources for their future audience.

An advantage in e-learning is the possibility to include instantly available optional and supplementary study material or to add pointers to such material. By these means, students who do not fit the minimal knowledge requirements for the respective resource can work through the resource all the same.

Learning without face-to-face contact is not new to humanity. Only the trend has changed towards non-face-to-face learning due to new learning technologies such as found in e-learning. Learning without face-to-face contact started with distance learning where study material consists of books, audio and video tapes, as well as radio and television broadcasts. At the beginning of the personal computer’s era in the 80s, study material was distributed on floppy disks. Floppy disks and compact disks are only helpful for persons who have access to a computer. Compact disks are powerful media for the transport of study material, unlike floppy disks with their limited storage capacity. Both types of disks permit resource designers to integrate a previously scripted interactivity into the resource content. Scripted interactivity means that the designer foresees several possible ways through a course, for example presenting different texts after a yes/no question. Such static study material looks always identical, whereas dynamic material is prepared and presented upon students previous interactions. One negative aspect of the above-mentioned methods is lack of direct interactivity between students and tutors. Students read, listen or watch the study material but cannot influence the course of the activity. In some resources, students can send back exercise solutions or essays by mail or sometimes get support by telephone.

The possibility for significantly improving interactivity started when personal computers became widespread. Students could access additional information provided on compact disks, where it was possible to include video and audio sequences, image galleries, and abundant secondary literature. However, only e-learning was a real revolution to distance learning. With the establishment of the Internet, students could connect directly to resources; work on real interactive and dynamic resource content as well as getting into contact with other e-learning students.

E-learning resource designers must implement didactical workarounds to get closer to the social environment of a traditional classroom. A traditional classroom is the typical classroom found in schools. It is a place where much more happens than just learning. Social contacts between students as well as between students and teachers are established. Many activities take place in breaks or other meetings initiated in the classroom. In a classroom, individuals do not only study, moreover they learn how to act in a social group. A virtual classroom is the name for a classroom found in e-learning resources. Not all existing e-learning resources are at the same time virtual classrooms. Virtual class rooms are e-learning resources enriched with features, which try to offer the same communication and learning methods found in traditional class rooms but adapted to e-learning. Additionally, resource designers try to include new technical and didactical methods offered by the Internet only. In virtual classrooms, social interactions found in regular classrooms merely take place because most interactions happen between students and resource servers. Usually, students visiting e-learning resources sit alone in front of a computer screen.

E-learning resources are still not as comfortable for studying as traditional courses. In e-learning resources, it is generally not possible to use text markers or to take notes and write them directly into the text. New methods have to substitute these traditional ones. In traditional learning, it is possible to do the homework almost everywhere, even taking a script and read through while sitting in a hot bath. The course material can be stored, together with all the personal notes and the exams. The day it is needed again, maybe ten years later; it is instantly and fully available. Traditional studying has many advantages and one of the most important is that we are used to it. Nevertheless, there exist not only disadvantages in e-learning. Studying online is getting increasingly popular because it offers advantages to traditional learning. E-learning tutors for example, can address a larger audience at the same time without loss of teaching quality. Particularly universities face the problem of overcrowded lecture rooms and a resulting loss of teaching quality as interactions between tutors and students get rather impossible. Significantly, in such cases, e-learning resources offer advantages for students and tutors:

 

  • It is possible to study independently from time and place with the only precondition that Internet access is available.
  • E-learning resources are normally open around the clock, 365 days a year.
  • E-learning resources are able to offer interactive study material where students can apply and increase their skills.
  • Students get pointers to supplementary lecture and are able to access it at once.
  • It is easy to integrate useful didactical methods, such as glossaries and discussion boards.

 

When studying in an online resource for the first time, students normally face a completely unusual way of studying [RPHG01]. Many times, students must learn how to use the Internet and the basic services such as the World Wide Web (WWW) or electronic mail. Students have to learn how to access a resource and how to navigate through the study material. They have to understand how to use the Internet for additional study material search and collection. Email and its features, Internet relay chat, instant messaging, discussion boards, white boards, all these methods have to be understood for studying in e-learning resources. They have to acquire social behavior in virtual communities such as in discussion boards or in chat rooms. Students who already own experiences using the Internet have advantages compared to others. Nevertheless, e-learning resource providers cannot expect that the students already know how to use the course material and should always explain the study methods in use. Resource providers should also link to related study topics, especially to the basics of the study topic and to resources, which provide supplementary information. A problem for educators is that younger students are used to quickly changing and superficial presentations such as found in video games or broadcasts in television channels [Mm98]. Even if these students are able to read a text up to the last line, they have problems with memorizing and understanding the message. Unfortunately, e-learning allows these abstract-minded students to do the same and to distract themselves much more by quickly clicking through the study material or surfing to other sites. E-learning resources should integrate learning control mechanisms, for example in form of understanding questions and essay tasks, distributed through the study material.

Tutors and resource designers have to understand the differences between traditional and e-learning. They have to replace their traditional methods by the respective counterparts for e-learning and integrate new ones, which are only available in e-learning. In particular, they have to consider the shift from face-to-face contact to machine directed contacts. In most cases, resource designers are not identical with tutors. The reason for this separation lies in the complexity of designing and implementing multifaceted e-learning resources. This work division can be potentially difficult as resource designers must perfectly understand the study matter and perfectly understand didactics. Consequently, a designer can only be a person, who is didactically educated and has a deep knowledge of the study topic. Alternatively, a didactical framework can enable topic professionals to implement e-learning resources in a qualitatively high standard.

Concluding the didactical introduction, one should always remember that human beings are creatures of rituals, ritualized behavior, and habits [SK90]. When we keep in mind these facts, it is not surprising to see that many students and tutors do not like their first contact with the new learning methods in the virtual classrooms.


 

1.4       Contributions

The introduced basics of e-learning architectures represent the environment in which we investigated the problems regarding interconnecting of geographically distributed resource providers with a geographically distributed architecture for hands-on trainings oriented computer networks laboratories. The prerequisite of the geographically distributed laboratories excludes the use of existing architectures for centralized resource provisioning. The integration of laboratories with limited hands-on training equipment requires the integration of a reservation system into the course management system. Users have to access the elements of such a distributed architecture and the expensive e-learning resources protected with a resource management system. Such a user access system should address the possibility of providing facultative user access and resource management to web-based resources. This system should also ease the integration of the resources in higher-level user access management systems. We investigated the authentication and authorization as well as interconnection related questions posed by these problems and developed three different novel architectures, a novel architecture for resource access management and two novel distributed e-learning architectures; as such architectures did not exist at the beginning of this thesis. The prototypical implementation of the e-learning computer networks laboratory raised teaching related questions, which we addressed with a novel didactical framework for hands-on training oriented e-learning resources.

This thesis is going to address the following problem areas:

  • How is it possible to enhance web-based e-learning resources with user and resource management functionalities as well as on demand communication and accounting features?
  • How is it possible to connect resources to higher-level user management systems in an easy procedure?
  • How is it possible to interconnect geographically distributed e-learning resources, such as computer networks laboratories with limited hands-on training equipment, for forming a common e-learning resource?
  • How can didactically unskilled e-learning computer networks laboratories designers implement a didactically structured state-of-the-art course and achieve a better teaching quality than in traditional laboratories?

 

In this thesis, we present an architecture, which solves the issues raised when connecting web-based resources to higher-level user management systems, such as authentication and authorization infrastructures. The architecture allows connecting of all types of resources with no system changes to higher-level user management systems. The architecture proposes a resource management portal and we call it resource management portal architecture. This architecture also introduces a concept, by which it is possible to protect and enhance resources with user and resource management functionalities, which base on a resource adapter concept. A special emphasis of the investigation lies on the adaptor concept, by which this broker can receive user information from higher-level user management systems and release information to resources. The user management concept also shows how to collect supplementary user information and how to manage automatically the resource access based on the collected user information. We further present a concept for user and resource accounting as well as a plug-in concept for adding communication tools to the resource management portal. We used a prototypical implementation of the architecture to prove the approaches and for scalability tests.

We present a distributed architecture for interconnecting all elements, necessary in an e-learning resource with geographically distributed laboratories, which we call multifunctional e-learning architecture. We also discuss the combination of this distributed architecture with the resource management portal architecture and the resulting shift of authentication tasks to higher-level user management systems. We call this combined architecture extended multifunctional e-learning architecture. We propose a concept for forming a grid with distributed e-learning laboratories, allowing the exchange of user authentication and authorization information. One element of this grid represents a resource management system with an integrated laboratory reservation system. A second element of this grid represents a laboratory portal server, comprising security functionalities for protecting the laboratory from Internet threads and a concept for safe forwarding laboratory users to the chosen laboratory devices as well as methods for resetting laboratory devices. In the case of the extended architecture, the third element of this grid is the resource management portal, which integrates the grid with the higher-level user management system. We discuss how to use the resource management portal for user registration in the resource management system and the course platform by means of the adaptor concept. We implemented a prototypical hands-on training e-learning laboratory with a lab bed consisting of two commercial routers and three Linux hosts to prove the laboratory portal server’s concept. We used the prototypical implementation of the architecture with an attached course platform and several geographically distributed laboratories to prove its functionality and tested it with students.

In this thesis we also presents a didactical framework, comprising of well-known didactical teaching methods but grouped together in a novel way for educating students in hands-on trainings oriented e-learning resources. This framework contains a proposed course structure for e-learning laboratories with a focus on hands-on trainings. We investigated the learning styles of students in a traditional computer networks laboratory by observing the students at work and with the analysis of feedback forms. Based upon that information we present a didactical framework for the electronic version of the laboratory. We could investigate the effects of the framework in a field test with real students in the prototypical implementation of the course. The analyzed user feedback reports an improved association of the newly acquired with existing knowledge and a higher sustainability of the learning material.


 

1.5       Outline

This document comprises five main Chapters. Chapter 2 presents and evaluates related technologies for their use in our own architectural solutions. We focus on authentication infrastructures, authentication and authorization infrastructures and on related technologies for a secured data transport.

Chapter 3 discusses the investigated issues and the subsequent design of the resource management portal architecture and its prototypical implementation, which can be operated autonomously and additionally act as a broker between higher-level user management systems and resources. We also investigate scalability with performance stress measurements performed with the portal’s prototypical implementation. We further show how to connect resources and user management systems to the resource management portal in a time and cost effective way as well as the advantages the resource management portal provides for the participating organizations, resource providers, and users.

Chapter 4 discusses investigated and addressed issues of the first distributed e-learning architecture we have designed and the prototypical implementation of the architecture. We called the architecture multifunctional e-learning architecture. It enables students to access geographically distributed hands-on trainings-oriented e-learning resources. This architecture resembles a computational grid as various distributed resources are aggregated together, forming the e-learning resource. We tested the concept of the architecture with the prototypical implementation of a first hands-on training laboratory by means of the learning module IP Security.

Chapter 5 discusses the motivation and the addressed issues, which led to the combination of the multifunctional e-learning architecture with the resource management portal architecture, called extended multifunctional e-learning architecture. This distributed architecture was prototypically implemented and evaluated.

Chapter 6 discusses the didactical aspects of e-learning and the developed framework for improving the quality of e-learning. The Chapter starts with an analysis of the exemplar traditional computer networks laboratory of our institution and presents the prototypical implementation and evaluations of the framework with the e-learning version of the computer networks laboratory.

In Chapter 7 we conclude the work in a global way.

 


 

2       Related Work:
Discussion and Evaluation

This Chapter discusses and evaluates the related work and technologies with their potential alternatives, applied in the resource management portal architecture and both, the multifunctional e-learning architecture and its extended version. We discuss the applied technologies in the presented architectures in more detail and extent than related but not selected ones. An evaluation follows each technology discussion and each discussed group of technologies ends with a comparison of the evaluations and recommendations about the use in our architectures.

Chapter 2.1 not only introduces basic terms in resource access but also shows the motivation for the application of such technologies in e-learning resources.

Chapter 2.2 discusses authentication infrastructures. These infrastructures serve to protect resources from undesired user access. Each type of technology provides different advantages for the resource users and the resource owners.

Chapter 2.3 is devoted to the discussion of secure data transport in the Internet, which is necessary for the exchange of confidential user data at the e-learning resource access and during a resource visit.

Chapter 2.4 discusses different authentication and authorization infrastructures. We discuss and evaluate these technologies, especially related to their implementation problematic, their user data protection and their current development and deployment state.

Chapter 2.5 is an evaluation summary of the related technologies and recommends the technologies to be used in our architectures.

Chapter 2.6 discusses computer networks laboratories.

2.1       Introduction

The first section of the introduction discusses basic terms used when talking about resource access control systems. We subsequently discuss the relation between resource access and protection of resources, especially in the case of e-learning resources. A conclusion of this discussion is that those methods already used at the beginning of the Internet do not always scale with large resource user communities or security demands encountered nowadays. In the subsequent section, we introduce the asymmetric encryption principle, encountered in many security technologies of today’s Internet. The introduction ends with a comparison and evaluation of these asymmetric technologies related to our own architectures.

We start the discussion about resource access issues with the introduction of terms related to the access of resources on the Internet:

 

Authentication

Authentication is the process of determining whether someone is really the person he or she claims to be.

Authorization

Authorization is the process of giving someone permission to do something.

Accounting

Accounting is the process, which measures the resources a user consumes during his or her session. Accounting performs authorization control, billing, trend analysis, and capacity planning activities.

Single sign-on (SSO)

Single sign-on [Cj02] is the term used for mechanisms permitting a user to authenticate with his or her user credentials only once in order to access multiple resources.

User Credentials

User credentials consist of information used by a user to authenticate with a resource.

 

All the time when a resource should provide their content to authorized persons only and when confidential data transfers the Internet, it is necessary to intercept access control systems, as well as to encrypt the transferred data. E-learning resources, whose providers do not intend to provide the content free of charge, have to protect access with an access control system. In this way, unauthorized persons cannot access these resources. Because of this circumstance, most e-learning architectures comprise systems, which protect the resources from undesired user access. The main reasons for this restricted access pattern for e-learning resources lie in the expensiveness of the learning content production, the high technical operation costs, the technical and didactical maintenance expenses along with the update processes, and particularly in the cost intensive user support.

Access to e-learning resources should be as user-friendly as possible. The user friendliest access procedure of course is achieved by a welcome message, informing about who is authorized to access the resource and no further access control system. However, without technical means to enforce access control, subscribers and non-subscribers access those unprotected resources, declaring to be open only for their subscribers.

Many possibilities exist to protect Internet resources from unauthorized access. The correct selection of an access control mechanism depends on the desired security level. Historically seen, access control systems, which do not scale for large user communities or fine-grained access control, protected resources first. By issuing a user name and a password to the users for example, the administration of a large user community causes a lot of work for the registration procedure and the user help desk, especially for forgotten user names and passwords. Because of this reason, for example libraries used and still use another access control system, based on IP numbers [Dc88]. However, all these access control systems have severe drawbacks as listed below:

 

  • With IP-based access control, the administration of the resulting IP number access lists is time consuming and hardly manageable for a high number of users.
  • With IP-based access control, there exists no administrative control to see, which user accessed the resource as the logs list IP numbers and not user names. Even IP numbers associated to single users could not help as some users may share IP numbers.
  • With IP-based access control, it is hardly impossible to evaluate statistically the user behavior and to implement payment systems due to the same reasons.
  • With IP-based access control, users traveling around and connecting from foreign places have always to ask for an entry of their actual IP number or host name in the access lists.
  • Many users connect via gateways with the Network Address Translation (NAT) protocol. Those users use internal IP numbers and appear all with the IP number used by the NAT device. In this way, many hosts can have the same IP on the Internet.
  • Many users having an IP number retrieve this number from a Dynamic Host Configuration Protocol (DHCP) server. This DHCP server issues IP numbers from a predefined IP range. In this way, users have no guarantee to receive always the same IP number.

 

Other access control systems help to overcome the above-mentioned drawbacks. They result to be more flexible, user friendly and administrable. The name for access control systems, which only authenticate users, is authentication infrastructures. The name for systems, which additionally authorize the authenticated users, is Authentication and Authorization Infrastructures (AAI). The term authentication and authorization infrastructure is not an expression for one special type of authentication and authorization infrastructure. It is a generic term for all infrastructures including user authentication and authorization.

It is necessary to differentiate (i.e. authorize) users’ access rights in a resource and not only to give or not give access (i.e. authenticate) a user. In e-learning resources for example, students can in no way have access to areas reserved for tutors. The term authentication and authorization infrastructure does not define where authentication and authorization take place. It is possible that the authorization process is combined with the authentication process or not. It is also possible that both processes are independent from each other. Some authentication and authorization infrastructures provide the possibility to split up authorization by giving users the possibility to decide how much personal information they want to release to a selected resource and by giving resources the possibility to decide if the users have provided enough information to access the resource.

We can broadly distinguish two major groups of resources in relation to access credentials. In one group, the resource provider only issues user credentials for the own resource. A commercial e-learning course provider, an Internet bookshop, an Internet bank or an Internet music store, working independently from other enterprises for example, maintain each an own user database. Advantages for the resource owners are that nobody else knows their customers and that those customers are fully transparent in their behavior in the resource.

In the other group, a group of resource providers issues user credentials for the group of their resources. Universities with many e-learning resources, multinational enterprises with many internal and external resources or universities from one country, which want to open their resources for all students of this country, for example prefer to issue one set of user credential per user and maintaining each user only in one database.

Because of the historical development of the Internet and of the resources, most users access resources with credentials only valid for the respective resource. This results in long lists of user credentials that users have to worry. The better way for everyone is thus, when resource providers issue user credentials valid for a set of resources. All involved parties benefit from such solutions, for example applied to e-learning resources:

 

  • Only one administration desk exists for student accounts, which are valid in many resources. The administration issues user credentials only once per user.
  • Resource providers do not have to care about user registration, administration and the user credential issuing processes, but only about subscribe or unsubscribe registered users to their resources.
  • Users benefit from user credentials that work with various resources.

 

The major conclusions here are that resource providers and resource users greatly benefit if not each resource but groups of resources issue user credentials. Moreover, user privacy is easier to maintain, if users can decide about the released information towards a resource. A consequence of these conclusions is the intention to realize architectures, which form computational grids, where users can access distributed resources and maintain user privacy. In such grids, users may originate from different organizations and places as well as access resources belonging to different organizations. Grids can provide seamless resource provisioning from many distributed resources to users. Such grids must comprise authentication, authorization, resource discovery and access mechanisms. In that way, for example a university can provide e-learning content located on different hosts to their students. The later presented distributed architectures for computer networks laboratories with geographically distributed laboratories are examples of such computational grids.

Famous representatives of computational grids solve ambitious computational jobs such as calculations of scientific or technical nature [FK98]. In many of these famous grids, most computers offering computational power to the grid belong to individuals who let their computers share not self-used computational power and contribute to the common goal of the respective grid. Grid resource users such as universities profit from the resources offered free of charge. Some grids resemble computer clusters with up to several thousand members and can compete with super computers. There exist many different computational grids [Sj03]. One of the most famous grids is seti@home, the grid used to search for extraterrestrial intelligence [ABDG97]. The Eurogrid is a grid infrastructure developed by another organization, which builds the base for several grids such as the Bio Grid, the Meteo Grid, or the Café Grid [ES01]. The mentioned grids process computational tasks in a distributed environment. The tasks consist of parts of bigger tasks. In our distributed architectures, a user interacts directly with one node of the e-learning grid and performs his or her tasks there. The tasks in our grid consist of hands-on trainings performed on the grid partners.

In some grids, participating users have to install client software on their computers. In other grids, no client software installation is necessary. The requirement for clients to install special software to be able to participate in a grid brings the burden of maintaining this software for the clients’ operating systems. Our architectures do not require clients to install own software and the prototypical implementations can be accessed with web browsers.

In grids, which solve computational tasks, servers distribute units of the entire computation tasks to the clients and collect the results. Under the many existing grids are grids that compute sensitive data and consequently have to use data encryption technologies for the data transfer in the Internet. For such types of grids, the Grid Security Infrastructure [BEFK00], which is a component of the Globus Toolkit [FK97b], is the de-facto security standard. In those grids, users delegate to the server the right to act for the user for initiating and monitoring this user’s operation on grid resources. To overcome these job delegation problems in the grid security infrastructure with standard web security protocols, a group proposed a solution based on web proxies. In our distributed architectures, sensitive data consists of the users’ actions on the distributed laboratories and of the user data transferred with the course platform. We do not forward sensitive data from one grid node, consisting of a laboratory, to another and thus apply encryption mechanisms such as secure sockets layer or secure shell.

Common to resource access control systems and data encryption technologies is the need for encryption keys. There exist symmetric keys, where identical keys serve for data encryption and decryption and asymmetric keys, where different keys serve to encrypt and decrypt data. In symmetric data encryption, both parties have to know the key. The key has to reach both parties in a safe way. This is not always possible and especially not over the Internet. This problem can be resolved by using asymmetric data encryption. In this technology, one of the keys is publicly available, for example on the Internet and used to encrypt data for the publisher. Only the publisher can then encrypt the respective data with the second key. A negative aspect of asymmetric encryption is the higher computational demand for encryption and decryption of data and thus there exist systems, where an asymmetric key serves to encrypt the symmetric key, which serves to encrypt the payload.


 

2.2       Authentication Issues

We start the discussion of authentication issues with the presentation of public key infrastructures. Public key infrastructures build a key element in encrypted data transport and in most authentication systems. Subsequently we discuss a state-of-the-art resource access infrastructure, which only performs user authentication and not authorization.

2.2.1   Public Key Infrastructures

Whenever we electronically exchange data, for example over the Internet, the equipment transforms the data in a well-defined number of ciphers. Such a well-defined number of ciphers can represent any kind of data and also electronic user credentials and electronic keys. It is possible to compute values from these well-defined cipher blocks itself. By means of these values, it is possible to verify if the cipher blocks changed on their way on their way or not. These cipher blocks and the way they are generated have well defined terms in the area of cryptography [Kb93]. We define these terms below:

 

Public Key

A public key is a value, for effectively encrypt messages and verify digital signatures issued by the corresponding private key. The public key may be publicly available, as it does not contain secret information. All secret information is stored within the corresponding private key.

Private Key

A private key is a value - known only to the owner - used to decrypt messages encrypted by the corresponding public key, issue digital signatures, which may be verified, by the corresponding public key, and compute the corresponding public key. The private key must not be publicly available and be kept private.

 

Together, a private and a public key form a key pair. It is only possible to decrypted messages, encrypted with the public key, with the corresponding private key.

 

Certificate Authority (CA)

The Certificate Authority is an authority in a network that issues, verifies, revokes, and manages security credentials and public keys for message encryption and signature verification.

Registration Authority (RA)

A Registration Authority is an authority, which verifies the certificate issuing procedure of the certificate authority by a policy. Registration authorities are the gatekeepers to the certificate authorities. The registration authority policy may be very strict and demand a personal show up of a user or very lenient up to issuing certificates to whom applies without verifying the identities.

Digital Certificate

A digital certificate consists of the public key and the identity of an entity, rendered unforgeable by digitally signing the entire information with the private key of the issuing certificate authority.

Certificate Revocation List (CRL)

A certificate revocation list is a collection of revoked digital certificates. Revoked certificates are no longer valid. Users query the list is to verify if the digital certificate in question is still valid.

Public Key Infrastructures (PKI)

A public key infrastructure is a system of digital certificates and certificate authorities that verify and authenticate the validity of each involved party.

Cross Certification

Cross certification means that certificate authority 1 signs the public key of certificate authority 2 with its private key and vice versa. In other words, certificate authority 1 certifies the root certificates of certificate authority 2 and vice versa.

 

The technical challenge is to achieve at least the same reliability level in the Internet as we in our daily life. A feasible way to achieve high security standards is the use of public key infrastructures [HFPS99]. The name public key infrastructure is used because certificate authorities issue digital certificates by signing public keys. Most of today’s issued certificates base on the X.509 Standard [X.509]. Public key infrastructures have become the de facto standard for establishing reliability over electronic networks.

The next Chapters present the major types of certificate authorities in use in today’s Internet, beginning with the single certificate authority model, the hierarchical certificate authority model, the cross certification authority model and ending with applications with trust lists.

Single Certificate Authority

The single certificate authority model is the most idealistic of the presented models. It is idealistic because it is impossible to have only one certificate authority worldwide, due to scalability and political reasons. In this model, each person gets a private key from the single existing certificate authority, in a secure out-of-band manner, for example in a personal hand-over of the private key. The same authority also signs the corresponding public key and stores this certificate in a certificate directory. The same authority also maintains a list with revoked certificates. Figure 2‑1 depicts a prototype of such a public key infrastructure. It consists of a certificate authority, a registration authority, one or more directories with the certificates and a certificate management system, containing a certificate revocation list.

 

Figure 21: Single certificate authority.

Figure 2‑1 also depicts the steps necessary when user A wants to certify his or her private key with a certificate authority and how user B obtains the respective public key for the encryption of a message to user A:

 

1)       User A applies for a public key certificate by the registration authority.

2)       User A complies with the registration authority’s policy and the registration authority allows the certificate authority to issue the certificate.

3)       The certificate authority signs user A’s public key and issues the certificate to user A as well as stores a copy in the certificate directory which is publicly accessible.

4)       User B wants to send a secret message to user A and needs to encrypt the message with user A’s public key. User B gets the public key from the certificate directory.

5)       User B queries the certificate revocation list.

6)       Only user A’s private key can decrypt such a message encrypted by user A’s public key.

 

A major problem with public key certificates is that nobody knows at first glance if they are still valid, revoked, or falsified. As in the single certificate authority model only one certificate authority exists, the process of verifying the actual state of a public key is relatively simple because only one certificate revocation list has to be maintained and queried by the users. Figure 2‑2 shows how user D may verify user C’s certificate issued by certificate authority X:

 

1)       User D queries the certificate directory and the certificate revocation list of certificate authority X to inquire if the certificate is still valid or revoked.

2)       User D requests user C’s certificate authority X’s public key which is publicly accessible.

3)       User D is now able verify the signature on user C’s public key certificate and learns if user C’s public key was issued by the certification authority X or not.

 

Figure 22: Certificate lookup with one certificate authority.

Hierarchical Certificate Authorities

In the hierarchical certificate authorities’ model, one root certificate authority signs the public keys of its sub certificate authorities and not public keys from each user as in the single certificate authority model. Each sub certificate authority can have one or more sub certificate authorities. In that way, it is possible to generate tree like structures with many sub certificate authorities. All certificate authorities could also sign user certificates but normally only the leaves of the tree do that. Figure 2‑3 shows the hierarchical model with one root certificate authority and two sub certificate authorities. The private key of the root certificate authority signs the public key certificates of certificate authority 1 and 2. User A’s and user B’s public key certificates are signed by their respective certificate authority. Everybody may validate these users’ public key certificates with the public key of the root certificate authority.

 

Figure 23: Hierarchical certificate authorities.

Cross Certificate Authorities

In the real world, many root certification authorities exist and certificate verification is a time consuming task impossible to execute for the majority of users in the Internet. To ease certificate verifications, some certificate authorities cross certify their root certificates.

The advantage of cross certification for users is that they can assume certificates reliable if that certificate authority’s public key is also signed by their own certificate authority. A certificate authority that signs another certificate authority’s public key is the root certificate authority and the other, the sub certificate authority. If a sub certificate authority signs other certificate authorities’ public keys and those do the same with other certificate authorities, they generate cross certification chains.

Figure 2‑4 shows certificate authority 1 and 2 that cross certify their certificates. Certificate authority 1 uses its root private key to sign the root public key of certificate authority 2. The thereby signed public key becomes now certificate authority 2’s public key certificate. Certificate authority 2 does the same but vice versa. Certificate authority 1’s public key can now be used to verify certificate authority 1’s issued public key certificate but also to verify certificate authority 2’s issued public key certificate and vice versa. User A’s key pair consists of a private key and public key which is signed by certificate authority 1’s public key, resulting in user A’s public key certificate. The same happens for user B with certificate authority 2. User A’s certificate allows to User B to verify the validity of this certificate and vice versa.

 

Figure 24: Cross certification with two certificate authorities.

Applications with Trust Lists

All users may store trust worthy public key certificates in applications, which possess the trust list feature. The acceptance and storage of these certificates demands a certain understanding from users as well as the ability to read the policy conditions, which can already be a problem due to an unknown language. Applications featuring pre-configured trust lists containing public key certificates of those root certificate authorities, which spent time and money and conform to the policies for the list integration make the installation procedure for end users obsolete.

Most web browsers, feature trust lists with pre-stored root certificates from many different certificate authorities. Figure 2‑5 shows user, A which uses a web browser.

 

Figure 25: Trust lists.

In this web browser, root certificate authorities 1 to 4 have already inserted their root public keys. User A could remove unwanted keys of the list or additionally add new keys. User A now opens a web site, which makes use of encrypted data. The web site owner owns a public key certificate from root certificate authority 2. User A may now validate this certificate by means of the built in root certificate of certificate authority 2. If the web site owner does not belong to a pre-added certificate authority, the user has to decide if he or she wants to accept and install the new certificate and trust the new certificate authority.

Public Key Infrastructure in Grid Computing

At least one of the global grid projects, the Grid Security Infrastructure, uses the above-discussed PKI technologies for the data transmission between its servers and clients. As discussed, in public key infrastructures messages can be decrypted only with the respective private key. This is a problem in the area of mass computing such as in the Grid area as clients send calculation jobs to a network of linked computers unable to decrypt the data because they do not have the users’ private key. To overcome this problem, grid security infrastructure makes use of delegated proxies acting on behalf of users and resources. A delegated proxy is a proxy acting on behalf of the anterior proxy. Such proxies do not use the original long-lived certificates but their own short-lived ones. The advantage of those self-signed certificates lies in their short lifetime and the resulting loss of danger for involved keys in automated processing. These proxies can communicate without involving the real user. [NTW01] describes an implementation of such a proxy chain in detail.

Evaluation of the Different Models

After the discussion of the different public key infrastructure models, we discuss and evaluate their advantages and disadvantage, for the use in the later discussed architectures.

Single Certificate Authority

It is an unrealistic assumption that one day, only one certificate authority would exist worldwide, and that each user gets his or her signed public key certificate directly from there. This root certificate authority would have immense power and be able to control all certificate holders. For an e-learning architecture, the single certificate authority model is interesting in an isolated environment. It enables the operator of such an environment to issue own certificates for server-to-server traffic and for the users. Users would have to accept and import the server certificates in their applications such as web browsers, the first time they get into contact with encrypted data of this certificate authority. Certificate authorities often issue the server certificates are over the Internet, an issuing process with a potential for data interception by attackers.

Hierarchical Certificate Authority

The hierarchical certificate authority model delegates responsibility to sub certificate authorities. All sub certificate authorities have to comply with the policies of all their upper certificate authorities but may issue policies that are more limited. The root certificate authority is still very powerful. This model is interesting, if for example a country sets up an official root certificate authority and organizations within this country operate sub certificate authorities. The advantage over the single certificate authority model lies in the delegation of reliability and administrational work to a root certificate authority, which manages law and financial issues. Due to the larger user community in the hierarchical model, the possibility that root keys of such root certificate authorities find their way in applications such as web browser is much higher than in the single certificate authority model. Another advantage is that an organization may set up two certificate authorities with different policies under the same root certificate authority, one for server certificates, and another for user certificates.

Cross Certificate Authority

Cross certification is a useful workaround, which allows relating certificate authorities of the single and hierarchical model and make root certificates of one certificate authority accepted by more users. However cross certification complexity increases with the number of partners. With each joining certificate authority, it is more difficult to keep track of the certificate network, especially if considering that certification chains can intersect. In big cross-certified networks, reliability may easily get lost and the advantages of public key infrastructures go along.

Applications with Trust Lists

Trust lists provide a high comfort to end users. Due to the pre-added public keys to users’ applications such as web browsers, no further user interaction is necessary when transferring encrypted data with the resource servers. If root certificates are not integrated in users’ applications, users get used to accept certificates and skip warning messages. A negative aspect is that users do not know most certificates in the trust lists of their applications (e.g. in web browsers). Integration of root certificates into applications is time consuming and expensive but alleviates e-learning resource users from the task of certificate installations in their applications.

Comparison and Recommendations

The features of each of the three evaluated public key infrastructures are condensed and compared in Table 2‑1. Features provided are marked as X, features provided under certain conditions as (X).

 

 

Single
certificate authority

Hierarchical certificate authority

Cross
certificate
authorities

One root certificate authority

X

X

 

Several root certificate authorities

 

 

X

One registration policy

X

 

 

Several registration policies

 

X

X

One certificate realm

X

 

 

Several certificate realms

 

X

X

Delegable certificate realms

 

X

(X)

Different trust standards

 

(X)

X

Provides full authority to resource owners in whole certificate realm

X

 

 

Provides full authority to resource owners in own certificate realm

 

X

 

Single and hierarchical certificate authorities linkable without loosing independency

 

 

X

Useful if server to server traffic is encrypted as no user applications have to be adapted

X

X

X

Lower costs for certificate integration in user applications

 

X

(X)

One certificate revocation list

X

 

 

Several certificate revocation lists

 

X

X

Table 21: Comparison of PKI models.

Evaluation recommendation:

We do not recommend using a single certificate authority for server-to-server traffic encryption and no end user applications can get into contact with the issued certificates without having to install the certificates manually or without spending a high amount of money for the certificate integration into applications such as web browsers. We recommend using a hierarchical certificate authority model in the role of a sub certificate authority with control over its own certificate realm. The costs for the integration of root certificates in user applications should be lower than in the single certificate model due to the larger user community participating in the costs. Cross-certified certificate authorities are interesting enhancements to the single and hierarchical certificate authority models. However, cross certifying many certificate authorities results in a loss of trustworthiness in the trust network. We recommend using end user applications with trust lists in any case with traffic between end users and servers.

2.2.2   Authentication with Kerberos

The Massachusetts Institute of Technology (MIT) developed Kerberos [CT94]. The name Kerberos originates from Greek mythology, where Kerberos is the name of the three-headed dog that guards the entrance to Hades. Kerberos is a network authentication protocol, designed to provide strong authentication for client/server applications by using secret key cryptography. Secret key cryptography is a synonym for symmetric key cryptography and thus in secret key cryptography, the same key serves to encrypt and decrypt data, in contrast to public key cryptography, where a public and a secret key are necessary. In Kerberos, client and server applications must be Kerberos enabled. The main components in Kerberos are the Authentication Server (AS) and the Ticket Granting Server (TGS). These servers together with a database form a Key Distribution Center (KDC). Kerberos bases on keys for user authentication (kU) and resource access (kR) as shown in Figure 2‑6. All resources together with the key distribution center form a Kerberos realm. Up to Kerberos version 4, it was necessary to establish a shared secret between all involved parties. This limited the inter-realm connectivity as it was hardly possible to establish the same shared secret over multiple realms, especially due to security risks in the case of corruption of the shared secret. From version 5 on, Kerberos is more scalable because it is possible to arrange hierarchically different Kerberos realms. Each of these realms has its own authentication server and ticket-granting server. It is also possible to use public key cryptography additionally to the shared secret of the secret key cryptography.

Figure 2‑6 shows the involved parties in a Kerberos system. Both, the user and the service on the resource are required to have keys registered with the authentication server. The user U that is located at his or her computer wants to access the Kerberos protected resource R:

 

1)       The user logs-in to the computer and provides his or her user name and password together with his or her key U (kU) for authentication with the authentication server.

2)       The Kerberos client installed on the computer sends a request for these credentials to the authentication server. The request is contains the user name U to be authenticated, the current time, the desired expiration time of the authentication ticket and a random number.

3)       The authentication server checks if U is in its database and if it is the server sends back to messages to the client: message A contains the client/ticket-granting server session key. This message is encrypted with the secret kU of the user. Message B contains the client identity, the client’s network address, the ticket expiration time a random number and the client/ticket-granting ticket session key. This message is encrypted with the secret key of the ticket-granting server. Another name is Ticket Granting Ticket (TGT).

4)       The client now decrypts message A and with the client/ticket granting ticket session key, the user can now request a ticket from the ticket-granting server with two messages. Message C contains message B and the identity of the resource R. Message D contains the client’s identity, and a timestamp. This message is encrypted with the client/ticket granting ticket session key. The client itself cannot decrypt message B, which is encrypted with the ticket granting servers’ secret key.

5)       Upon receiving messages C and , the ticket granting server decrypts message D with the client/ticket granting server session key and sends two messages to the client: message E contains the client’s identity, the client’s network address, the ticket expiration date and a client/resource session key, encrypted with the resource’s secret key kR. Message F contains the client/resource session key, encrypted with the client/ticket granting server session key.

6)       The client sends these credentials to the resource R for accessing the requested service. Message G contains message E and is encrypted with the resource’s secret key. Message H contains message D, encrypted with the client/resource’s session key. The resource now receives and decrypts the messages with its own kR and the service provisioning starts.

7)       The resource signals back its decision to the user U.

 

Figure 26: Kerberos authentication.

Figure 2‑7 shows a user of Kerberos realm A accessing a resource in Kerberos realm B. The user has keys registered with the authentication server of realm A, the resource with the authentication server of realm B. The user of realm A accesses the computer and wants to access the Kerberos protected resource:

 

1)       The user logs-in to the computer and provides his or her user name and password together with his or her key U (kU) for authentication with the authentication server of his or her Kerberos realm A.

2)       The Kerberos client installed on the computer sends a request for these credentials to the authentication server of realm A. The request is contains the user name U to be authenticated, the current time, the desired expiration time of the authentication ticket and a random number.

3)       The authentication server checks if U is in its database and if it is the server sends back to messages to the client: message A contains the client/ticket-granting server session key and also the key distribution center URL of realm B. This message is encrypted with the secret kU of the user. Message B contains the client identity, the client’s network address, the ticket expiration time a random number and the client/ticket-granting ticket session key. This message is encrypted with the secret key of the ticket-granting server. Another name is Ticket Granting Ticket (TGT).

4)       The Kerberos client installed on the computer this time sends an authentication request for the user to the authentication server of realm B, together with the credentials of realm A, consisting of the decrypted message A. With the client/ticket granting ticket session key, the user can now request a ticket from the ticket-granting server with two messages. Message C contains message B and the identity of the resource R. Message D contains the client’s identity, and a timestamp. This message is encrypted with the client/ticket granting ticket session key. The client itself cannot decrypt message B, which is encrypted with the ticket granting servers’ secret key.

5)       Upon receiving messages C and , the ticket granting server of realm B decrypts message D with the client/ticket granting server session key and sends two messages to the client: message E contains the client’s identity, the client’s network address, the ticket expiration date and a client/resource session key, encrypted with the resource’s secret key kR. Message F contains the client/resource session key, encrypted with the client/ticket granting server session key.

6)       These credentials can be sent to the resource for accessing the requested service in the other Kerberos realm. The resource now receives the ticket and the service accepts or rejects the ticket.

7)       The client sends these credentials to the resource R for accessing the requested service in the other Kerberos realm. Message G contains message E and is encrypted with the resource’s secret key. Message H contains message D, encrypted with the client/resource’s session key. The resource now receives and decrypts the messages with its own kR and the service provisioning starts.

8)       The resource signals back its decision to the user U.

 

Figure 27: Kerberos inter-realm connectivity.

Evaluation of Kerberos

Kerberos is a widely deployed authentication infrastructure but not an authorization infrastructure. Client software for the most used applications and server software exist for Microsoft Windows, Linux, and UNIX operating systems. Only resources with many users such as commercial course platform [GSS96 and GS97] for example are Kerberos enabled. Smaller resources are not Kerberos enabled. Even with the improvements realized in Kerberos version 5, some limitations remain and an inter-realm shared secret or a public key infrastructure certification are necessary. Inter-realm connections may result in long certification chains, as an accessed resource in a foreign realm has to trace back the user’s realm via the next realms in between. Therefore, Kerberos does not scale for large user groups, which do not belong to a limited number of organizations. A disadvantage of Kerberos is that it is not designed for user authorization. It is only indirectly possible to authorize users. The only possibility to authorize users in Kerberos is by issuing authentication tickets, related to access rights defined in additional databases. This kind of authorization causes high administrational overhead, because each user’s authorization state, based on these additional authentication ticket has to be stored in a database belonging to the e-learning courses resource management system. Nowadays, it is easier to handle user authorization if it bases on user information attributes.

 

User information Attribute

An attribute is a property of something. There exists pre-defined attributes with corresponding values. A user information attribute for a user name is such a pre-defined attribute in conjunction with the respective user value.

 

Table 2‑2 lists the advantages and disadvantages found in Kerberos:

 

Advantages

Disadvantages

·          Secure authentication infrastructure.

·          Broadly deployed.

·          Natively supported in Microsoft operating systems Windows 2000 and XP.

·          Supported in UNIX derivatives.

·          Pure authentication infrastructure, authorization must be based on authenticated identities.

·          Inter-realm resource access is complicated to realize.

·          Only organizations, which operate a key distribution center for their users can participate

Table 22: Advantages and disadvantages of Kerberos.

 

Evaluation recommendation: We do not recommend using Kerberos for the below described portal and e-learning architectures. Kerberos is principally an authentication infrastructure and misses the authorization part, important for e-learning resources such as the computer networks laboratory. Kerberos especially lacks the feature of user authorization based on user information attributes.

 


 

2.3       Secure Data Transport

This Chapter discusses and evaluates related technologies for the secure data transport between servers and servers as well as servers and end users.

2.3.1   Internet Protocol Security

Internet Protocol Security (IPSec) [SBDG02] is a technology for securing data transport between servers as well as between servers and users in the Internet on IP level. This makes IPSec an interesting potential technology to for securing traffic in e-learning architectures. Furthermore, IPSec is the main topic of one of the below presented e-learning module implementations in the computer networks laboratory. We therefore discuss IPSec in detail. The Internet Engineering Task Force (IETF) standardized IP version 6 (IPv6) [DH98 and Bt99] to solve pending problems such as address shortage of the current version of the IP protocol (IPv4). A spin-off development of this process was the IP security architecture, which introduces per-packet security features. While delays in the IP version 6 deployment occurred, the security architecture was adapted to the current IP version (IPv4). A key motivation for this adaptation was that Internet protocol security comprises all security mechanisms needed to implement a Virtual Private Network (VPN).

 

Virtual private network

A virtual private network is an encrypted data link, allowing the use of public networks for sending private data.

 

The Internet security architecture comprises of a family of protocols. IPSec describes IP packet header extensions and packet trailers, which provide security functions. We present the Authentication Header (AH), Encapsulating Security Payload (ESP), Security Associations (SA), and Internet Key Exchange (IKE) in more detail. The per-packet security functions originate from two protocols: The authentication header [KA98a], which provides packet integrity and authenticity and the encapsulating security payload [KA98b], which provides privacy through encryption. Authentication header and encapsulating security payload are independent protocols, applicable separately or combined. A reason for the separation of the security mechanisms was that there exist countries with restrictive regulations for encrypted communication. In such countries, IPSec can be deployed solely using authentication header because authentication mechanisms are free unlike payload encryption. The set of authentication header and encapsulating security payload is also required in order to guarantee interoperability between different IPSec implementations. Both protocols’ specifications do not include cryptographic algorithms. Hence, it is simple to add a new encryption algorithm to IPSec. Both authentication header and encapsulating security payload assume the presence of an encryption key known to the involved parties. This key may be installed manually. A better and more scalable approach is to use the third protocol of the IPSec family: the Internet key exchange protocol [HC98].

Security Association and Security Policy Database

At some point in the network, both authentication header and encapsulating security payload protocols perform a transformation to IP packets. The IPSec compliant nodes always form sender/receiver pairs where the sender performs the transformation and the receiver reverses it. The security association describes the relation between sender and receiver. Nota bene that the security association describes just one transformation and its inverse. Concatenated security associations describe concatenated authentication header and encapsulating security payload transformations. Security associations may be seen as descriptions of established IPSec connections. Both IPSec peering machines store representations of security associations. An IPSec security association specifies important settings:

 

  • The mode of the authentication algorithm used in the authentication header and the respective keys.
  • The encapsulating security payload encryption algorithm mode plus the respective keys.
  • The presence or absence of any cryptographic key synchronization used to determine the identical transaction key used in the selected encryption algorithm.
  • The frequency for the exchange of those keys.
  • The authentication algorithm and authentication mode applied in encapsulating security payload plus the respective keys.
  • The key’s lifetime.
  • The own lifetime.
  • The source address.
  • The sensitivity level descriptor, a security level indicator.

 

A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI) (a 32-bit number), the destination IP address, and the IPSec protocol in use (authentication header or encapsulating security payload). The sending party writes the security parameter index into the appropriate field of the IP protocol extension. The receiver uses this information to identify the correct security association. The receiver is able to invert the transformation and to restore the original packet. Each IPSec compliant machine may be involved in an arbitrary number of security associations.

Accordingly, a security association is a management construct used to enforce a security policy in the IPSec environment. The policy specifications are stored locally in every IPSec node’s Security Policy Database (SPD), consulted each time when processing inbound and outbound IP traffic, including non-IPSec traffic. The security policy database contains different entries for inbound and outbound traffic. The security policy database determines if traffic must be encrypted or can remain as clear text, or if traffic must be discarded. If traffic is encrypted, the security policy database must point to the respective security association by a selector, a set of IP and upper layer protocol field values to map traffic to a policy.

Transport and Tunnel Mode

Both, encapsulating security payload and authentication header have two modes: the transport mode and the tunnel mode. In the transport mode, only the payload and a part of the IP header get encrypted and authenticated. It extends the IP headers by adding additional fields. The original IP header remains the same before and after encryption. Figure 2‑8 shows an IP packet after applying the authentication header protocol. The authentication header adds information between the original IP header and the TCP/UDP/ICMP header. Figure 2‑9 shows an IP packet after applying the encapsulating security payload protocol. After the original IP header, the encapsulating security payload header is inserted and at the tail, an encapsulating security payload trailer 1and an encapsulating security payload authentication are added.

 

Figure 28: IP packet after applying AH in transport mode.

 

Figure 29: IP packet after applying ESP in transport mode.

 

The tunnel mode is ideal for implementing a virtual private network tunnel between Internet access routers as access routers can be equipped with special hardware, which encrypts and decrypts data faster than end systems without the respective hardware. Equipping many end systems with this type of hardware is more expensive than equipping few access routers. Figure 2‑10 shows an IP packet after applying the encapsulating security payload protocol in tunnel mode. The packet begins with a new IP header containing the addresses of the IPSec tunnel end points followed by an encapsulating security payload header. Then, the original IP packet follows and at the tail, an encapsulating security payload trailer and an encapsulating security payload authentication added.

 

Figure 210: IP packet after applying ESP in tunnel mode.

The new IP header may be secured using authentication header. The tunnel mode allows passing non-routable IP addresses or other network protocols through a public network as the addresses of the inner header are hidden. Hiding the original network topology also provides privacy.

The Internet Key Exchange Protocol

If two parties would like to communicate using IPSec, they need to negotiate the parameters in the security association. If the parameters have to be established manually, the process is time consuming and assumes that the involved parties possess required knowledge. The Internet key exchange protocol allows two nodes to automatically and securely set up and renew the required security associations. Internet key exchange uses the Internet Security Association and Key Management Protocol (ISAKMP) [MSST98] to exchange messages. The Internet security association and key management protocol provides a framework for authentication and key exchange but does not define a particular key exchange scheme. Internet key exchange uses parts of the two key exchange schemes Oakley [Oh98] and Secure Key Exchange Mechanism (SKEME) [Kf96].

Internet key exchange operates in two phases. In phase 1, the two peers establish a secure authenticated communication channel (also called ISAKMP security association). In phase 2, security associations can be established on behalf of other services (most prominently IPSec security associations). Phase 2 exchanges require an existing Internet security association and key management protocol security association. One Internet security association and key management protocol security association can protect several phase 2 exchanges and a phase 2 exchange can negotiate several security associations on behalf of other services. The Internet security association and key management protocol security association is bi-directional and the following attributes are used by Internet key exchange and negotiated as part of the Internet security association and key management protocol security association: encryption algorithm, hash algorithm, authentication method, and initial parameters for the Diffie-Hellman algorithm [Sb96].

2.3.2   Secure Sockets Layer and Transport Layer
Security

The Secure Sockets Layer Protocol (SSL) developed by Netscape [FKK96] or the standardized version Transport Layer Security (TLS) [DA99] are designed to provide privacy and data integrity between two communicating applications (i.e. a client and a server) by using public key cryptography as described in Chapter 2.2.1 for example together with RSA or DSS [RSA78 and GJKR96]. TLS 1.0 and SSL 3.0 do not interoperate although TLS is an enhancement of SSL [Ra00]. The protocols are also designed to authenticate the server, and optionally the client. SSL/TLS require a reliable transport protocol (e.g. TCP [Pj81]) for data transport.

One advantage of SSL/TLS protocols is that it is application protocol independent. This makes secure sockets layer a base technology for applications used in the e-learning architecture. An application level protocol, such as the Hypertext Transfer Protocol (HTTP) [FGMF99], the File Transfer Protocol (FTP) [PR85], and Telnet [PR83] can layer on top of the SSL/TLS protocols transparently as shown in Figure 2‑11. SSL/TLS protocols can negotiate an encryption algorithm and a session key as well as authenticate a server before the application protocol transmits or receives its first byte of data. SSL/TLS support the use of X.509 digital certificates from the server so that, if necessary, a user can authenticate the sender.

 

Figure 211: SSL/TLS principle.

All application protocol data is encrypted before transportation, be it HTTP, Internet Message Access Protocol (IMAP) [LLM97], Lightweight Directory Access Protocol (LDAP) [YHK95] or others thereby ensuring privacy. Connections provided by SSL/TLS protocols are private, authenticated, and reliable. All messages are encrypted using secret key cryptography for example with DES, 3DES or RC4 [DES, Tw79, TK97] with a session key that is defined at the beginning with an initial handshake. A session key is a cryptographic key valid only for one communication session. The server endpoint of the conversation is always authenticated, while the client endpoint authentication is optionally. The protocol includes a message integrity check using a Message Authentication Code (MAC) for detecting packet alteration between client and server. The MAC is calculated using secure one-way hash functions for example with SHA or MD5 [SHA, Rr92].

Secure Tunnel

The Secure tunnel or Stunnel [VMC02] is an application, which uses secure sockets layer to encrypt and tunnel TCP connection between the IP ports of two networked computers. Doing so, non-secure sockets layer aware applications’ traffic can be encrypted without changing their program code. A Stunnel server provides two functionalities: First, it receives unencrypted traffic, encrypts the traffic, and sends it to the Stunnel client over the Internet. Secondly, it receives encrypted traffic, decrypts the traffic, and then sends it over the Internet to another program residing on the same computer. Stunnel may be used for encrypting server-to-server traffic in the e-learning architecture.

Hypertext Transfer Protocol over Secure Sockets Layer

Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) or HTTP over SSL [BFF96] is used for encrypted transport of web pages over secure sockets layer. Most web browsers (Netscape, Explorer, Mozilla, Opera, Safari, etc.) support HTTPS without any additional software installation on the client side. HTTPS encrypts and decrypts user page requests and the returned pages. HTTPS connections are often used for submitting private information such as credit-card numbers and personal details. Web servers such as Apache and Microsoft Internet Information Server can be equipped with SSL/TLS modules. HTTPS may be used for a secured transport of web pages of the e-learning architecture.

2.3.3   Secure Shell

During a long time, Telnet served for remote access to computers. Although still in use, it is no longer popular due to its unencrypted data transport. In addition, user name and password pass Internet in clear text. The Telnet successor’s name is Secure Shell (SSH) [Yt96]. SSH provides secure login, file transfer, and TCP/IP connections over a public insecure network such as the Internet. It uses cryptographic authentication, automatic session encryption, and integrity protection for transferred data. The available SSH clients provide least the same functionalities as Telnet does. SSH supports the use of public key cryptography. SSH may be used for the client connection to the resource servers and laboratory devices of the e-learning architecture.

 

 

2.3.4   Evaluation of the Different Transport Technologies

Evaluation of Internet Protocol Security

IPSec is a potential candidate for the encryption of server-to-server traffic. Unfortunately, the implementations of the Internet key exchange protocol is not so advanced as necessary to use it for server to end system encryption and most IPSec tunnels must be set up manually. This is a major disadvantage as nobody can expect users to set up complicated tunnel configurations before attending an e-learning resource. IPSec is the choice for securely transporting traffic from whole sub networks behind access routers to other network areas.

Evaluation of Secure Sockets Layer

SSL/TLS is an option for securing the network traffic from different applications. SSL/TLS is able to encrypt the traffic between servers and servers and clients. An advantage of SSL/TSL is that public key infrastructures may be used for issuing encryption keys. Particularly applications with pre-configured trust lists in combination with root certificate authorities, which have stored their root certificates in these trust lists, facilitate the user access to the e-learning resources.

Stunnel bases on SSL/TLS and provides a safe data transport over public wires. It is an encryption technology, which is deployable within minutes and provides the advantage of tunneling traffic from unmodified applications’ IP number port to IP number port.

HTTPS bases on SSL/TLS and supported by most existing web browsers. It is user-friendly, as users do not have to install additional software to retrieve and send encrypted web pages.

Evaluation of Secure Shell

Secure shell is an application for directly connecting clients to hosts and having the same working environment as with a Telnet shell. The advantage of secure shell is that it encrypts all the traffic. It is possible to use a public key infrastructure for issuing encryption keys. Secure shell implementations exist in many variations, also as Java applets. It is essential for a computer networks laboratory that students can connect to the laboratory devices such as routers and hosts in the same way they would do this locally. Secure shell provides this possibility. The existing Java version additionally fulfills the requirement of no additional software installation on client side.


 

Comparison and Recommendations

The features of each of the three evaluated secure data transport technologies are condensed and compared in Table 2‑3. Features provided are marked as X, features provided under certain conditions as (X).

 

 

IP security

SSL/TLS

Secure shell

Standardized protocols

X

X

X

Tunnels data traffic from IP number to IP number

X

 

 

Tunnels data traffic from IP number port to IP number port

 

X

X

Use of PKI issued keys possible

X

X

X

End user friendly set up

(X)

X

X

Available for most operating systems

X

X

X

Widely deployed

X

X

X

If public key certificate is not pre- stored to the trust lists of the applications, users have first to accept/import the certificate.

 

X

(X)

Table 23: Comparison of Transport Technologies.

Evaluation recommendation:

We recommend using IP security protocols for the encryption of the server-to-server traffic in the e-learning architecture as the complexity for the set up of these connections can be justified by the high security level achieved. For non-static server IP numbers or in the case simpler set up procedures and less security is necessary, we recommend using an SSL/TLS based encryption method such as Stunnel. We recommend using the SSL/TLS based HTTPS encryption for the web page transport between resource servers and students, tutors and administrators. We recommend using SSH for the encrypted data transfer between resources of the e-learning architecture, which exceed shell access, such as the laboratory devices of the computer networks laboratory.


 

2.4       Authentication and Authorization
       Infrastructures

This Chapter starts with the discussion of the lightweight directory access protocol, the authentication and authorization infrastructure, which builds the base of the resource management system in both of the multifunctional e-learning architectures. Subsequently we discuss Shibboleth, the authentication and authorization infrastructure chosen by the Swiss universities [Gc03]. Although Shibboleth is the pre-selected architecture for the Swiss universities and the prototypical implementation of the e-learning computer networks laboratory belongs to a Swiss university, we discuss, evaluate, and compare potential competitors. After Shibboleth, we discuss another interesting authentication and authorization infrastructure with similarities to Shibboleth, the Spanish authentication and authorization infrastructure PAPI. We then discuss the remote authentication dial-in user service RADIUS and Diameter, its further development. We also discuss the Liberty Alliance project, a standardization alliance, which intends to group existing standards and protocols together and to provide a single sign-on system similar to Shibboleth, but with accounting and charging in mind. We also discuss the Microsoft passport project, the trigger for the formation of the liberty alliance. We conclude this sub Chapter with a comparison of all the infrastructures and recommendations for their use in our architectures.

2.4.1   Lightweight Directory Access Protocol

In Chapters 4 and 5, we describe a multifunctional e-learning architecture and its extended version. The preconditions to a technology for the implementation of such architecture are integrated authentication and authorization mechanisms, as well as the possibility to use it for laboratory device reservations. We have chosen the lightweight directory access protocol, because it fulfills these preconditions. LDAP is also extendable in several directions, it allows, for example, to use standardized user information attributes but also to define own user information attributes. Furthermore, it is possible to subordinate an architecture based on the lightweight directory access protocol to other authentication and authorization infrastructures. In this Chapter, we discuss the technical features of the lightweight directory access protocol, optimized for fast read access to databases for clients, such as the geographically distributed laboratories of the computer networks laboratory. These laboratories connect to the Internet with laboratory portals, which act as brokers between the laboratory devices and the users as well as the resource management system. The laboratory portals frequently read out the reservation status of the hands-on trainings in the database, whereas user account changes and bookings in the database occur less frequently. Initially, the design of the lightweight directory access protocol described how clients access X.500 directories, without incorporating all the functionalities of the Directory Access Protocol (DAP). In the meantime, the further developed lightweight directory access protocol is a client/server protocol for accessing existing X.500 directories but also a standalone directory server. Because of the further development, there exist LDAP clients and LDAP servers now. LDAP clients send a protocol request, which describes the requested operation on the server. LDAP servers function as a replacement of the X.500 servers and are responsible for performing the necessary operations on the directory database. Upon completion of the necessary operations, the server provides the directory information to the clients.

Attribute Types and Object Classes

In X.500 and LDAP directories, information is stored as values related to attributes, i.e. attribute/value pairs. The same syntax of attribute-value pairs is also valid for X.509 certificates, where the same standardized attributes are used. Each dataset in an LDAP directory starts with the attribute distinguished name (dn), which can be considered as the most important attribute at all.

A distinguished name uniquely identifies an entry within the hierarchical directory. The dn consists of the entry's name plus the path (list of entry names) back to the top of the tree. Figure 2‑12 shows the principle of an LDAP tree with some attributes taken from Table 2‑4. There is always an origin at the bottom of the trunk. Each distinguished name starts at a leave, going back from branch to branch until reaching the trunk.

Figure 212: LDAP tree.

Each dn must be unique and can only exist once in an LDAP directory. A dn is the key to find its corresponding entry within the tree-like directory structure. From right to left, a dn contains all the entry's names leading from the top level to the desired entry. The dn

 

dn: sn=Steinemann,cn=Marc Steinemann,o=Universität Bern,c=CH

 

means that the person Marc Steinemann with the surname Marc belongs to the organization University of Bern, which is located in Switzerland (CH). The top level in the directory of this example is the country. The next sub level is the organization, then the common name. Trees can split up, for example, Switzerland can have multiple organization entries, or organizations can have multiple sub trees for their units (ou: organizational unit). Shows a selection of standardized attributes:

 

Attribute

Meaning

c

country

dn

distinguished name

cn

common name

sn

surname

o

organization

ou

organizational unit

Table 24: Set of standardized LDAP attributes.

Attribute types more precisely specify attribute/value pairs. An attribute type defines the data representation format and the order of the associated values. Additionally, an attribute type allows specifying whether an attribute consists of one single value or of a set of values. An object class specifies a collection of attributes. An object class specifies the collection of attributes available to specify a data set. There are two groups of attributes. The first group specifies required attributes in order to specify a valid data set; the second group lists additional attributes, which can characterize the data set. A data set can belong to more than one object class if it provides all the required attributers specified in the concerned object classes. Data sets must belong to at least one object class.

Schema Files

The different available object classes and attribute types are stored in schema files. There exist standard schema files like core.schema that defines the LDAP schema items specified in RFC 2251 – 2256 and cosine.schema describes items specified in RFC 1274. These essential schema files include the most common object classes and attributes. The specification for the attribute name looks as Figure 2‑13 shows:


 

attributetype ( 1.3.6.1.4.1.3536.2.7.1.4
        NAME 'hostname'
DESC 'Hostname of the machine where the file is stored'
        EQUALITY caseIgnoreMatch
        ORDERING caseIgnoreOrderingMatch
        SUBSTR caseIgnoreSubstringsMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Figure 213: Attribute definition schema.

The attribute is specified by a unique number expressed as a number in the Abstract Syntax Notification number 1 (ASN.1) code [TNF97] and the attribute’s name. The parameter DESC describes the abstract number in a human understandable form. EQUALITY specifies if the attribute is case sensitive or insensitive. This is a quite important decision, especially for a directory where persons frequently search for names and do not want to repeat each search with all possible writings of the name. ORDERING specifies if the attribute values have to obey a certain order and SUBSTR specifies if the substrings of the attribute are case sensitive. SYNTAX specifies the type of value.

Figure 2‑14 shows the specification for the object class globus (this is not a real existing object class):

 

objectclass ( 1.3.6.1.4.1.10434.99.97.111
        NAME 'globus'
        DESC 'describes the Globus'
        SUP top
        STRUCTURAL 
        MUST sn $ cn )
        MAY o $ ou $ c

Figure 214: Object class definition schema.

Each specified object class is defined by an ASN.1 number followed by the parameter NAME and the name of the object class. SUP specifies the parent object class from which the current object class inherits specifications. STRUCTURAL prevents a dataset to belong to more than one structural object class. It helps for example, to prevent that a dataset can represent a person and an organization at the same time. MUST specifies the attributes a dataset must contain and MAY specifies the attributes a dataset may contain.

Importing and Modifying Data

Principally, we can enter LDAP data in two ways: The first is to enter the data in the command line, each by each. The second is to write an LDAP import file (ldif). There exist tools with graphical user interfaces, which use the first method to add, modify, and delete data.

An ldif file to add a dataset for Marc Steinemann at University of Bern looks as Figure 2‑15 shows:

 

 

dn: c=CH

objectclass: top

objectclass: country

c: CH

 

dn: o=Universität Bern,c=CH

objectclass: organization

o: Universität Bern

 

dn: cn=Marc Steinemann,o=Universität Bern,c=CH

objectclass: person

cn: Marc Steinemann

sn: Steinemann

Figure 215: Example ldif file.

Aliasing

It is possible to alias already existing directory entries to other locations in the directory. The advantage of aliasing entries lies in the fact that the data update process is much easier because only one copy of a data set exists.

 

dn: cn=Marc Steinemann,ou=IAM,o=Universität Bern,c=CH

objectclass: alias

aliasedobjectname: cn=Marc Steinemann,ou=RVS,o=Universität Bern,c=CH

Figure 216: Alias entry.

Figure 2‑16 shows an alias entry for Marc Steinemann who works at the department IAM in the University of Bern. Now he starts to work at department RVS and the administrator of department RVS aliases to the initial dataset. After the dn the object class defines that this entry is an alias. The object class alias has a required attribute called aliasdobjectname, which adds the data of the original dn to itself.

Referring

LDAP gives the possibility to refer to other LDAP directories. With such referrals, it is possible to include directory branches of one server into the directory tree of another server. The sub tree of the second server refers with a link in the root server (i.e. the server that is linking to the other server). The functionality of a referral is similar to the one of an alias with the difference that it does not link within a directory but between directories.

Figure 2‑17 shows two datasets in two different directory servers, each for an own branch of the same organization:

 

dn: o=Universität Bern,c=CH

objectclass: organization

o: Universitä Bern

 

dn: ou=FirstFloor,o=Universität Bern,c=CH

objectclass: organizationalunit

ou: FirstFloor

 

dn: cn=Marc Steinemann,ou=Phil. Nat,o=Univesität Bern,c=CH

objectclass: person

cn: Marc Steinemann

sn: Steinemann

 

 

dn: o=Universität Bern,c=CH

objectclass: organization

o: UniversitätBern

 

dn: ou=ThirdFloor,o=Universität Bern,c=CH

objectclass: organizationalunit

ou: ThirdFloor

 

dn: cn=Attila Weyland,ou=Phil. Nat,o=Univesität Bern,c=CH

objectclass: person

cn: Attila Weyland

sn: Weyland

Figure 217: Two directories for two branches.

Figure 2‑18 shows the necessary entry in the directory server of the branch FirstFloor to include (refer) the directory sub tree of branch ThirdFloor into its own:

 

dn: ou=ThirdFloor,o=Universität Bern,c=CH

objectclass: referral

objectclass: extesibleobject

ref: ldaps://ldaps.thirdfloor.universityofbern.ch/ou=ThirdFloor,o=UniversityOfBern,c=CH

Figure 218: Referral entry.

 

The referral entry contains the object class’s referral and extensible object. The attribute ref contains the URL of the referred directory and the distinguished name of the branch to be included. Figure 2‑19 shows an example of a referral lookup. A user enters a search string into the LDAP client, which starts the database lookup in the LDAP server A. The server A has a referral configured and thus links a branch of LDAP server B into its own tree. In this way, server A returns the entry found in LDAP server B to the client.

 

Figure 219: UML sequence diagram for a referral lookup.

Evaluation of the Lightweight Directory Access Protocol

LDAP directory servers exist as open source implementations and may be used for combinations of user and device management functions. With LDAPS exists a secure sockets layer enhanced implementation for encrypted data transport over the Internet. LDAP provides the possibility to operate distributed laboratory portals and resource content servers as well as authentication and authorization of students, tutors, and administrators. Few user account changes and reservation actions take place but many read outs from laboratory portals and resource content servers. LDAP does not scale in cases with multiple linked LDAP directories, as the access policy is set up per data entry and directory, resulting in a high administrational overhead. LDAP directories are adaptable to receive user database entries from other user databases, such as for example from our institution’s user databases or other authentication and authorization infrastructures, called root infrastructure. A root infrastructure is hierarchically on top of the sub or subordinate infrastructure. For example, a countrywide authentication infrastructure acts as the root infrastructure if it adds user accounts to another authentication infrastructure, for example belonging to one of several universities within the country. The terms root and sub have an identical meaning as in the context of public key infrastructures. Consequently, a multifunctional e-learning architecture based on LDAP could become a subordinate system in the framework of a broadly deployed user management system. Table 2‑5 lists the advantages and disadvantages of LDAP:


 

Advantages

Disadvantages

·          Standardized protocol.

·          Broadly deployed.

·          Fits the preconditions for an environment with distributed content providing servers.

·          Possible to integrate a public key infrastructure.

·          Fast readouts optimized database is.

·          LDAP is available as LDAPS, a version that uses SSL-encrypted data transport.

·          Possible to realize a laboratory device reservation system.

·          Possible to refer LDAP directories.

·          Root directories can feed an LDAP directory.

·          The access policy definitions for referred LDAP directories are very complicated and hardly manageable in the case of a large directory.

 

Table 25: Advantages and disadvantages of LDAP.

Evaluation recommendation: As already anticipated in the introduction, we recommend using LDAP for the multifunctional e-learning architecture discussed in Chapter 4 and the extended version in Chapter 5, because authentication, authorization and device reservation functions can be realized, together with the possibility to define user information attributes and to subordinate LDAP to other authentication and authorization infrastructures.

2.4.2   Shibboleth

The name of Internet2’s authentication and authorization infrastructure initiative is project Shibboleth [Shibboleth and CE02]. The term Shibboleth originates from Hebrew. It served to differentiate group members from non-group members by a word, phrase, or habit, only known to querying group. Shibboleth is an authentication and authorization infrastructure architecture for web-based services. Shibboleth is a joint project of Internet2 and the Middleware Architecture Committee for Education (MACE). It aims to develop an architecture for a standards-based vendor-independent web access control infrastructure, which can operate across institutional boundaries. Shibboleth targets at educational use without integrating charging and accounting schemes. Shibboleth provides single sign-on functionality without providing a single log-out mechanism. Shibboleth specifications and software for target site (resource) as well as origin sites (home organization) is freely available. Shibboleth allows federated user administration. In federated user administration, it is possible to delegate the user management to the users’ home organizations, residing in different administrational areas, which administrate and maintain a database with their own users and participate in the authentication and authorization infrastructure. Shibboleth also provides resource access based on user information attributes and active privacy management for users. It uses the simple object access protocol and the security assertion markup language for the message and assertion formats as well as for the protocol bindings. We now define regularly used terms:

 

Assertion

The term assertion in computer sciences defines a declaration about a specific user or object.

Federation

A federation in the context of authentication and authorization infrastructures is a union of autonomous organizations, agreeing in technical and legal aspects to enable user information exchange within the federation and sometimes within different federations also.

Handle

A handle in computer sciences is a unique sequence of data used to identify a certain action or transaction.

Opaque

The adjective opaque describes an object whose content is not visible, be it through an intransparent surface or through encryption.

SOAP in Shibboleth

The Simple Object Access Protocol (SOAP) [CDKM02] is an XML-based framework for web services. SOAP specifies how to encode an HTTP header and an XML file, so that a program in one computer can call a program in another computer and transfer information. SOAP also specifies how the called program can return a response. SOAP is similar to Sun’s Remote Object Invocation (RMI) as with SOAP, a client can invoke a program on a server and get the subsequent response back

SAML in Shibboleth

The Security Assertion Markup Language (SAML) [SAML] is an XML-based framework for web services. A SAML assertion is a statement about a user in the SAML framework. There are three different types: authentication assertions, user information attribute assertions, and authorization decision assertions. Bindings in the SAML framework specify how a SAML request maps into transport protocols, for example into SOAP or HTTP. The Organization for the Advancement of Structured Information Standards (OASIS) [Oasis] security services technical committee developed the security assertions markup language. The security assertions markup language provides interoperability between entities for web access management and especially for providing single sign-on capabilities. In the security assertions markup language environment, users should be able to sign on at one web site and access other security assertions markup language-enabled web sites without having to login again. The user credentials should be transferred automatically from site to site.

 

A Shibboleth-based authentication and authorization infrastructure consists of the following components:

 

  • Shibboleth Indexical Reference Establisher (SHIRE)

The SHIRE is a module loaded into the same web server, which provides the protected resource. The Shibboleth indexical reference establisher intercepts the first HTTP request a user sends to a Shibboleth protected resource and associates it with a handle. Later, the Shibboleth indexical reference establisher provides the Shibboleth Attribute Requestor (SHAR) with the fully qualified domain name of the user’s origin site, together with the location and binding information, necessary to contact the appropriate Attribute Authority (AA) for user information attributes.

  • Where Are You From service (WAYF)

The where are you from service is a service located somewhere in the Internet, used to discover the user's origin site. The where are you from service possesses full information about connected home organizations.

  • Handle Service

The handle service supplements the unique sequence of data issued by the Shibboleth attribute requestor. The attribute handle gets back to the Shibboleth indexical reference establisher only after the respective user has successfully authenticated with its home organization.

  • Authentication System

There is no preliminary authentication method foreseen. Home organizations select their authentication method.

  • Shibboleth Attribute Requestor (SHAR)

The Shibboleth attribute requestor is a module, loaded into the same web server, which provides the protected resource. The Shibboleth attribute requestor receives a user handle from the Shibboleth indexical reference establisher and sends an attribute query message to the attribute authority. The Shibboleth attribute requestor passes the received attributes to the resource manager, which provides them to the protected resource.

  • Attribute Authority

The attribute authority is an origin site component responding to attribute query messages of the Shibboleth attribute requestor. It provides the means for users and administrators to specify their Attribute Release Policy (ARP), acquires and maintains information about SHAR/target associations for the purposes of managing the attribute release policy and enforces the privacy precautions inherent in the attribute release policy. The attribute release policy is a rule set, defining the user information attributes that can be released to a resource.

 

The main parts of Shibboleth and shoes how a user gets a handle to access a resource are depicted in Figure 2‑20. We have slightly adapted Figure 2‑20 and the description, taken from the above-mentioned architecture draft, to our discussion.

 

Figure 220: Shibboleth architecture.

In Shibboleth, users access the web resources with a web browser and are then HTTP-redirected to the respective Shibboleth services and back. The web redirections use the HTTP command 302 “Temporary Redirect”, which was originally invented for the temporary redirection to a resource residing under a different URI. Technically, HTTP-redirections work by putting the temporary URI in the location response header field of a HTTP response. The user’s web browser must then perform a HTTP GET with the received URI. The steps of accessing a Shibboleth protected resource are as follows (Steps 2 to 6 are HTTP browser redirects, happening together with the described actions of step 2 to 6):

 

1)       A user accesses the Shibboleth protected resource B by contacting the URL of the web server, which runs on resource B. The Shibboleth indexical reference establisher intercepts the HTTP request, associating it with a handle suitable for attribute requests by the Shibboleth attribute requestor. The handle is called Attribute Query Handle (AQH).

2)       The Shibboleth indexical reference establisher redirects the user to the where are you from service. The user manually selects his or her home organization in the list, presented by the where are you from (WAYF) service. Passed together with the redirect to the where are you from service are the handle acceptance URL and the user’s initially desired target URL as parameters. The handle acceptance URL is the URL, where the Shibboleth indexical reference establisher expects the attribute query handle from the Handle Service (HS). Parameters are URL encoded with the Uniform Resource Identifier (URI) generic syntax [BFIM98].

3)       The where are you from service redirects the user to the user’s home organization’s handle service together with the Shibboleth indexical reference establisher parameters, effectively acting as a proxy for the Shibboleth indexical reference establisher. The handle service makes sure that the user is authenticated.

4)       The handle service sends back an opaque handle associated with the user’s attribute authority’s location to the Shibboleth indexical reference establisher's "handle acceptance URL" by means of an HTML form posting conforming to the SAML Browser/POST profile [SAMLBind]. The user's desired target URL is passed as an additional parameter. Impersonation countermeasure information is presented as well. The target URL is the URL to which the user's web browser is going to be redirected after the handle has been accepted. The SAML response form element contains a SAML protocol response, wrapped around an authentication assertion, i.e. a base64-encoded XML instance document. The Shibboleth indexical reference establisher, upon reception of the HTTPS request at the handle acceptance URL, examines the in the form of a web browser/POST incoming submission. The Shibboleth indexical reference establisher then sends the extracted user data to another module loaded in the protected resource’s web server, called Shibboleth attribute requestor. The Shibboleth attribute requestor receives the user’s HTTP request URL, method, headers, an attribute query handle, all authority binding information sent by the handle service and the domain name of the organization that issued the handle.

5)       The Shibboleth attribute requestor sends an Attribute Query Message (AQM) to the attribute authority. The query message uses the SAML syntax, embedded in a SOAP header.

6)       The Shibboleth attribute requestor receives an Attribute Response Message (ARM). Upon evaluation of the attribute response message, the Shibboleth attribute requestor sends the acquired attributes on to the resource manager (RM) that writes them into a file and grants or not access to the protected resource, depending on the resource’s Attribute Acceptance Policy (AAP). The attribute acceptance policy is the rule set defining the attributes a resource requires for granting access to a user.

 

Starting with the Shibboleth implementation version 1.3, it is possible to interconnect multiple Shibboleth federations. A Shibboleth federation is a community, which agrees upon certain common issues. In a Shibboleth federation, it is necessary to specify and define typical things such as the user information attributes. It is necessary to define which of the attributes are mandatory or recommended and to specify the format of additional attributes. It is necessary to specify the certificate authorities accepted within and among the federations. Within a federation, it is necessary to organize legal issues as a federation establishes common reliability among all its members and the resources. For the interconnection of different Shibboleth federations, it is necessary to deal with the same issues again, but on an inter-federation level. From a technical point of view, the user information attribute definition and the certificate authority acceptance policy are the most important issues, whereas from the users’ point of view the data protection issues invoked by the transfer of user information across federation borders is the most important issue.

2.4.3   Point of Access to Providers of Information

Point of Access to Providers of Information (PAPI) [CL01] is the authentication and authorization infrastructure mainly used by Spanish libraries. The Spanish national research network provider RedIRIS [Rediris] has developed PAPI. PAPI is a system for providing access control to restricted web-based information resources across the Internet, independent from IP number origin and open for mobile users. It intends to keep authentication as an issue local to the user’s home organization, while leaving full control over the resources to the information providers. The authentication mechanisms allow each home organization to use its own authentication schema, maintaining user privacy, and offering information providers the attributes required for access control decisions. Moreover, access control mechanisms are transparent to the user and compatible with the most commonly employed web browsers, i.e., Mozilla, Netscape, Internet Explorer, Lynx, and any operating system.

A PAPI-based authentication and authorization infrastructure consists of the following components:

 

  • Authentication server

The authentication server authenticates users from their respective home organization. There is no preliminary authentication method foreseen. Home organizations select their authentication method. The authentication server has full knowledge about each user’s rights in the PAPI environment. Users receive list of accessible resources.

  • Point of Access to resources (PoA)

Points of access to resources are the gatekeepers to the PAPI protected resources. They act as a proxy and authenticate each web page request.

 

Figure 2‑21 depicts PAPI’s main parts and shows how a user accesses a PAPI-protected resource. Figure 2‑21 and the description originate from the above-mentioned architecture document. We have slightly adapted both to our discussion. All security assertions are placed into cookies. The single steps described below show the security measures taken in this process. The resource provider grants access based on visitor’s public attributes. PAPI guarantees user privacy by a unique user code and only the respective home organization is able to relate personal information to this code.

 

Figure 221: PAPI architecture.

The steps of accessing a resource are as follows:

 

1)       A user sends his or her authentication data to the respective home organization’s authentication server.

2)       Upon a successful authentication, the authentication server sends back a list of temporarily signed URL of allowed points of access to resources for the respective user. Each URL contains a user code, the authentication server, the expiration time and the sign time.

3)       The user accesses a point of access to resources, which hosts the desired resource. He or she issues a HTTP-request and sends two cookies to the point of access to resources. The first cookie, the Hcookie contains the user code (a unique user identifier), the authentication server, the expiration time and a random block. The second cookie, the Lcookie contains the user code, the authentication server, and the creation time.

4)       The points of access to resources stores the user information contained in the cookies in its database.

5)       The points of access to resources then perform a HTTP-request to the desired resource’s web server.

6)       The resource sends back the web page to the points of access to resources.

7)       New cookies are generated.

8)       The web page together with new H and L cookies are served to the user.

 

2.4.4   Remote Authentication Dial-In User Service

Remote Authentication Dial-In User Service (RADIUS) [Rc00], nowadays also called remote network access security in an open systems environment. It is a system for authenticating and authorizing users in access networks, i.e. telephone networks, cell phone networks, modem pools and in the Internet as well as for providing Point to Point Protocol (PPP) [Sw94] and terminal server access. RADIUS furthermore offers accounting. IETF published the RADIUS Request For Comments (RFC) document in 1997.

RADIUS bases on the client/server model. Clients pass user information to the server and vice-versa. RADIUS servers manage users’ connection requests and authenticate them, return configuration information to the client and execute accounting functions. RADIUS servers can also be the linking unit to other RADIUS servers or other authentication infrastructures. RADIUS traffic is encrypted with a shared secret, never sent over the network.

A user that accesses a network performs the steps shown in Figure 2‑22:

 

1)       A user logs in into a network by providing a user name and a password.

2)       The network access server being the RADIUS client passes the user information to the RADIUS server. The server authenticates the user based on the information stored in the user database and reads out client configuration data as well as authorization information.

3)       The server returns all the configuration parameters to the RADIUS client and the user can access the desired service.

 

Figure 222: RADIUS protected network access.

 

2.4.5   Diameter

Over time, with the growth of the Internet and the introduction of new access technologies, including wireless networks, Digital Subscriber Line (DSL), Mobile IP and Ethernet, routers and network access servers (NAS) have increased in complexity and density, putting new demands on Authentication, Authorization and Accounting (AAA) protocols.

Diameter [CLGZ03] is a response to these new demands. Diameter is a further development of RADIUS. The Diameter base protocol specifies the components each Diameter implementation must include. These specifications include the message format, the message transport mechanism, the error messages, and the security services of the Diameter protocol. The applications are on top of the base protocol.

One of most important enhancements in Diameter is authorization based on user information attributes. Another important enhancement is the simplified collaboration between different administrative domains.

Additionally to RADIUS, Diameter was also enhanced in the following areas: error notification, extensibility through addition of new commands and attribute/value pairs, basic services necessary for applications, such as handling of user sessions.

A user that accesses a network performs the steps shown in Figure 2‑23:

 

1)       A user logs in into a network by providing a user name and a password.

2)       The network access server that is the Diameter client passes the user information to the Diameter server in an authentication and authorization request. The server authenticates the user based on the information stored in the database and reads out client configuration data, as well as authorization information.

3)       The server returns all the configuration parameters in an authentication and authorization response to the Diameter client

4)       The Diameter client sends an accounting message for the user and the respective service to the server.

5)       The server replies with a confirmation message and the accounting phase starts.

6)       When the user terminates the session, the Diameter client sends an accounting termination request to the server.

7)       The server replies with a confirmation message and terminates the accounting session.

 

Figure 223: Diameter protected network access.

2.4.6   Liberty Alliance

The project with the name Liberty Alliance [Wt03 and LH02] started in 2001 and aims to provide open standards for a trust network with an emphasis on commercialization. Liberty Alliance is a response to Microsoft’s Passport infrastructure but based on open standards and implemented into the products of the Liberty Alliance compliant partners. Liberty Alliance provides the necessary technical and legal specifications, required for the interoperation of the infrastructure partners within and among the Liberty Alliance federations. Liberty Alliance does not provide a framework for charging and accounting yet but wants to provide this at a later stage. Liberty Alliance resembles Shibboleth in many aspects and we thus compare the features of both in the discussion of the Liberty Alliance. A main difference is that in Shibboleth users go to resources directly and are then intercepted by Shibboleth, redirected for authentication and access the resource, whereas in Liberty Alliance, users go to a web portal belonging to an identity provider and authenticate first. After authentication, users can federate their account, which means that they authorize their identity provider to share their identity to partners of this identity provider. This resembles customer loyalty programs and emphasis the commercial orientation of the Liberty Alliance. It is well imaginable that an airline maintains such a portal and operates the identity provider. The airline then cooperates with hotels and car rentals. The own customers cannot only federate their identity with these allies but they also get softly pushed to use these services due to two reasons: They find the allied enterprises on the portal of their identity provider, the airline. Moreover, they can easily use their services by federating their accounts. Liberty Alliance like Shibboleth exchanges user identity information through pre-existing protocols and languages. Both use SOAP [BEKL00] for exchanging application data and invoking programs on remote servers. Like Shibboleth, Liberty Alliance also uses the XML subset SAML. Shibboleth and Liberty Alliance use the authentication assertion, stating that a user U was authenticated at time T by means M. Internet2, Shibboleth’s home organization, is a member of the Liberty Alliance. Table 2‑6 compares Shibboleth with Liberty Alliance:


 

Feature

Shibboleth

Liberty Alliance

Target audience

University students, educational use

Paying customers, commercial use

Active privacy management

Yes

Yes

Login and Authentication

Single Sign-On with any authentication method chosen by the home organization

Single Sign-On with any authentication method chosen by the identity provider

Single Sign-Out

No, the authentication cookie’s lifetime determines the session end, no real logout with the resources

Yes, the logout at the identity provider terminates the sessions with the service providers

Protocols for authentication and authorization information exchange

HTTP, XML, SOAP, SAML

HTTP, XML, SOAP, SAML

Fully disclosed architecture specifications

Yes

Yes

Software

Shibboleth issues open source Shibboleth software and provides it for download

No, Liberty Alliance does not implement provide any software. Liberty Alliance compliant partners adapt their products

Identity providers

Universities

Enterprises

Federations (trust circles)

Yes

Yes

Number of federations

One per country

Many, related to identity providers

Federation interoperability

Yes, with technical and legal agreements

Yes, with technical and legal agreements

Benefit for user

Easy resource access in the whole country, flexibility

Easy resource access with all partner resources of the identity provider

Table 26: Comparison of Shibboleth and Liberty Alliance features.

The Liberty Alliance’s goal lies in the design of an architectural framework, which allows developing and delivering specifications, to enable federated network identity management. The Liberty Alliance federated network identity architecture comprises four modules. The slightly modified Figure 2‑24 originates from the Liberty Alliance architecture [LA03]. It depicts the four modules:

 

  • Liberty Identity Federation Framework (ID-FF)

The Liberty identity federation framework is designed to work with heterogeneous platforms and with all kinds of network devices.

  • Liberty Identity Services Interfaces Specifications (ID-SIS)

Liberty Identity services interface specifications are a collection of specifications for interoperable services built on top of modules 1, 2, and 3.

  • Liberty Identity Web Services Framework (ID-WSF)

The Liberty identity web Services framework defines a framework for creating, discovering, and applying identity services built on modules 1 and 2.

  • Adopting and Extending Other Industry Standards

Liberty Alliance's architecture depends on standards and specifications created within OASIS, W3C, and IETF. Module 2 integrates existing industry standards into the architecture.

 

Figure 224: Liberty Alliance architecture.

Figure 2‑25 depicts the UML sequence diagram of the Liberty Alliance mechanisms. A user first authenticates with the identity provider, called home organization in the Shibboleth environment. The user receives an authentication cookie and accesses the web site of a service provider, called resource in Shibboleth. The service provider accepts the authentication cookie and asks for an account federation. With the account federation, the service provider asks the user for the permission to use the user identity residing with the identity provider. The user clears the federation request. He or she is subsequently redirected to the identity provider, in a similar way as it happens in Shibboleth with the Shibboleth indexical reference establisher. The user sends an assertion request in a SAML compliant format to his or her identity provider. The identity provider grants the assertion and the redirects the user back to the service provider. The service provider now requests user information attributes by the attribute provider, which is normally located by the identify provider, in a SOAP/SAML compliant format. The user still has to agree upon the attribute release towards the service provider, similar to the process with the attribute authority found in Shibboleth. After receiving the attributes, the service provider starts the service.

 

Figure 225: UML sequence diagram of the Liberty Alliance mechanisms.

2.4.7   Microsoft Passport

Microsoft .NET Passport [Passport] features one central database where all sensitive system data is stored. Only one company administrates this root server and has access to the stored data of all affiliated organizations. Standards are not open and thus make the system insecure compared to open source systems where the code is freely available and anybody can verify it. Users cannot define their information release policy for each resource they visit. Several severe security issues have been discovered in the past.

The Microsoft Passport architecture comprises three entities:

 

  • Passport Nexus is the name of the root entity. This server stores the configuration information and the mapping data for all participating servers in the Passport environment.
  • Passport servers are the entities that issue passports to their respective users. Users have to register with a Passport server that then stores their user data in a database. Each Passport server provides a cookie to the user’s browser.
  • The Passport manager entity runs at each resource site and reads the user cookies. Passport managers can retrieve additional user information by the respective Passport server.

2.4.8   Evaluation and Comparison of Authentication and Authorization Infrastructures

Shibboleth

Shibboleth allows distributed user management by the respective home organizations and the connection of web-based resources, with a resource access policy fully based on user information attributes. Participating home organizations and resources agree on a common federation policy and use commonly accepted public key certificates for the traffic encryption. Resources do never see user credentials as users always authenticate with their home organizations. Home organizations and users can decide which user information attributes are released to resources and by this, actively influence the authorization process. Resources authorize users by hand of the finally received user information attributes. The user data management is transparent to users and user privacy guaranteed. Organizations joining a Shibboleth implementation have to deploy the origin site installation, which connects their user directory with the infrastructure. Major disadvantages are the missing accounting and charging mechanisms and the not yet fully implemented architecture, which at least now does not provide users with full authority about their user information attributes.

PAPI

The PAPI architecture allows the integration of distributed user management and of distributed content providing resources. User privacy is nevertheless an issue in the PAPI architecture. Authentication servers need to know each resource a user is allowed to access. Particularly when having a large number of resources this cannot scale, as the administrational work would be immense to maintain these lists.

RADIUS

In RADIUS, authorization does not base on user information attributes but on a database, which stores authorization data per user and resource. The maintenance of this database is labor consuming for large user communities with many users and resources. It gets more complicated, if users and resources belong to several organizations and administrational domains. The RADIUS architecture allows having a root server and delegate authority to subordinate servers, such as the domain name service [AL94] does. Nevertheless, this assumes that all involved parties agree with the service policy and with the operators of the involved servers. This is not a realistic scenario, as sensitive user information is visible for many user unrelated parties and it is impossible to guarantee user privacy. Another negative aspect is that users provide credentials to the resources, which operate the RADIUS client, and the resources forward the credentials to the RADIUS servers. Malicious resources can easily catch the user credentials. Another difficulty is the inter-realm connection when it is impossible to connect the realms in tree like schemes, but instead in a way similar to cross certification in public key cryptography.

Diameter

Diameter is an enhancement of RADIUS with interesting new features. Particularly the user information attributes based authorization makes Diameter a promising architecture, although it is not yet clear if users can selectively release user information attributes per resource. User information attributes bring their benefits to users only, if users can selectively control who receives them. Diameter is a very recent development and implementations are rare. Up to now, only few applications exist in the telecommunication industry. Diameter has overcome the drawbacks existing in RADIUS, to this time at least theoretically. As the telecom industry pushes Diameter, implementations in this area will show up in future. We assume that Diameter will reach a higher popularity than RADIUS did.

Liberty Alliance

Liberty Alliance is still in the architectural defining phase and not all the necessary documents for the implementation are ready. Liberty Alliance announced to release the specification documents in mid 2004 but not all the documents were ready. Each Liberty Alliance partner has to implementation the specifications in the own equipment. A finished open source implementation does not yet exist. The principles of the architecture are interesting and make it a serious option for future authentication and authorization networks with accounting support.

Passport

Microsoft’s architecture is an interesting architecture but unfortunately gives too much power to one single enterprise. It is impossible to guarantee user privacy and data protection. This prevents Passport to be a serious candidate for our architectures, although we could implement interfaces towards Passport if necessary in a later phase.

 

Comparison and Recommendations

The features of each of the six evaluated secure data transport technologies are condensed and compared in Table 2‑7. Features provided are marked as X, features provided under certain conditions as (X):


 

 

Shibboleth

PAPI

RADIUS

Diameter

Liberty Alliance

Passport

User information attribute-based authorization

X

 

 

X

X

 

Easy inclusion of organizations possessing a user database

X

X

X

X

X

X

Multi domain interoperability natively supported.

X

X

 

X

X

 

Authentication remains with users’ home organizations.

X

X

 

 

X

 

Open source based

X

X

X

X

X

 

User privacy guaranteed

X

X

 

X

X

 

Allows integration of a public key infrastructure.

X

X

 

X

X

 

Accounting supported

 

 

X

X

X

X

Federated user management

X

X

 

X

X

 

Deployed

X

X

X

(X)

 

X

Supported by telecom industry

 

 

X

X