Managing login account creation with the World Wide Web

Introduction

A solution was needed! At the end of November, 1994, I volunteered to produce a solution using WWW technology. This paper describes the design, implementation and initial appraisal of this solution.

System Requirements

• A student would have a single login name, to be used on all systems. This login name would be permanently allocated to the student - in the same way that their student ID was.
• IT support staff should be able to create login accounts on any system, located on any campus, with a minimum of effort.
• The system needed to enforce security so that only authorised people could access it.
• The system would have to use existing resources; there was no budget.

System Design

• World Wide Web software is multi-platform and freely available.
• The combination of HTML forms and CGI scripts is extremely flexible.
• The store-and-forward capabilities of electronic mail allows asynchronous operation of the system.
• Documentation for the system could be easily built in.
• The university is in the early stages of adopting WWW technology in a major way and this project will serve as a good trial of one of the technology's capabilities.

Message Protocol

1. Add User

   This message requests the creation of a new account on the system. If the account already exists on the system it is ignored.The format of the message is AU:Login:Name:Password:Groups where:

   • AU indicates Add User.
   • Login is the login name.
   • Name is the name of the account holder.
   • Password is the initial password for the account.
   • Groups is a comma-separated list of groups which correspond to units that the student is enrolled in. If a group does not exist on a system, it is ignored.

   Note that for Add User messages sent to the modem pool, information about units is dropped and the message modified to AU:Login:Name:Password:Type where:
   • Type is either U (undergraduate), P (postgraduate), or S (staff). The distinction is required because undergraduate students use a modem pool number different to the one used by staff and postgraduate students (postgraduate students are considered equivalent to staff).

   This divergence occurred because of the late addition of the modem pool to the account creation system. The two message formats will eventually be blended into a single message format.

2. Remove User

   This message requests the removal of an existing account from the system. The format of the message is RU:Login where:

   • RU indicates Remove User.
   • Login is the login name.

3. Add Group

   This message requests the addition of an existing account to the specified group. The format of the message is AG:Login:Group where:

   • AG indicates Add Group.
   • Login is the login name.
   • Group is the group name, which corresponds to a unit code.

4. Remove Group

   This message requests the removal of an existing account from the specified group. The format of the message is RG:Login:Group where:

   • RG indicates Remove Group.
   • Login is the login name.
   • Group is the group name, which corresponds to a unit code.

Account Creation Process

1. Student Accounts

   The login account creation process for students occurs as follows:

   1. A student completes and signs a login account application form. This is necessary since the student must agree to abide by the rules of computer use within the university.
   2. The form is then submitted to a campus IT support officer who uses a HTML form to enter the student's ID number, plus select the systems on which the login account is to be created.
   3. The form is submitted to a CGI script which searches a database of students for the ID number. If found, the script returns another HTML form displaying:
      • The student's ID number.
      • Their full name.
      • Their login name and initial password.
      • Units they were enrolled in, and
      • The systems selected for account creation. This has been structured so that every student that applies for an account on any system will automatically be given an account on the modem pool.
   4. If the displayed information corresponds to that on the application form, the IT support officer prints a copy of the form for the student, then submits it to another CGI script which appends an Add User command to account creation files for each system selected for account creation.
   5. At hourly intervals, a script on the HTTP server system emails the contents of each system's account creation file to a nominated email address on the system. A server process on that system then creates the actual account.

2. Staff Accounts

   The account creation process for staff occurs as follows:

   1. A staff member provides a campus IT support officer with their staff ID number, name and their university email alias.
   2. The IT support officer then enters the staff ID and email alias into a HTML form and submits it to a CGI script. If the staff ID is found in the staff database and they are currently employed and the specified email alias exists, another HTML form is returned displaying:
      • The staff ID number.
      • The staff member's name.
      • Their login name.
      • Their initial password.
   3. If the displayed information is correct, the IT support officer submits the form to another CGI script which appends an Add User command to the modem pool account creation file. Details of the staff member's login ID and initial password are automatically e-mailed to their email alias. The form can also be printed for the staff member if required.
   4. At hourly intervals, a script on the HTTP server system emails the contents of the account creation file to the modem pool. A server process on that system then creates the actual account.

Implementation

The implementation process has required the development of:

1. Scripts for the construction and maintenance of student and staff databases.
2. HTML documents and forms for data entry. To access a demonstration of these, click here
3. CGI scripts to process the HTML forms.
4. A script to mail the account creation requests to the systems on which accounts are to be created.
5. Scripts to run on the systems on which accounts are to be created. These process the messages e-mailed from the HTML server. Implementation of these scripts has been left to the relevant system administrators. A description of the NLM developed for the Novell NetWare servers can be seen here.
6. Security strategies to minimise the risk of unauthorised people using the system to create accounts.

System Evaluation

Positive aspects of the system include:

1. The system has streamlined the process of creating login accounts and reduced the amount of data entry required from IT support officers and other system administrators.
2. The ability to quickly make changes when problems arise or enhancements are required has proven to be an asset. This particularly applies to the HTML forms and the online documentation.
3. The asynchronous nature of the system, enabling parts of it to be taken down without impacting other parts, has been very useful for dealing with initial scripting problems on both the HTTP server and the target systems.

1. The browser used (Netscape):
   • There is no accelerator key for printing which means that the user has to open the File menu and select Print in order to print login details for the student or staff member.
   • When a form is displayed, the cursor is not automatically placed in the field. This means that the operator has to click with the mouse before typing. Even if pressing the Tab key would move the cursor there, it would be a great improvement.
2. The HTML specification:
   • A nice addition to the specification would be the ability to enable hot keys within field labels. This would allow the keyboard to be used for all data entry on the form. On the whole, having to move between keyboard and mouse often whilst filling out a form is not a good thing.
3. Maintaining the databases.
   • Whilst this has now been largely automated there is still the need to ensure regular updates. However, I think it is a worthwhile compromise. Whilst the ability to directly link CGI scripts to the university's central SQL databases has some technical appeal, the response rate would be too slow. By having dedicated databases for the system, the operators are attaining very fast responses to queries. This is very important if you have large numbers of accounts to create.
   • It has become apparent that there are categories of login accounts where the person does not appear in either database. People falling into these categories include:
     • Students from other teaching institutions who have been given permission to use the university's facilities.
     • Students taking part in community extension courses.
     • Visiting fellows.
     A present, these people are being dealt with manually but I hope to be able to extend the system to cater for them.

Conclusion

What has contributed to this success has been the ease with which the World Wide Web can be used for application development. Whilst the tools available for creating HTML forms are only just becoming really "user friendly", once you know HTML it is not difficult to knock up a form very quickly.

CGI scripting can be as difficult and complex as you want to make it. TCL has proven to be easy to learn and adequate to the task although for more complex tasks other languages may be a better solution.

Importantly, however, the system has demonstrated potential for expansion to both:

• Increase the number of systems for which account creation can be handled, and
• Be applied to other applications of a like nature.

Copyright