A FRAMEWORK FOR THE DESIGN OF AN EXTENSIBLE MODULAR ...

3 downloads 134 Views 86KB Size Report
We report on the experience accumulated by designing a modern web site ... The design of a web site is of a particular importance today, considering the impact.
A FRAMEWORK FOR THE DESIGN OF AN EXTENSIBLE MODULAR ACADEMIC WEB SITE Dimitris A. Dervos, Assoc. Prof., Information Technology Dept., T.E.I., P.O. Box 141, 57400 Sindos, Greece Email: [email protected], Tel. +30.2310.791295, Fax +30.2310.791290 Konstantinos Psarras, Systems Administrator, Information Technology Dept., T.E.I., P.O. Box 141, 57400 Sindos, Greece Email: [email protected], Tel. +30.2310.791604, Fax +30.2310.791290 ABSTRACT We report on the experience accumulated by designing a modern web site that is to serve the needs of the academic community at the Information Technology department of the Thessaloniki T.E.I. Along the lines of the requirements specifications set forth by a project funded by the 2nd European Community Support Framework (EPEAEK, Continuing Training, Action against Exclusion for the Job Market) launched in October 2003, the new web site should (a) comprise a single, ‘one-stop’ point, serving the information dissemination, exchange and communication needs of the teaching, student, technical, administrative, and alumni user communities, (b) support an easy to use interface, (c) implement modularity by organizing its content (both static and dynamic) and services in a way that reflects the departmental structure (i.e. the department as a whole, plus its divisions, research laboratories, student union, etc.), and (d) support a granular administration scheme, with one administrator, plus a variable number of moderator accounts with localized privileges, one per modular unit involved. At present, the system is not required to support a unified user authentication facility for a number web applications; however, it does come with an integrated facility that synchronizes user passwords across a number of (external) applications. KEY WORDS web site, portal, user role management INTRODUCTION The design of a web site is of a particular importance today, considering the impact internet has to our lives. In the not-so-distant past, it would suffice for a web site to implement a user-friendly organization of its, mostly static, content. Today, the web is rapidly evolving into a universal information repository with services that span across nearly all of the social aspects of a human’s life: work, entertainment, communication, shopping, etc. The information management and dissemination need of the academic community at the Information Technology department of the Thessaloniki TEI is no exception to the ‘rule’ outlined in the previous paragraph. Within the departmental structure, one can easily identify user roles (e.g. student, teacher, alumni, etc.), and organizational units that need be supported in the abstraction of a web-based community model. In designing the first version of the latter, care has been taken not to violate the (empirical) 80/20 rule that adds value to an organization when deploying a new information system, namely: “deliver the 20% of the

system that people really need to 80% of the people”. Quite often, many organizations fall into the 20/80 trap by opting for monolithic applications that attempt to deploy 80% of the required functionality, but only reach 20% of those that need it, because of the costs of training and support [1]. In this respect, a strategic decision taken in the early stages of the project was not to aim for a full-scale portal environment design and implementation, for the following two reasons: •



The department and the TEI of Thessaloniki, do not yet utilize the number and the type of applications that call for the operational umbrella of a sophisticated portal environment. In this respect, the specification requirements of a typical higher level educational institution in Greece differ from those of an analogous environment in the U.S., or in the U.K. Portal design and development utilizes a technology that appears to be in a transitional phase nowadays; the big players in the marketplace (IBM, Microsoft, Oracle, etc) are on the move towards offering pervasive portals, namely portal like functionality embedded within the operating system. In this respect, it is worth holding back a bit on the strategic moves one makes, especially when an open source platform is used for development and implementation.

Still, the design of a web site for the Information Technology department at the Thessaloniki should not exclude the possibilities for future extensions in the direction of implementing portal-like functionality of the type outlined by Geoff Butter: (a portal is an environment that) brings together content from diverse distributed resources, using technologies such as crosssearching, harvesting, and alerting, and collates this into an amalgamated form for presentation to the user [2]. REQUIREMENTS SPECIFICATION Prior to considering the requirements of the model system itself, it is worth to identify and briefly comment on the impact the usage of a modern web site is expected to have on the everyday life of its target user population. Only then, one can safely plan for the subsequent stages and properly prioritize the importance of each one sub-task involved in a series of incremental development stages. Thus, despite the details in the design and in its functionality, the web site is expected to shape the everyday life of its user community as follows: 1. It will comprise a ‘one-stop’ point in serving the information dissemination, exchange, and communication needs of the department’s academic, student, technical, administrative, and alumni user communities, 2. It will promote and sustain the communal feeling amongst its user population. In the case of the graduates in particular, it will help them maintain contact with the department and promote interaction with the current student community in a most constructive and mutually beneficial way, plus 3. It will improve the efficiency of management, by having its structure reflect the organizational structure of the department. In this respect, a number of requirements relating to the functionality of the system under development are identified, and have as follows:

• •





• •

Personalization: The system should implement granularity in user access, determined by the administrator: everybody need not have access to everything. Customization: The user should be able to configure the way information is presented. For example, by controlling the screen layout, as well as the content displayed. Grouping and Team Working: Interest groups should exist in the user community, enjoying privacy in their group communication. Collaboration should be encouraged by having the system support threaded discussions, voting and surveys, plus calendar sharing. Simplicity of use: Reflected in (a) the way the system is accessed on the internet via a standard web browser, and (b) the 80/20 rule in serving the information processing needs of its user community. Modular Design: Each one group sub-environment need be identical to the rest, and implement its own private communal services. Granular Administration: Each one group sub-environment need have its own (local) moderator, plus one or more (local) content managers. THE MODEL

In accordance with the specification requirements presented in the previous section, Figure 1 outlines the topology of the model environment. To the (unauthorized) public user, a number of subject catalogs present information of a general interest, e.g. the structure of the department, the degree(s) offered with the corresponding course syllabi, the academic, administrative, and technical staff, contact info, etc. The information that goes public via the public subject catalogs may either be of a static nature (i.e. HTML documents with embedded hyperlinks), or be retrieved dynamically from one or more databases maintained by local applications. The modular inner structure involves six (6) basic facilities: 1. Announcements Board: Registering announcements of interest to the user community 2. Discussion Fora: A discussion board containing a number of user-initiated discussion fora. Each one of the latter comprises a ‘speaker’s corner’ type of asynchronous discussion area, usually focusing on one specific topic. 3. Events Calendar: Registering info on upcoming events. Contains backbone information maintained by the administrator and/or the item moderator (if applicable), allowing each one user to append own calendar data which is accessible only via his own, private view on the calendar. 4. Web Applications: A variable number of (external) applications accessible from within the web site environment. 5. Web Links: Hyperlinks to web addresses containing information of interest to the (local) user community. 6. Subject Catalogs: A hierarchy of sub-directories/folders with documents that are meant to be accessible only by the (local) user community in question. In addition to the main inner environment containing the above (1-6) facilities at level-1, the model environment opts also for a variable number of similar level-2 clones. Each one of the latter is said to comprise an item. To each one item the web site administrator assigns the role of the item moderator to one of the users who belong to the item’s own group of users. The item moderator has administrator access to all the resources of the group in question. In

addition, he has the privilege of granting content manager roles to one or more members of the item’s user community. A content manager has administrator access on selected (item moderator specified) resources within the item, without a grant option.

Figure 1. The web site topology DEVELOPMENT PLATFORM SELECTION To begin with, one strategic decision taken was to investigate the availability of an open source solution/platform for the development of the departmental web site. This was due to the formidable cost of the corresponding commercial products. In this respect, a number of open source web site development software solutions (frameworks) have been considered. At first, the PHP-Nuke [3] content management system (CMS) was used. However, the existence of a number of unresolved security flaws in the platform was seen to dictate some limited platform functionality in order to avoid the exploitation of the to-be-developed web site by unauthorized third parties in the internet (e.g. [4]). Next, the PostNuke CMS platform [5] was considered. As a derivative of the PHP-Nuke solution, PostNuke was seen to comprise a more robust environment, as far as security is concerned. However, it was found to involve a limited flexibility in terms of the user classification (roles) it supports. More specifically, PostNuke provides support for just two types of user roles: administrator and user. In the case

of the departmental web site in question, one of the critical system specifications is for the administrator to distribute/decentralize some of the content management control privileges to a number of local (in terms of the user population and content part they control) moderators. The experience of testing PHP-Nuke and PostNuke against the given set of specification requirements of the departmental web site, has led to the appreciation of the functionality supported by yet another PHP-Nuke derivative CMS platform: the phpWebSite communitydriven webware [6]. In compliance with the set requirements, phpWebSite provides support for granulated administration, namely the administrator can assign permissions on a per user basis. For example, the admin account could grant a user the privilege to post announcements, but not allow him the option of deleting them. Under the given scheme, the system users population involves accounts with varying privileges/permissions [7]. The support phpWebSite offers for granulated administration makes it stand out of the ‘crowd’ of the existing CMS platforms. The norm for most of the latter is to adopt a minimalist/generic approach on the user access issue, namely one where only the administrator, the user, plus a limited number of pre-defined extra user roles are supported: a type of functionality rated to be insufficient for the departmental web site under development. This is the main reason why the phpWebSite platform has been chosen for the development of the departmental web site.

USER ACCESS MANAGEMENT Considering the issues addressed in the “Development Platform Selection” section above, the user access policy (UAP) for the model under design involves the following processes: • • • • •

User authentication User authorization Group assignment Role assignment Determination of access rights

As soon as a (remote) user visits the web site, he automatically defaults to the ‘public’ group of users. This implies that he is allowed to wander around the public region of the site’s topology (the public subject catalogs in Figure 1). In the UAP model, a list of access rights is embedded into each one of the web site resources. The list of access rights refers to the rights each one user group has for the resource in question. In addition, each user group involves a list of users who have been declared to belong to it (Figure 2). The assignment of a user to one or more groups, and the determination of the access rights a user has for a certain resource, taken together comprise the user authorization stage. It is worth noting that, as far the UAP is concerned, each one entity of the model in Figure 1 is taken to comprise a resource (i.e. catalogs, documents, announcement boards, calendars, items, etc.).

Figure 2. User authorization policy (UAP)

Users may proceed and have themselves be authenticated by the system (i.e. log on into the inner area of the web-site). This can only be done by presenting the necessary credentials (i.e. username and password) to the system. Authentication credentials are given to all the members of the departmental community (graduates/alumni members included). Have the credentials been confirmed/accepted by the system, the user is granted the privileges associated to the one or more of the pre-defined user groups he belongs to. As a result, he obtains access to a number of resources that are not generally available to all users. In addition to belonging to one or more of the pre-defined groups, each one user of the system is granted one or more roles. With the exception of the web site administrator role (that has full access to and control on all resources), an authenticated user may be granted one or more of the following three roles: item moderator, item content manager, and ordinary item user. The difference between the roles of item moderator and item content manager is that the former acts as a local administrator to the item, possessing privileges that he can selectively grant to the members of his group, whereas the latter (item content manager) acquires (local) administrator privileges on selected item resources that he cannot grant to others. Lastly, ordinary item users acquire privileges indirectly, via the group(s) the web site administrator declares them to belong to. Once a user is declared to belong to an item’s own group of users, he is subject to having his privileges be enriched by including a set of additional privileges granted to him by the item’s moderator. Users are grouped in accordance with the operational items present under the web site’s ‘umbrella’, at a given instance in time (Figure 1); to each one item corresponds a group of users who possess privileges that allow them to access the resources of the item in question. For example, say that user_A has just logged on into the system. Having done so, the user acts in accordance with the roles that have been assigned to him by the web site administrator, and (probably) by one or more item moderators. For example, he may be an item moderator for items I1, I6, and I9, an item content manager for items I2, and I5, and an ordinary user for items I4, and I7. It is noted that the content of items I3 and I8 is not accessible by (i.e. it is transparent to) the user in question.

CONCLUSION AND FUTURE WORK The framework (design model) for the development of a web site for the Thessaloniki TEI Information Technology department is presented. An initial set of design goals are met, in accordance with the 80/20 rule, namely “deliver the 20% of the system that people really need to 80% of the people” [1]. The web site is being developed by utilizing the phpWEbSite, a derivative of the PHP-Nuke CMS platform. Its modular structure makes possible the operation of a variable number of item sub-environments within the web site; each one of the latter is managed/maintained by a local item moderator user account and a number of item content manager user accounts, in a decentralized granular user access policy (UAP) scheme. To satisfy/serve the information dissemination, exchange, and communication needs of the department’s user communities, a separate item sub-environment is implemented for (a) the academic staff, (b) the technical staff, (c) the administrative staff, (d) the students, (e) the alumni, etc. The system is designed to be flexible in creating/dropping item sub-environments at runtime, as the need occurs. The plans for the design and development of future extensions to the web site framework described above include: •

• •

A unified user authentication system that will also cover a number of services accessible via the departmental web site (e.g. a controlled interface to the student transcript records database, a web-based database application managing the industrial student placements, the department’s virtual/distance learning environment, etc.) A cross-platform search engine facility System usage log file analysis for the determination of user patterns and resource usage REFERENCES

[1]

Bordoli J., “Portal Power: An Introduction to Portals”, white paper, Ashton Court Group Ltd., Available from: http://ashtoncourt.com, 2004.

[2]

Butters G., “What features in a Portal?”, Ariadne Issue 35, Available from: http://www.ariadne.ac.uk/issue35/butters/intro.html, 2003.

[3]

PHP-Nuke Content Management System. Available from: http://phpnuke.org/

[5]

PostNuke Content Management System. Available from: http://www.postnuke.com

[4]

Vink J., “Multiple security flaws in PhpNuke 6.x - 7.3”, SecurityFocus, Available from: http://www.securityfocus.com/archive/1/365865, 11 June, 2004

[6]

phpWebSite community-driven webware. Available from: http://phpwebsite.appstate.edu/

[7]

The phpWebSite Reference Manual. Available from: http://phpwebsite.appstate.edu/manual/html/