The User Management System

General Project Requirements

The Great Plains Free-Net Inc., based in Regina Saskatchewan, is a non-profit, volunteer-driven corporation dedicated to providing low and no-cost internet connectivity to residents, community groups and organizations that are not sufficiently served by commercial Internet Service Providers (ISPs).

In particular, the Great Plains Free-Net caters to individuals:

whose personal computers are too old or antiquated to run current generation web-browsers and other internet client software;
who want a text only user interface to a graphical user interface because of personal preference or disability;
who are new to the Internet environment and who need more “hand-holding” and support that commercial ISPs are prepared to offer; or
who are not heavy users of the Internet and who do not require the unlimited or generous usage offers characteristic of many commercial offerings.

For community groups, the Great Plains Free-Net offers:

no and low cost web hosting to community groups seeking to inform the public of their services and programs;
e-mail list services to cyber-communities for whom face-to-face meetings are unrealistic;
Database hosting services for dynamic web content; and
Virtual domain hosting on a cost-recovery basis for community groups, individuals and organizations that wish to pay for this service.

Because of the mix of products and services offered to the public, the Great Plains Free-Net (GPFN) needs a User Management System (UMS) to manage its user base. As GPFN is volunteer driven, this system needs to be managed remotely by volunteers. As GPFN exclusively uses a Linux server base, any new system should be implemented in a Linux environment and be Internet and Web enabled.

In general, the UMS needs to provide the following functions:

Allow users and prospective users to use the Web to apply for a new user account;
Allow existing users to apply to upgrade their account to include new services or increased quotas;
Allow GPFN volunteers to approve or reject applications for new accounts or account upgrades and, if approved, effect the necessary changes to the system;
Allow users some access to their own system configuration such as changing their password, reviewing their account history, changing mail forwarding settings, and possibly adjusting spam filters;
Allow GPFN volunteers access to change the configuration parameters listed in function (4) above for any GPFN user;
The GPFN charges for memberships and other services based on a calendar year. The system must support a “renewal cycle” whereby all existing GPFN users are asked to explicitly renew their account. This renewal is validated by responding to an e-mail notification (in the case of free accounts), or by remitting a cheque for any memberships or service fees. This renewal cycle is generated through a scheduled task (or “cron job”) or via a GPFN volunteer’s explicit action;
The renewal cycle must not generate renewals for accounts which are not in arrears and must be able to generate a paper invoice or statement upon request;
The system must allow GPFN volunteers to process receipts against outstanding renewal requests so that user accounts are not again flagged for renewal notification during the current renewal or billing cycle;
The system must allow GPFN volunteers to expire or suspend accounts for any reason such as a user misusing their account or not responding to a renewal request. If a user remedies the reason for the suspension, the system must allow a GPFN volunteer to reinstate a previously suspended account. Alternatively, the system must also allow GPFN volunteers to delete any account previously expired;
In order to support expirations due to non-renewal, the system must be able to offer a “batch mode” whereby all non-renewed accounts are listed and expired together. Similarly, once a decision is made to delete accounts, the option should exist to allow a volunteer to delete all expired accounts as a batch process;
The system must maintain a history of the financial transactions against an account including the date and method by which a renewal notification was sent (either e-mail or printing), and the date and method by which a payment was received (cheque, cash, donation in kind, or credit card);
For audit purposes, the system must track the GPFN volunteer who performed any action.

Project Justification

To date, GPFN has used a software package called Chebucto Suite to perform all User Management functions. The Chebucto Community Network in Halifax, Nova Scotia wrote Chebucto Suite (or Csuite). It uses a collection of about 300 shell scripts and a series of flat file datastores to manage all aspects of a user’s account on the system. Because of the changing nature of the Internet market space, Csuite development is now halted as is system support and maintenance.

Csuite assumes that all users will interact with the system using the Csuite shell or “Cshell”. This Cshell is a restricted, custom compiled version of a lynx web browser. Lynx is a text-only web browser that renders HTML pages without displaying any graphics. The Csuite version of Lynx allows users to use keystrokes to branch off into a file editor, a mail reader (pine), as well as manage or review aspects of their user.

Csuite was written for RedHat Linux 4.1. GPFN is planning to upgrade to RedHat Linux 7.2 for its new server. A number of security concerns, new features, and system libraries predicate the need for this upgrade. However, in initial examination of the Csuite package, it is likely that any attempt to migrate Csuite to this new Linux platform would necessitate a line-by-line review of the existing Csuite code. Such a review would be very costly in terms of volunteer personnel resources and would be very specialized work. As well, GPFN did not use some Csuite features while Csuite could not support other desired features.

At the same time, new technology in existence since Csuite was initially developed means that the backend datastores can use a complete Relational Database System (RDBS) such as MySQL. The application logic can use newer more capable implementation languages. This combination of a RDBS and new implementation languages will result in a robust system that is more flexible to the business needs of GPFN and will require less development effort than that required for the rewrite of Csuite.

Business Case

GPFN is embarking on a comprehensive modernization strategy. As part of this strategy, GPFN is offering a number of new services and adopting a more member-centric philosophy. One problem with the existing system is that very few volunteers understand or can manage Csuite. Therefore member inquiries, problems or complaints often took a number of days to resolve. This delay resulted in member and volunteer frustration. At the same time, the Csuite package was hard-coded in terms of services and member categories, resulting in a collection of ad-hoc systems, databases and other methods to manage services and membership classes specific to GPFN.

While GPFN wants to maintain the Cshell for use by members and users who have older equipment, a growing number of members do not use Cshell. These members often use GPFN’s PPP connection for graphical web browsing, some POP client to connect to GPFN’s mail servers, or a third party high-speed internet connection to view GPFN’s web resources. For these users, a web-enabled system to allow them to review their account settings and change account parameters (such as passwords) is important.

User Requirements

It is expected that GPFN volunteers would interact with the new system using a graphical web browser. However, there will be users and volunteers who prefer the Lynx browser as their user interface. For this reason, any user interface should be implemented so that it does not make use of a graphics intensive front end. Similarly, the use of imagemaps, Javascript, applets, Shockwave and Flash media is not appropriate.

System Requirements

Because GPFN is a volunteer-driven, non-profit organization, cost containment is always an organizational issue. The UMS must be implemented in as cost-efficient a manner as possible. This necessitates the use of open-source or ther free software and development tools; conversely, GPFN discourages the use of products which require license fees or other costs.

Because GPFN’s environment is exclusively based on Linux, any system must be implemented on the latest release of RedHat Linux. At the same time, because Linux is a constantly evolving operating system, any system should be sufficiently flexible and robust that it can be ported to newer releases of RedHat as those releases become available.

This requirement can be met by attempting to confine operating system specific calls to a single layer within the application environment.

Business Model

During a Joint Application Development (JAD) session with GPFN board members, volunteers and members, the business model employed by the Free-Net was enunciated and elaborated.

Registered Users

The Free-Net has three basic classes of users. Registered Users are users who have signed up for service but who are not members of the corporation. Registered users are essentially “Free” users. They are not billed for their usage of the system. In return they are entitled to internet access using a GPFN dial-up account but are only offered a Cshell with its component text-only web browser and text based e-mail reader. They have 5 Mb of disk quota in the mail system and 2 Mb of disk quota for personal files and downloads in their home account. They are guaranteed one hour of usage per day.

Individual Members

Individual members have paid a membership fee (currently $24 per annum) to become a member of corporation. The constitution of GPFN allows for the contribution of service or goods-in-kind in lieu of the membership fee. Individual members are entitled to full participation in the governance of the corporation including voice and vote at all public meetings and the opportunity to be elected to the board of directors.

From a system usage perspective, institutional members are entitled to the same access privileges as Registered Users except that they:

Are guaranteed unlimited dial-up access but only in one-hour blocks of time;
Are permitted personal web pages within their home directory;
Can purchase additional services for their account such as increased quota, graphical PPP dial-up access, database access, or virtual web hosting.

Institutional Members

Institutional memberships are intended for community groups and organizations comprised of more than one person. As such, the same rights, responsibilities, privileges and opportunities exist to them as for Individual members with the following exceptions:

They are permitted 5 Mb disk quota within the public web space of GPFN;
Although they are only entitled to 1 e-mail account, they can have up to four e-mail aliases to forward mail to off-site accounts;
The membership fee is currently $48 per annum.

Additional Services Available to Members

A number of additional services are available to members only. These services include:

Increased quota for personal directory space, public web space, or incoming e-mail space;
PPP dial-up access so that members can dial in to the Free-Net’s modem pool and use their Netscape, Internet Explorer, Microsoft Outlook or other graphical browser or POP mail client to access the Free-Net’s resources;
Subscribing to a database within GPFN’s hosted database servers;
Subscribing to a virtual domain web hosting service whereby the member can have a web site with the domain name of their own choosing but hosted on GPFN’s servers.

The costs for some of these services are not yet determined but they are all billed on the basis of a calendar year.

Affinity Program

As a holdover from the default implementation of Csuite, a number of current GPFN memberships are held as “family” memberships. This is a membership category employed by the Chebucto Community Network but never formally adopted by GPFN. However, a small number of members found an orphaned page on GPFN’s web site and sent in a cheque for $40 for a family membership. GPFN decided to honour this membership option.

During the JAD session, GPFN stakeholders decided that they wanted any new system to have the option of supporting family memberships. Upon further discussion, it was agreed that the new system should have the capability of supporting a number of “aggregator” type accounts. Another example of such an account would be a company or non-profit group who has given a donation to the Free-Net. In exchange for the donation, GPFN would provide memberships at a reduced cost or at no cost to members of that company or group.

Such an “affinity” program would give GPFN a way of forming and cultivating strategic partnerships with other community groups and would necessitate a special pricing option for some members who also belong to the partnering organization.

System Architecture

Security Concerns

Since the implementation will use a Web Server connected to the Internet, security is a concern. This concern stems from two sources: how to prevent a “man in the middle attack” whereby a third party will intercept transmissions to and from the application and learn about a user’s password or other personal information, and how to ensure that an individual interacting with the system is entitled to perform such interactions. The former concern involves an issue of privacy, the latter an issue of authenticity.

The “man-in-the-middle” attack is not a present concern. Since GPFN has no plans to conduct on-line financial transactions at this time, there is little reason for a malefactor to attempt to hijack data transmissions from the UMS. At the same time, most users and volunteers will be using GPFN’s own modems to connect to the system further minimizing the chance for intercepting data transmissions. However, the requirement to support SSL encrypted connections may be added in the future.

The issue of user authentication is more pressing. The database should be secured so that only applications on the local host can access the data with write privileges. The application level should be designed so that user authentication is required before accessing the system and once authenticated a user’s credentials are maintained for the duration of the session. Once a session is finished or a time limit expired, these credentials must be revoked.

User authentication is important for both user access and volunteer access to the system. In the former case, it must be absolutely guaranteed that a user will never be able to access another user’s data. Similarly, it must be absolutely guaranteed that only approved GPFN volunteers will have access to the information of any user.

Implementation Concerns

The proposed system will be implemented by volunteers. This reality has a number of constituent consequences:

Volunteers work at their own pace and may not be prepared to meet arbitrarily imposed deadlines.
Volunteers will be working on their own time and from their own homes making it difficult to formalize project meetings or other team get-togethers.
Volunteers have a wide range of skills and a wide range of competencies within each skill set. The design must include a variety of tasks for volunteers of every skill set and ability.
To implement the system in the quickest manner, a phased approach should be adopted so that basic functionalities can be built and the system put into service at the earliest available date.