Home | Search | Demo | News | Feedback | Members Only
Ross MacIntyre, Manchester Computing, University of Manchester
SuperJournal Technical Report SJMC240
1. Purpose of the Report
4. Solutions Considered
5. Solution Selected
6. Technical Implementation
7. Problems and Issues
Appendix A Registration Screen
Appendix B Login Screen
Appendix C Library Class
Appendix D Person and User Classes
The subject of access is a common issue of concern to all service providers. There is the familiar dichotomy of accessibility versus eligibility, i.e. the application should be easily available to those who are eligible, but not available to those who are not.
The definition of an appropriate access mechanism for the SuperJournal application involved the traditional steps of identifying requirements, proposing options and identifying the "best fit" against the stated requirements.
This report lists the identified requirements and describes the process used to establish an acceptable solution. The chosen solution is documented together with the underlying technical processes involved. Issues are noted, some existing from the start, others have arisen during the two years the mechanism has been in successful operation.
The project has required personal identification, so the provision of access to an indistinct audience is not considered.
In developing a list of requirements for registration and login, the project looked at the individual requirements of the various participants: the libraries, the publishers, and HUSAT who would conduct the evaluation studies.
In Spring 1996 the project visited the first eight university test sites. Each of the libraries wanted to know how the project would enable access for users, both within the library and from their departments. They expressed requirements from their point of view:
From the publishers' point of view, the system should ensure that access was limited to authorised users at the test sites. From HUSAT's point of view, we needed to identify individual users, both to measure their use and to contact them so we could understand their use.
Manchester Computing looked at the technical options and then developed a consolidated list of requirements:
Libraries wanted the mechanism to fit with existing practices used in supporting other online services. This could mean institution-wide usernames/passwords, e.g. as then used for IOPP, IDEAL or departmental usernames/passwords, e.g. as for BIDS, or some other variation.
Firstly, in order to adequately monitor the use made of the system and its variable features it was essential that each user could be recognised. IP address recording just recognises a computer; not who is using it. This may be acceptable for an academic with a PC in their room, but is not in the case of general access machines such as in open clusters and in libraries.
Secondly, the application was to support persistent preference settings for users, e.g. if they prefer a particular search engine, they can register this preference so it is used for all future sessions. In order for this to be supported, particular individuals need to be recognised.
The project needed people to actually use the system, so it would be counter productive to have established a user-hostile mechanism that, in itself, put people off. It was acknowledged that any visible authentication mechanism was a barrier, so the requirement was to minimise it, rather eliminate it completely.
If individual passwords were to be issued, the user should be able to subsequently change it, rather than have to stick with the one originally allocated. (The imposition of passwords was fairly common in 1996 when the requirements were being established.)
A bona-fide user should be able to access the service from anywhere they choose: workplace, home, while visiting another site, and possibly abroad.
There needed to be some mechanism to confirm that a user was associated with a particular participating institution. Otherwise the material would be accessible beyond its intended audience. This would go against the formal agreement with the participating Publishers.
For the purposes of making an initial decision, Manchester prepared a document detailing some possible options for access control. An assessment was then made on the implications for the following groups: end users, the libraries, Manchester Computing, HUSAT and the publishers.
The list was not exhaustive and many additional methods/derivatives were possible. Problems associated with correctly establishing network addresses when caching may be in use were not resolved.
Both "Validated" and "Non-validated" access mechanisms were considered and matched against the requirements stated above.
"Non-validated" access included: free access via a link from the SuperJournal Web site, a "secret URL" issued to users, a login where the user declares who they are, but with no check. None of these options were suitable. Though the administration burden would be low, use could easily spread outside the intended audience. Additionally, monitoring use would be patchy at best, as it would be difficult to identify consistently and continuously who was doing what; impossible for certain options.
"Validated" access included: institution-wide username(s) and password(s), individual username and password, IP address checking and combinations of each. Institution-wide username & password could be used to confirm eligibility, but does not identify an individual. Also, without a network check of some kind, use could spread beyond the intended audience. Issuing and maintaining individual username & password lists can be onerous, this was counter to a key requirement. IP address checking alone would not identify an individual and it is not possible to guarantee correct identification. Restrictions would constrain the user to pre-declared locations, counter to one of the requirements.
It was clear that some kind of combined solution would be required. In particular, the identification of a user via their email address was seen as desirable.
The process of initial registration and subsequent access were clearly distinguished, reflecting the differing requirements. Registration is primarily concerned with checking a person's eligibility and gathering base data. Subsequent access focuses on gathering actual usage data, having established who the user is.
The following solution was derived, discussed with project participants and accepted:
The email address was selected as an identifier as it is unique, possessed by (virtually) all of the target population, sufficiently non-volatile and easier for users to remember. However, it is essentially "public property" so a Personal Identifier (PID) can also be supplied.
The Library Username, Library Password and network address are checked against those stored. The data is confirmed with the user and an initial database session started. Any problems concerning undeclared network addresses can be resolved via a proxy registration, typically by relevant library, but also by the project team at Manchester Computing.
The following documents the implementation of the mechanism and contains additional technical information.
The implementation at a particular site started with an on-site technical visit, during which the Library supplied their chosen Library Username(s) and Library Password(s) together with declared network domain names (e.g. *.man.ac.uk) and ranges of IP addresses (e.g. 130.88.201.*) which were to be regarded as "valid" physical locations associated with the institution
Most libraries opted for a single Library Username and Password (though there were exceptions, see to Section 7).
Additionally, a Web-accessible script was written, with access suitably restricted, that enabled the Project Manager to keep track of registrations, e.g. how many users were registering, at which institutions, etc.
The main SuperJournal screen contains links to the Registration screen, which is produced by a script (PERL). The script firstly checks whether the service is running before outputting the HTML form. If the service is down, for some reason, the person is informed. This step avoids the situation where a person takes some time to fill in all their details, and then receives a failure message on submission.
The user accesses the registration screen and the following data is required:
Library Username (mandatory)
Library Password (mandatory)
Chosen Personal Identifier
Status (options: Academic Staff, Research Staff, Postgraduate Student, Undergraduate Student, Library Staff, or Other
Email Address (mandatory)
Postal Address, including University Faculty or Department
The following processing is done using a lower case version of the data entered (but the data is still stored as entered).
The objectbase (ODB-II) is accessed to check whether the email address already exists, to identify duplicate registrations. If so, it will error with an appropriate message. Similarly if the email address field has not been entered.
The syntax of the email field is checked as far as is possible. Non-alphanumeric characters, e.g. ";", "<", ">", "&", "*", "|", "$", are rejected, except for ".", "\", "'", "-". It is also checked that there is one, and only one, "@" in the email address.
The Library Username submitted is checked, together with the Library Password and pre-declared network address(es). The network address that is received within the HTTP header is actually specified in 2 ways: as a server name (REMOTE_HOST), e.g. rmac.man.ac.uk, which (seemingly) comes from a Manchester University server and an IP address (REMOTE_ADDR), e.g. 18.104.22.168. Also, the server name is not always specified, it may also contain the numeric value. A check is done on both fields.
This is not a highly secure check, but is sufficient for the purposes of the research project. IP-based restrictions are not entirely foolproof because of "IP spoofing", but mounting an IP spoofing attack requires considerable expertise and the contents of the SuperJournal application are unlikely to merit such attention. The data records held for Libraries can be found in Appendix C.
A new User object is created (see Appendix D) containing all properties entered via the registration screen, together with default values for other properties that will be used to record and support personal preferences within the application:
username; (=email address)
timeOut (default: 7200; unit =seconds);
searchEngine (default:"No Preference");
preferedCluster (default:"SuperJournal Clusters");
startScreen (default:"SuperJournal Clusters");
homePage (default:"SuperJournal Clusters");
set ccsNotifyNewIssue (default:EMPTY);
set mgpNotifyNewIssue (default:EMPTY);
set psNotifyNewIssue (default:EMPTY);
set ppNotifyNewIssue (default:EMPTY);
set preferedReading (default:EMPTY);
A confirmation screen is then displayed to the user, confirming their email address and personal identifier, if chosen. Once confirmed, the same details are also sent via email for later use, and the new User object is "committed", i.e. made permanent. Any "bounced" emails sent by the system are caught and notified to the Library contact at the relevant institution, assuming it can be identified.
The SuperJournal Login Screen requests the user to enter:
The objectbase is accessed to locate the specific User object using the entered email address as the primary key. Once found, if a PID has been stored and entered, this is validated. The PID is not treated as a password, e.g. it does not have to be over a particular length, consist of numeric, alphabetic and non-alphanumeric characters, and it is not case sensitive.
Any personal preferences recorded that affect the behaviour of the application are then actioned, e.g. start screen or home page.
The user can use the Preferences page to amend either their Email or PID. There is the familiar requirement to enter the new email address twice for validation purposes.
The following types of problems and issues were encountered during the period of operation.
The largest class of problem, generating the largest number of emails to the SuperJournal admin account, was people setting a personal identifier then subsequently forgetting what it was. People also mistyped their PIDs on occasion.
As noted above, the only mandatory fields were Library Username, Library Password and email address. Some users chose not to fill in the optional fields, e.g. name, department, status, etc.
To assist in the evaluation, the classification of "types" of user was to be done by the user at the point of registration. The initial definition of types was too prescriptive, leading people to choose the status "Other" and entering something like their job title. Once recognised, the status fields were reduced to: Academic Staff, Research Staff, Postgraduate Student, Undergraduate Student, Library Staff, and Other.
Certain institutions do not supply email accounts to all members as a matter of course. This did not prevent people from using the system, nor did it stop the person being identifiable for potential evaluation follow-up.
A very small number of individuals supplied email addresses that they must have known to be invalid. It seems most likely that they were seeking to avoid "spamming" rather than hiding their identity, as they supplied name and address, etc.
There have been very few examples of deliberate "mickey-taking". The most considered being: Chief Rabbi, Professor, the Lord, John Smith, Postgraduate, Address: Golf Club Drive.
One library supplied a file containing all individual IP addresses, i.e. a potential address for every machine on file at the time. This was at too low a level of detail and would have been very difficult to keep two lists in sync.
Periodic checks were done on the list of registered users. This was only accessible from specific machines in Manchester Computing, HUSAT and Project Manager.
One library required two Library Passwords after they issued a general email quoting a different Password than they had requested initially. The first had already been communicated to some users and used for some existing registrations.
One library chose both types of Username: one institution-wide, and several reflecting the familiar username/password combinations used to access BIDS.
One library changed their minds, but the initial Library Username and Password had not been publicised outside the library.
Overall, the scheme worked as planned with no real problems.
Libraries had different approaches to the implementation at their sites, but the scheme proved flexible, and didn't cause too much additional administration. Those few libraries that chose to support both institution-wide and departmental Usernames correctly surmised that people would use both.
There was negligible need to register on people's behalf. Manchester Computing were able to support some off-site registrations, and of course supplied forgotten PIDs routinely.
The Project Manager used the Web-accessible script on a regular basis to monitor registration. This had not been planned for when identifying initial requirements.
The user's username (email address) was used as the identifier in all logging activity, which had the fortunate side effect of making the usage files easier to look at. In particular, one abuse of the application, where a person must have made their registered email and PID known to others at a number of sites in the USA, was quickly spotted and dealt with.
As expected, a person's email address proved satisfactory as a username, since it fulfilled the following criteria: familiar, in regular use, not excessively volatile, and typing errors are quite evident, as it is "readable".
The additional supply of a PID was high. It was also evident that people were supplying either some simple derivative of their name, or using another "true" password which was presumably familiar to them. The treatment of a PID as a non-password would not be acceptable in a commercial environment, as it could be intercepted and used by an unauthorised user.
A Registration Screen
B Login Screen
C Library Class
D Person and User Classes
String shortName default:"Library";
String set servernames default:EMPTY;
String set servers_num default:EMPTY;
Boolean includes(String domain, String number);
The Class User inherits a number of properties from class Person.
String unmangleSessionKey(String Mangle, String Oid);
String searchEngine default:"No Preference";
String preferedCluster default:"SuperJournal Clusters";
String startScreen default:"SuperJournal Clusters";
String homePage default:"SuperJournal Clusters";
String set ccsNotifyNewIssue default:EMPTY;
String set mgpNotifyNewIssue default:EMPTY;
String set psNotifyNewIssue default:EMPTY;
String set ppNotifyNewIssue default:EMPTY;
Article set preferedReading default:EMPTY;
String mangleSessionKey(String SessKey, String Oid);
Boolean setPassword(String Password);
Boolean setUserName(String username);
Boolean contains(CFmedia::User user);
This web site is maintained by firstname.lastname@example.org
Last modified: May 07, 1999