Issues in Web-based Collaborative Systems
Lukasz Beca, Marek Podgorny
CollabWorx and Syracuse University
Web-based collaborative services are becoming increasingly popular.
Examples include chat rooms, virtual meetings, and distance learning
environments. In this paper we analyze functionality and architecture
of two types of real-time collaborative systems: a system for supporting
online meetings and a system for supporting distance learning sessions.
We discuss security issues that arise during design, deployment,
and use of these systems, such as authentication, authorization,
communication security, auditing, and integration with existing
security frameworks. We identify currently available security solutions
and evaluate their applicability in addressing identified issues.
We also propose new solutions where currently used technologies
do not seem adequate.
Terms: security, World Wide Web, collaborative systems
diversity of the services available on the World Wide Web is growing.
The users, apart from accessing the most popular applications such
as browsing documents and performing purchases, can also participate
in online auctions, chat rooms, virtual meetings, distance learning
sessions and other activities. The World Wide Web is becoming increasingly
a virtual place where people not only operate in isolation but also
interact with other Web users. Still, even though the existing infrastructure
supports relatively secure Web browsing and purchasing transactions,
there is no generic framework for building secure systems for on-line
of the already available solutions can be adopted (for example SSL
, digital certificates), but not all of them are sufficient
or appropriate because of requirements imposed on real-time collaborative
systems, which are different from the requirements imposed on standard
Web applications. For example, the HyperText Transfer Protocol (HTTP)
 does not provide ability to notify a Web client about changes
in the content managed by Web servers. A notification mechanism
is one of the several services that might be used to implement collaborative
applications, which must receive updates about changes in the shared
application state. In absence of the notification mechanism, new
communication protocols must be used by such applications. This
approach in turn causes a number of problems related to integration
of the system communication infrastructure with already existing
security solutions–for example deployed firewalls.
this paper we address general issues of security in Web-based collaborative
systems. The paper is organized as follows: In Section II
we discuss how various aspects of the Web environment can
be of benefit to collaborative systems. In Section III
we discuss two typical collaborative applications and, based
on a case study, we define generic system architecture for collaborative
systems. In Sections IV
we discuss various security aspects and available solutions.
provides an overview of the integration issues related to
the existing Internet security infrastructure. Conclusions are provided
in Section X
of the World Wide Web is a phenomenon with many different facets.
Socially, WWW transformed perception of computers from an obscure
and arcane technology used by technical and business people to a
home appliance and a subject of casual party conversations. In this
aspect, computers and information access capabilities became a part
of everyday social life. Technologically, the broad demand for these
new, hitherto exotic services, led to an unprecedented explosion
in creativity of system architects. In a span of just several years,
the Internet evolved from a simple collection of few dozens of web
servers into an advanced distributed computing system.
Supported Collaborative Work (CSCW) premises and concepts predate
the Web but it is one of the fields that is being profoundly affected
by the Web: CSCW is traditionally concerned with human-computer
interfaces, and its focus is computer support of human collaborative
activities. With the social change of attitude towards every-day
use of computers, CSCW is poised to leave its laboratory confines
and move towards mainstream computing.
Web environment offers significant benefits to the developers of
collaborative systems. The most important features are: global scope,
high availability, rich content, multi-platform clients, and ability
to host executable content. All these properties make the Web a
powerful platform for building collaborative applications. In fact,
many of the new industrial groupware systems (for example WebEx
, Lotus SameTime , PlaceWare ) are Web based.
trend is accelerated by the nature of Web technology. Its social
and technological impact on groupware makes Web –based collaborative
systems increasingly sophisticated, and, slowly but surely, improves
their acceptance. As the Web-based collaborative systems gain industrial
acceptance, they will have to undergo the evolution from laboratory
tools to strategic IT tools. This, among other things, implies making
them secure and integrating them with the existing Internet security
most of the groupware applications developed on the Web enabled
only asynchronous collaboration (for example, BSCW ). These applications
were build using Web technologies such as HTML pages, CGI scripts,
or Java servlets. As a result, security problems encountered in
such applications could be addressed using standard Web solutions
(for example form based authentication and HTTPS protocol). Some
of these technologies are also useful for development of real-time
(synchronous) collaborative systems. However, inherently different
requirements imposed on real-time collaborative systems force developers
to combine Web technologies with non-Web solutions. Such hybrid
systems are not entirely covered by the security models currently
used on the Web.
this section we describe our efforts to create two secure Web-based
real-time collaborative services: a web conferencing system (called
virtual meeting) and a distance learning system (called virtual
classroom), based on TANGO Interactive framework  developed
jointly by Syracuse University and by CollabWorx. We wanted to
build the systems in such a way that:
After deployment at a Web site they do not decrease
security of already present solutions.
The potential users of the environment can trust
other participants of the interaction; the content of the interaction
is protected from capture or malicious modifications.
Deployed security solutions do not impose computation
or communication overhead that would be unacceptable to the service
users or service hosts.
meeting system provides functionality of scheduling and holding
online meetings. The meetings can be scheduled and accessed only
by authorized users. Usually one of the participants prepares presentation
to be displayed for other users during the meeting through shared
web browser. Communication with other participants is provided through
audio/video links, and chat application. Whiteboard tool can be
used to clarify presentation issues. Moreover, participants have
an option to share their screens or selected applications. All users
have access to the list of meeting participants.
classroom system enables delivering lectures to the geographically
students in real-time. It supports structured patterns of interactions
appropriate for teaching. The instructor has active role; he or
she coordinates activities in the classroom to ensure efficient
learning process. The students receive lecture content, they can
ask questions and they can take control over certain tools while
monitored by the instructor. The tools for signaling questions or
continuous evaluation of the lecture presentation enable better
interaction between students and the instructor. Our experience
(the system was used to deliver fully accredited, semester-long
graduate courses from Syracuse University to geographically remote
colleges) indicates that in some cases, when the number of students
is large (i.e., above 15), it is useful to introduce another type
of a session participant – an assistant. Such person is responsible
for monitoring activities of the students and responding to the
questions related to technical problems that may develop during
a virtual lecture. Many problems during the class sessions stem
from the fluctuations in the available bandwidth of the Internet
connections and this factor influences quality of the service delivered
to the students.
applications described in the previous section have similar architectures
since they are built using the same collaborative framework–TANGO
Interactive (hereafter referred to as TI). Figure 1. presents the
architecture of the TI system.
system is built according to several basic principles. The most
entire system is browser-based. It is started from a Web link,
and most of the client side code executes in a browser.
tools are implemented as Java applets, scripted Web pages, or
as ActiveX components. However, the framework takes a pragmatic
approach and allows native collaborative tools. Native tools can
be implemented in C/C++, as Java applications, or in other programming
language. Functionally identical APIs are provided for each supported
system allows tools to be downloaded at runtime or installed on
- If the tools are downloaded by the system,
they can originate from an arbitrary Web server. The tools can,
in turn, request additional data. TI framework treats Web servers
as a primary repository for both the tools code and data. This
holds even for the native applications.
tools share the state using event-sharing mechanism. The events
are shared via a special middleware layer, denoted as TI plug-in
Figure 1., and via a real-time messaging server, called TI Meeting
Engine (TIME). TIME does not have to be collocated with any of
the Web code and data servers. It is implemented as a Java application.
- Collaborative tools, either in-browser or
native, can communicate with TIME only via the middleware (plug-in).
Importance of this arrangement is discussed below.
bi-directional communication for sending and retrieving messages
between the collaborative tools and the middleware is provided.
Browser supported document object model is extensively used.
Figure 1: Architecture
of the TANGO Interactive web-based collaboration
critical components of the system are the plug-in (middleware), and the Meeting Engine.
Middleware has been introduced to ensure high system reliability.
It also plays important role in system security. The crucial idea
behind middleware is that collaborative tools cannot communicate
directly with the messaging server. Instead, they use middleware
method calls for such communication. The middleware acts as a message
filter and multiplexer, preventing applications from sending ill-formed
or illegal messages. An ill-behaved tool might not work but it would
not disturb the overall system operation.
of the plug-in as data multiplexer simplifies implementation of
the messaging server. Each system client connects to the engine
just once. A proprietary protocol provides all services necessary
to identify message sources and addresses. In absence of the multiplexing
plug-in, each application would have to open a separate connection
to the messaging server. Such a solution practically precludes implementation
of strong and coherent security mechanisms. As described in further
sections, in TI framework secure communication is implemented between
the plug-in and the messaging server.
the messaging server is a central element of the system, it may
become a target of attacks executed by hackers that want to take
control over the environment. The server has been designed with
security in mind. It is primarily responsible for message routing.
In contrast to data servers such as HTTP or FTP, TIME does not perform
any local file operations. For its authentication and authorization
functionality, TIME communicates through encrypted connection with
the database placed behind the firewall. In addition, digital certificates
may be used for authentication during database access to eliminate
possibility of TIME spoofing. The database is accessed by TIME in
read-only mode. The reason for this approach to TIME security design
is that the messaging server cannot be placed in a highly secure
environment without seriously impairing its basic function of message
routing (see Section IX.B
). In the case that TIME is broken into, the server does
not provide any means to further compromise OS or data source security.
shown in Figure 1., TI framework has one special collaboration tool,
the Session Manager. The tool is implemented as a Java applet, and,
depending on system configuration, it may present system user with
a graphical interface, or it may be hidden, in which case its operation
is defined by startup scripts. Session Manager (SM) uses special
protocol to communicate with the plug-in. This protocol supports
complex and potentially unsafe operations such as loading the application
code and data and starting application execution on remote machines.
SM tool participates in user authentication and authorization, and
it also provides unified mechanism for meeting floor control. Under
these circumstances, code and communication protection of SM is
critical. TI solves this problem by digitally signing both the SM
and middleware code and by verification of digital signatures before
communication can be established.
final comment about the architecture is related to the peer-to-peer
communication channel between the instances of a collaborative tool.
In Figure 1, a dashed line connects the two instances of “Native
Application”. This schematically denotes a peer-to-peer communication
model. Since we have stated above that TI framework uses messaging
server to establish message routing between collaborative tools,
the addition of peer-to-peer communication pattern may be confusing.
Let us hence explain this issue in some detail.
framework achieves scalability and high performance by making a
careful distinction between the data and event communication
channels. Let us consider a shared browser tool. In the popular
shared display (a.k.a. shared screen) mode of collaboration, a master
browser would download the data from a Web server, and then the
system such as NetMeeting would replicate display of the Internet
Explorer on the workstations of all shared browser session participants.
This clearly is not an optimal solution. TI framework works differently:
under the control of Session Manager, a shared browser tool is started
on multiple workstations. The session chair, or master, selects
a URL to load into the browser. The browser sends the URL to TIME,
which, in turn, distributes it to other instances. The “slave” instances
download the URL from the same Web server or, if the system URL
mapping facility is used, from a replicated server. With properly
configured topology of the system it is possible to have sharing
of HTML documents while incurring only minimal network traffic.
The same principle can be now used to capture browser events such
as page scrolling, DHTML layer control etc. Shared browser perfectly
demonstrates all advantages of event sharing.
the same principle can be used to implement a shared whiteboard,
or a shared world described by a VRML scene graph. Event-sharing
methodology of state sharing works best if the amount of information
necessary for state synchronization is small compared to the amount
of “static” data. In our solution, dynamic data is distributed via
messaging server; static data always comes from Web infrastructure.
Similar approach is applied in case of a chat application. We can
distribute chat messages via TIME, since chat messages are short
and, being generated by humans, infrequent.
paradigm breaks with applications such as audio-video conferencing.
The data streams become “fat” and they are also time-sensitive.
In such case, TI framework uses TIME only to establish collaborative
sessions of the specialized tools, such as an audio or video conferencing,
and it allows the tools to use their private communication channels.
This is a mechanism very similar to the H.323  approach, where
Q.931 and T.245 protocols are used to establish the “calls” and
then RTP protocol is used to distribute data streams in the peer-to-peer
mode, optionally using IP multicast to optimize network bandwidth.
TI framework provides security only for the session setup phase.
Security of the media stream distribution is not supported. The
media conferencing tools have to implement this functionality on
their own. TI framework makes this process a little simpler since
it can be used to, for instance, exchange the secret encryption
keys and security policy parameters between instances of the tool.
environments have a number of the requirements related to the security
of these systems. In general, they can be broadly divided in two
parts. One set of problems is related to traditional security measures
such as authentication, authorization, and communication security.
Each of these issues has new aspects in the context of collaboration
systems. We will discuss these new aspects in detail. The second
group of problems is related to integration of collaborative systems
with the existing Internet security infrastructures.
of the users is necessary so that meeting participants can determine
who they are interacting with and possibly have access to the information
about other group member. Such approach increases trust among meeting
participants and leads to more efficient interactions. Authorization
mechanisms are necessary to determine access rights to the collaborative
application resources. They can be used to limit the group of users
that can participate in the online meetings or virtual classroom
sessions. They can also be used to impose structure on the interaction
by applying restrictions in access to the system resources. Another
important issue is security of communication channels used for exchange
of control and application data among collaborative clients and
servers. Without protection the protocol messages can be intercepted
and used to gain access to the system. Moreover, potential attacker
can get access to the application data exchanged between collaborative
client and server. Finally, there are numerous security solutions
already deployed on the Web (for example, security models implemented
by Web browsers, firewalls on corporate networks) and collaborative
environments that operate in this environment should be able to
integrate their security solutions with already present infrastructure.
performed during regular real-life meetings (for example, presentations,
discussions, decision making) require that participants know and
trust each other. The same necessity applies to the online meetings.
One of the important features of the collaborative system that supports
this requirement is assurance that the users that participate in
online interactions are really the individuals who they claim to
be. In this way, the participants of the meeting know that the specific
identifier denotes certain real person that they probably met in
real life or exchanged a number of e-mail messages and can expect
specific type of behavior. The issue of authentication is also essential
in other types of distributed applications, for example, distributed
operating systems .
number of technologies are available that support authentication.
Kerberos  was designed to provide authentication services for
large distributed systems. Currently, it is included in several
operating systems. However, it is not widely used in the Web environment.
SSL protocol provides mechanisms for authentication, which allow
Web clients to authenticate Web servers and vice versa. The authentication
is based on the X.509 certificates  installed in the Web browsers
and servers. Simpler solutions use form-based authentication supported
by Web browsers. It is also possible to embed authentication solutions
in the protocol used for communication between collaboration server
our solution we use combination of two mechanisms: X.509 certificate
authentication mechanism provided by the HTTPS protocol and authentication
messages embedded in the protocol used for communication between
collaboration client and server (that correspond to plug-in and
TIME as described in section III.B ). The first mechanism is used
to gain the access to the Web site where the users can enter meetings.
Another mechanism is used when the user enters specific virtual
meeting or virtual classroom session. At that point the participant
must submit user name and password. The information about users
with corresponding passwords is stored in the database and it is
accessible to the collaboration server (TIME), which can check validity
of user login operation. We use SHA  algorithm for scrambling
passwords. Since the password is sent without encryption from the
client to the server, the communication channel must be protected
(see section VII
for more details). The described authentication mechanism provides
base for enforcing authorization polices defined for specific types
of environments (for example virtual classroom).
enables verification of the user’s identity and this information
can be used to define user’s access to various resources and services
provided by the system. In the first approach we can define all-or-nothing
policy. The user that was recognized by the system as authorized
is allowed to participate in collaborative sessions and use the
system without any restrictions. This approach may be appropriate
for on-line virtual meetings where participants are subject to social
norms that in natural way impose limits on the interactions. However,
in certain situation more structured patterns of interactions are
required; ability of defining such structure may be achieved by
introducing refined access control mechanisms. A type of session
management policy , access to specific collaborative tools, and
modes of floor control  – all these parameters can be used to
shape collaborative policy targeted for particular application.
example, in the virtual classroom environment, an instructor needs
to maintain control over collaborative activities at all times in
order to deliver the content of the lecture efficiently. On the
other hand, the students should have access only to limited functionality
that would not allow them to disturb other receivers of the lecture.
In our solution we addressed this problem by the introduction of
the simple role based access control (RBAC) mechanism (for extensive
description of this topic see  and ). Each participant in
virtual classroom session has a role assigned. Example roles include
a professor, a student, and an assistant. The roles in turn are
used to describe access permissions to collaborative sessions, tools,
or control tokens. Depending on the role, the system may decide
to allow the participant to enter the meeting, start specific tool,
or use already started tool with limited or full functionality.
As a result, it is possible to control collaborative functionality
that is accessible to specific user precisely and relatively easily.
of the assumptions that must be made when building distributed application
operating on the Internet is that all messages exchanged among application
components over the network can be intercepted, fabricated, spoofed,
or stored and retransmitted later by malicious users. The commercial
Web sites that perform financial transactions use HTTPS (HTTP over
SSL) to provide secure access to their services. Real-time collaborative
systems are also vulnerable to this type of threat. The messages
exchanged between collaboration server and clients (TIME and plug-ins
as described in section III.B
) contain protocol messages (for example login message with
user name and password) and application data that can be potentially
used to harm collaborative session participants (for example, if
the confidential business information is presented during a virtual
meeting). Also, a malicious user can try to send messages that simulate
actions of one of the meeting participants. Therefore two properties
must be satisfied in order to provide secure communication among
collaborative application components: confidentiality and integrity.
order to provide these features in implementation of TI framework
we used SSL as an underlying layer of our communication protocol
(we evaluated BSAFE—SSL Java libraries developed by RSA ). SSL
has a number of properties that make it feasible as a mechanism
providing communication security for collaborative environments.
It provides mechanisms for client and server authentication, channel
encryption, and message authentication. Moreover, it allows selection
of various cipher suites from the strongest (but slowest) to the
weakest (but fastest) so that requirements of various types of user
groups can be accommodated. The users that can accept lower performance
for the benefit of improved security can use the strongest cipher
suite. On the other hand when the security requirements are more
relaxed, faster algorithms can be employed.
additional protocol layer adds computational overhead to the message
processing. This overhead is almost unnoticeable for applications
with low bandwidth requirements such as chat or whiteboard that
exchange data in form of small state updates. However, the overhead
can be significant for applications that require high bandwidth,
for example screen sharing applications. Also, applications that
transmit large volumes of delay-sensitive data (audio/video conferencing
tools) using connectionless protocols (UDP) cannot use SLL to provide
communication security. In such situation, phone conference call
can be used to provide secure audio link.
our implementation of virtual meeting and virtual classroom systems,
SSL (in combination with X.509 certificates) is also used to authenticate
collaboration server (TIME) to the clients. Such approach enables
control over deployed engines and makes difficult establishing unauthorized
installations. However it requires creating infrastructure for issuing
and management of keys and certificates used by the system (PKI
framework can be used for that purpose ).
the intrusion into the system already happened the mechanisms should
be in place to allow discovery of the break-in. Auditing (recording
of important events related to accessing the system functionality)
can be used to enable such detection. In our solution the collaboration
server (TIME) maintains a log of the most important events in the
system. Each entry in the log contains following data:
Operation type: system login and logout, session join and leave,
session creation and termination.
objects affected by the operation.
User identity: the system assigns temporary identifiers to the
users upon successful completion of login procedure, the identifier
is later used to tag actions executed by the particular user in
Status: provides information about whether operation was executed
successfully or not. In case of failure, the reason is provided
Timestamp of the operation
of the information contained in the log can give insight into activities
of the users and can help in detection of the potential intrusion.
of the Web-based applications must take into account security technologies
already deployed in the Internet environment. In this section we
concentrate on the security model implemented by Web browsers for
executable objects and on methods of implementing communication
A. Web browsers
and executable objects
systems that use objects executable in Web browser environment (for
example Java Applets or ActiveX controls) must take into account
security models implemented by the Web browsers (Netscape Navigator
and Internet Explorer). Java applet by default is not allowed to
access any resources placed on local machine. Also, it is forbidden
to open socket connections to the machine other than the one where
the Web server that hosts the applet is placed. The latter limitation
is particularly significant if we want to deploy a collaboration
server on the machine other than the one from which the client was
downloaded. Fortunately, it is possible to overcome mentioned restrictions
by using appropriate mechanisms  provided by browser platforms.
These mechanisms are based on capabilities model in which principals
(digitally signed Java applets) can get access to certain targets
(protected system resources). Authorization of access is represented
by the privileges associated with the principal and related
to particular target. As a result, in order to access a particular
resource managed by the Web browser, the principal must explicitly
ask for the privilege to use the resource (the code of the applet
must contain an appropriate method call). After the privilege is
granted, the resource can be used without restrictions.
practice, before letting an applet to execute a potentially dangerous
operation (for example, opening socket connection to arbitrary host
on the Internet) the browser displays a window with information
about the feature that is supposed to be accessed, information about
object signer, and controls that enable user to make decision to
grant or deny appropriate privilege.
system requires access to several restricted resources such as:
socket connections to arbitrary hosts (necessary to connect to TIME)
or ability to execute applications on client’s machine. The access
to this functionality is acquired through the capabilities mechanism
collaboration systems, whether Web-based or not, firewalls create
a set of major problems. These problems are not widely known, and
they have not been extensively discussed in the literature. This
is probably due to the fact that academic campuses, where most of
the CSCW research work is done, usually do not use firewalls, relying
instead on other network protection mechanisms, such as tight traffic
monitoring and policy enforcement via administrative methods. Academic
institutions also enjoy a privileged access to the IP addressing
space, eliminating the need for network address translation. Yet,
the problem of traversing firewalls is critical for successful deployment
of collaboration systems. Our experience with such deployment on
corporate and DoD networks provided us with a body of evidence on
how existing security infrastructure can break deployment plans
for collaborative applications.
most frequent reasons for the problems we have encountered in practice
administrators responsible for security do not want to compromise
firewalls by “punching holes” for additional network connection
necessary for collaboration systems to function. For example,
the popular NetMeeting application from Microsoft  requires
opening of a number of TCP ports and all UDP ports with numbers
above 1024! Deployment of applications that use UDP protocol is
particularly difficult to negotiate, as many secure corporate
networks block all UDP traffic. Similarly, H.323-compliant conferencing
products require a block of both TCP and UDP ports to traverse
An alternative to opening ports in firewalls is installation of
proxy servers integrated with firewall. The problem with this
solution is that, with exception of SOCKS  proxy servers,
all proxy servers are application protocol-specific. This means
that every application requires a separate proxy to communicate
through firewall. Installation of proxy servers incurs additional
software license and maintenance cost. Further, proxy servers
are only available for popular protocols such as HTTP and FTP.
Certain application vendors provide proprietary proxy servers
(a good example is Oracle Connection Manager, which provides proxying
of the entire Oracle Net8 protocol suite), but for many other
application a network-layer SOCKS proxy is the only available
solution, which slowly is becoming a standard. Still, configuration
of a SOCKS proxy server for real-time groupware is relatively
2: Secure deployment
of a web-based collaboration service
integration issues for groupware systems for the service receivers
are generally less complex than these for the service providers.
In our solution, if the end-users of a collaborative service are
connected to a network that uses generic firewalls without proxy
servers the only available solution is to open ports in the firewall
to enable access from the client-side middleware to the collaboration
server (TIME). In this context the importance of the message multiplexing
function of the middleware becomes apparent. It is sufficient
to install a firewall channel for one TCP port to enable communication
with the conference engine. For the firewalls with integrated
proxy servers, a standard HTTP proxy server takes care about all
HTTP traffic described in Section III.B
. To provide communication with the TIME a SOCKS proxy
should be used. To avoid complex setup procedures on the server
side it is recommended that all end-user workstations install
a SOCKS wrapper (a good example of such component is SOCKSCap
). The wrapper enhances TCP/IP protocol stack on the end user
workstation and routes all outgoing connections to the SOCKS proxy
server. This solution has been tested on large secure corporate
networks with TANGO Interactive framework. A combination of the
standard HTTP and SOCKS proxy servers enables the entire functionality
of the collaborative application.
the provider side the requirements are a little more complex.
Figure 2 presents a recommended configuration of the site providing
typical security setup involves two firewalls: an Internet firewall
and an internal firewall. The network segment behind the Internet
firewall is often called “Demilitarized Zone” (DMZ). Typically,
the public Web servers are placed on this network segment, which
is not considered very secure. Many installations refresh contents
of the Web servers in regular intervals to prevent unauthorized
changes by hackers.
DMZ segment is the ideal location for both the collaboration server
(TIME) and for the Web server acting as the code and data repository
for the collaboration system. As discussed in previous sections,
our collaboration server was designed to provide secure service.
The code and data repository can be periodically refreshed in
the same way as the other Web server content. The database back-end
storing collaboration application user and policy data can be
placed behind internal firewall.
solution presented in Figure 2. suggests opening TCP ports in
the firewall to enable access to both Web and collaboration servers.
A more sophisticated and more secure solution can be implemented
using an inverse HTTP proxy server for Web services and a custom-built
inverse proxy server for the collaboration engine.
implementation and deployment of secure collaborative services
on the Internet are complex tasks. We analyzed security issues
that we encountered during our work on real-time virtual meetings
and virtual classrooms. Some security aspects, such as authentication
and channel security, can be addressed with relative ease using
already available technologies (although not all aspects can be
solved in this way; for example, there is no standard solution
for encryption of audio and video streams). Other functions, such
as authorization and auditing, must be designed and implemented
specifically for the developed systems. Finally, the integration
with already deployed security solutions on the Internet, especially
firewalls, requires careful analysis of the installed infrastructure
and often requires changes to the site configuration.
C. Adams, S. Kent, S. Lloyd, Understanding the Public-Key
Infrastructure, New Riders Publishing, 1999.
 Beagle Software,
SOCKSCap information: http://www.beaglesoft.com/ProxySocksCap.htm
L. Beca, G. Cheng, G. C. Fox, T. Jurga, K. Olszewski,
M. Podgorny, P. Sokolowski, and K. Walczak, “Java enabling collaborative
education, health care, and computing”, Concurrency: Practice
and Experience, Vol. 9(6), June 1997, pp. 521-533.
 G. Coulouris,
J. Dollimore, and T. Kindberg, Distributed Systems: Concepts
and Design, 3rd ed, Addison-Wesley Pub Co, August 2000
W. K. Edwards, “Session management for collaborative applications”,
Proceedings of the conference on Computer Supported Cooperative
Work, 1994, pp 323 – 330.
 D. F. Ferraiolo,
J. F. Barkley, and D. R. Kuhn, “A role-based access control model
and reference implementation within a corporate intranet”, ACM
Transactions on Information and System Security 2, 1 (Feb.
1999), pp 34-64.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, T. Berners-Lee, Hypertext Transfer Protocol—HTTP/1.1,
RFC 2616, 1999.
 S. Greenberg,
“Personalizable groupware: Accommodating individual roles and
group differences”, Proceedings of the European Conference
on Computer Supported Cooperative Work (ECSCW’91), Kluwer
Academic Press, 1991, pp. 17-32.
T. Horstmann, R. Bentley, “Distributed authoring on the
Web with the BSCW shared workspace system”, StandardView
5, 1 (Mar. 1997), pp 9-16.
 iPlanet, Object Signing Resources
 ITU-T Recommendation H.323,
Visual telephone systems and equipment for local area networks
which provide a non-guaranteed quality of service, November
 J. B. D. Joshi, W. G. Aref,
A. Ghafoor and E. H. Spafford, “Security models for web-based
applications”, Communications of the ACM 44, 2 (Feb. 2001),
 C. Kaufman, R. Perlman, and
M. Speciner, Network Security: Private Communication in a Public
World, Prentice Hall, 1995.
Lotus, SameTime, http://www.lotus.com/home.nsf/welcome/sametime
 Microsoft Corp., NetMeeting,
 RSA Security, BSAFE Library
S. A. Thomas, SSL & TLS Essentials: Securing the Web, John
Wiley & Sons, 2000.
WebEx Communications, http://www.webex.com
E. D. Zwicky, S. Cooper, D. B. Chapman, Building Internet Firewalls,
2nd ed, O'Reilly & Associates, 2000.