Abstract

At EUNIS-97 we presented the Ping- system as a public interface to the Swedish University admission system using WWW-technology and smart cards" Through 1998 , we have developed and tested the system and it is currently under installation within the LADOK-consortium. (Information about LADOK see http://Error! Bookmark not defined.)

The original paper was presented with the name " Ping: an electronic interface for the Swedish universities" and is available at Error! Bookmark not defined.. At EUNIS-99 we present Ping as a multi-tier product which allows users an easy and secure access to a large administrative system and makes the coordination of student records from many universities possible.

Background

During the 90’s, we have seen an increasing need both to coordinate student records and to let students use the Internet to interact with the system. Ping has both the ambition of being one of many answers to the economic necessity of rationalization of the admission process, as well as trying to respond to students expectations of Internet-based services. In the change of paradigm from a Paper-based to an Internet-based admission system that’s taking place we think that Ping can serve a useful purpose.

Short description of LADOK

LADOK is a computer based student admission and documentation system for a university or university college. It focuses on administration of undergraduate and graduate students. The system is locally deployed and managed by the institutions.

The LADOK system has a mutual core, identical for all LADOK system installations in Sweden. The core consists of a structure of database tables, computer programs and terminal screen routines. Every institution decides what parts of the core to be used at the institution and it is also possible to use locally developed addendum's. The LADOK-system can therefore be viewed upon as a large "smorgasbord" where the institution can choose which parts to use.

The LADOK-system consists of two major parts, the admission system and the documentation system. They are integrated and share data, e.g. name, address and other facts about applicants and students. A third part, handling documentation of graduate students, is newly added to the LADOK system core. Undergraduate studies are handled within two major concepts, courses and study programs. The first has its focus on students and single courses and the second of students following a specified study program, normally 3- 4 years study.

The system files contain information for student identification, general eligibility for university studies, admission to courses and study programs, registration on courses per semester, course data, credit points from courses, awarded degrees and international studies.

The LADOK system mainly focuses on student admission and documentation, planning and follow-up. The system is designed to be used by all Swedish state financed institutions of higher education and has its focus on the departmental level. Users of the LADOK system at an institution can be found at all levels:

university board and administration

faculty or school heads

departments

students

Data from LADOK are exported to the ministry of education and other agencies for follow-up purposes. An important objective of LADOK is to prepare the annual invoice to the government for studies on the undergraduate level at an institution.

The LADOK system is owned by a consortium of 49 institutions in higher education in Sweden. Software maintenance for the LADOK system core is conducted by a maintenance group at the University of Umeå. Local system usage is the responsibility of the institution, who pays for servers, networking, terminal equipment and local support.

The system is currently facing a major revision that aims for easier user interface and new functionality including a strong focus on security issues. Today, the system is used by approx. 2.000 simultaneously on-line users but it has to be prepared for a large growth in number of users inside institutions and, of course, there are more than 300.000 students waiting for better service with WWW, touch-tone telephone systems and explicit student applications.

Short description of the Ping-system

In this section we aim to describe the Ping-System as a highly modularized system where the functionality of a transaction is expressed at the "front" (in the client-application) and at the "back" (in the database interface).

The Ping-system is based on the following components.
1. A Java1.1.6 based client

2. An Authentication Server that can authenticate/log calling users, universities and transactions .

3. A Transaction Handler that distribute transactions to different universities and return results.

4. A Database interface where each transaction is expressed as a stand-alone component.

Changes from -97

In our paper to EUNIS-97 we had the ambition to focus more on security using smart-cards. Smart-cards has not gained ground in Sweden at the pace we anticipated. Today, we see no obvious economic alternative in the area of smart-cards. Also, we see no major changes in the infrastructure from –97 that would indicate that we are closer to a "grand scale" solution.

A View of the system

In the following sections we will present the different components more in detail. Graphically the system can be illustrated like this:

In the figure above we see 1) the client application that loads into a web-page using either normal or secure http-protocol. The next step is that the client contacts its Authentication-Server using TCP/IP protocol. 2) Ping uses DES and RSA-encryption to ensure a secure connection and a user can log on to the system using one of several authentication schemes. 3). When a logon has been performed certain services are loaded to the Java-applet depending on the users category. When a transaction has been sent from the client, it is authenticated by the Authentication Server and sent 4) to the Transaction Handler. Depending on the configuration in the Authentication Server the transaction is sent to the systems own database 5) or in parallel to the systems of other universities 6). To be noted is that a: all components communicate with each other using the same protocol and b: all components use threads which means that performance is more or less the same no matter how many universities that are connected to the system.

Modules

In the following sections we will describe the modules outlined above in a little more detail. We save some of the more technical issues to a special section.

The Client-program

The entire client is designed as a Java-Applet. When the user is logged on he/she is given a series of services presented as tabs. (shown below)

When the user clicks on a tab a transaction is sent to the Authentication Server and the result is presented as one or more sub-tabs. One sub-tab is shown for each university that is being called and one help-tab (Hjälp) that is always shown. Above we see "Course results" for a student at the Royal Institute of Technology" in Stockholm. Some transactions require input, in those cases the tab is shown to the user to enable input and the tab has an "OK" button. For non-complex transactions the only actual coding that has to be done is to design the tab and to separate the answers to designated data-fields.

The Authentification-server

The Authentication Server is the real heart in the system, it authenticates users as described above and transactions using a configuration file, so adding a new transaction doesn’t mean that a lot of programming has to be done at this stage in the process either. In the configuration file we have extensive possibilities to filter out unwanted communication and unwanted transactions.

The system also uses a second file with public RSA-keys and a third containing secret keys and the password used to encrypt the communication between Authentication Server and Transaction Handler. The Authentication Server can use several authentication schemes, (see separate section) and has a built-in scheduler for reoccurring tasks. Examples of these are; checking clients for idle-timeouts, checking for the presence of other Authentication Servers and doing system checkup. The Authentication Server has two log-files, for ordinary traffic and errors but if it from any reason becomes worried it can always send a mail to its operator. The system has an administrative user who can (using the same user interface) start and stop the system and gather statistic data from the log files.

The Transaction-handler

The Transaction Handler has a much simpler task at hand then the Authentication Server. It accepts input from only one address, and uses the same technique as the Authentication Server to distribute the transaction to available universities. Unwanted attempts of access is logged and the system can always alert its operator if it finds itself under attack. Ping uses the transaction number to find out which software component to execute and has access to the same configuration files as the Authentication Server.

The Database-interface

When we designed Ping we wanted to build the system as modular as possible, one of the choices that we made was to use UNIFACE to build components to interface the to the database. This has enabled us to add or change transactions to the system without making changes in any other component of the system.

Authentification schemes

Today Ping has three different authentication schemes. When the Authentication Server is started the command-line parameter "aut_sys" is set to the values "standard", "CATS" or "extra". "Standard" is a local database with user-id and passwords in a traditional style. The only things that we have added is entry and expire-date plus user-category. "CATS" is an acronym for Central AuthenTication Server. This server is the result of a very recent cooperation between the Ladok-unit and the national Post office which want to develop a national authentication service for all Swedish students.

The purpose of the system is to facilitate the student’s change of address using a internet based system. This work is very interesting but has not yet been incorporated in the other Ladok-products. "Extra" means that the local installation uses an authentication system of their own choice. This way we feel that we have "all bases covered".

Functionality

Today Ping has functionality to provide basic student access to a local LADOK installation and can present results to a student using a secure connection. We also have a possibility for the student to extract transcripts from the system. The transcripts have an electronic seal printed on them and can be verified by anyone using Internet. On a special web-page one would input the students personal-id plus the seal and then the original document can be retrieved from the database.

For an admission officer, Ping can provide data about a person in a coordinated way so that a complete picture of all results from all connected universities are shown, which we will show in the examples below. Ping can also be used to gather basic information about a student to present a more complete picture before the admission process starts.

The CATS-system is expected to start on May 1:st and it is supposed to contain at least 300 000 students at that point. At that time Ping with CATS will be a strong system for delivering data to students.

Some Technical issues

In this paper we have talked about an Authentication Server and a Transaction Handler. Actually these two components are the same program. They are just started with different parameters and perform different tasks. The system uses threads for maximum performance and the average time for a transaction is well below a second. Actually almost all of the time-consuming work is being performed in the Java-client.

The system is developed in ANSI C on Windows NT but all components can run on the Unix- flavors of HP, SUN- and DEC-. This is with the exception of the authentication scheme "Standard" which is NT-specific. The java-applet is not compulsory, a html client with forms can be used, but then we will have to use a "helper-program" on the server instead. The database interface can be replaced by any kind of components.

Level of installation

At EUNIS –98 in Prague Ulrich Kammerer held a much appreciated presentation concerning "Islands, Volcanoes and Dinosaurs". We have had to deal with much of similar problems during the year of –98. Unfortunately we have not been able to install the system in as many universities as we have wanted, but at the present day (99-03-14) the system is installed in eleven universities and by the time of the presentation we hope that the number is significantly higher. Also, there has been problems in the final testing of the system. Testing a distributed system such as Ping has led us to some interesting (and hopefully unique) situations.

Examples

In this section we will show some examples of what the system looks like. Hopefully it will also illustrate some of the issues discussed in the section "The Client Program" We illustrate the system with a number of tabs developed for the National Bureau of Loans and Grants.
 

The java-Client has been loaded and the user can log on	A number of personal-id number has been fed to the system which is ready to start a search

Ping shows which universities that have results for the different persons	We choose one person and examine her results. (from two universities)
Ping can report its system settings	Course results for a Student

Summary / Future plans

In this paper we have presented the Ping-System as a generic system to give a large number of users safe access to a large administrative system. To develop transactions all that has to be done is to develop the front and back-end. Ping will handle the rest.

During the spring of –99 we hope that we will have a national acceptance of Ping as an instrument for coordinating the different LADOK-databases. There are still battles to fight and victories to win. However we feel confident that time is in our favor.

The LADOK consortium has not yet discussed the possibility of licensing the software to other countries, but as I see it, there are some extremely interesting tasks that lie ahead, some of them can be approached with Ping.