Increasingly, the WWW requires management of its data, including controlled dissemination within specific groups of users. Currently, the authorization and organizational mechanisms required for such use of the Web are lacking. The DCE Web applies a set of sophisticated distributed computing technologies, based on OSF DCE, to solving these problems. Most important, the DCE Web provides a sophisticated authorization mechanism, based on DCE ACLs, along with a structure for organizing groups of Web users and resources under coherent security and other administrative policies. The DCE Web also incorporates an efficient name-service based mechanism for locating objects. The DCE Web provides these features while maintaining seamless access to the WWW using familiar browsing interfaces and an unchanged user's view of the Web. A prototype DCE Web browser, server and gateway have been developed. The prototype browser is based on a protocol tunneling toolkit designed to make it possible to easily adapt existing Web browsers to the DCE Web environment with minimum change to existing software. Preliminary performance testing of the DCE Web indicates that subjective performance is on a par with standard Web browsers. Work is ongoing to develop new security, administrative, and naming mechanisms.
The original motivation behind the World-Wide Web was a focused one: to provide tools "which would allow collaborators in remote sites to share their ideas on all aspects of a common project."[1] This occurred in the context of CERN, the European Particle Physics Laboratory in Geneva, Switzerland. Early Web use was focused on easy, rapid broadband dissemination of information. However, Web use is rapidly growing to include organizations, such as businesses and government agencies, that want to share different categories of information, in distinct ways, within a variety of user populations. Even researchers may wish to share potentially patentable ideas within a limited community. The Web is beginning to move beyond a service that allows information to be easily created and widely disseminated, to one that requires management of its data, including controlled dissemination within particular communities.
Our DCE Web is designed to help the World-Wide Web meet these requirements by applying state-of-the-art distributed computing services to the Web. In particular, we want to provide the means for groups of Web users to share hypertext documents protected by sophisticated authorization mechanisms under coherent and easily administered security policies. This means, for example, the ability to set permissions for specific operations-to browse, to post, to delete, to query, etc.-for individuals and groups of users and for specific sets of documents. In addition to such security, we also want to make the Web easier for collaborative groups to use by incorporating naming, management, and other distributed services.
Of course, we want to do all this while providing seamless Web access using familiar hypertext browsing interfaces. The user's view and model for use of the Web must be essentially unchanged. We recognize that there is a certain tension between these goals. One one hand we want to be able to draw strict administrative boundaries around sets of documents and users. On the other hand, we don't want these administrative boundaries to translate into unnecessary Web boundaries for users. Users must be able to see documents simply as part of the World Wide Web of hypertext.
Our approach to solving these problems has been to apply the services provided by the OSF Distributed Computing Environment (DCE)[6] to the Web. DCE is the result of extensive collaboration among private industry and academic and research institutions, and contains a distillation of much of the best distributed computing technology currently available. By applying the DCE services to existing Web software, we are able to offer powerful new functionality to the Web, especially in the area of security, without having to reinvent the wheel.
This paper describes our initial work on the DCE Web, leading to the creation of our first set of prototype Web tools. It begins by providing some background on the security and administrative issues we are dealing with (Sections 2.1 and 2.2). Following this we introduce the major features of DCE relevant to our work (Section 3). Then we provide a high-level overview of DCE Web design (Section 4) and a description of our current prototype implementation (Section 5). We also report some preliminary performance results (Section 6), and, finally, we discuss future directions for our work (Section 7).
We are convinced that security-especially authorization-and administration are the most important areas where we will need to improve the Web to meet the goals laid out in Section 1.
Our central concern in developing DCE Web security has been authorization. Ongoing work on authentication and data encryption has been laying the foundations for full security solutions on the World Wide Web [2][8]. This work generally relies on a combination of public key and secret key encryption to achieve two goals: authentication of users to servers and servers to users, and encrypted transmission of private hypertext documents or client information such as credit card data. However, very little work has been done towards the goal of authorization or access control [3].
In the context of the Web, authorization means applying authentication information to determine what actions a user may take, perhaps on a specified document or documents. The richness of the HTTP [4] methods available requires access control that can be applied at the granularity of issuing a particular method against a particular hypertext object. Web access control is complicated by the fact that not all hypertext objcts exist as files or even exist before they are accessed. In the DCE Web we propose the use of authorization mechanisms based on DCE's distributed Access Control List (ACL) technology. ACLs are a flexible, fine-grained, standards-compatible solution to Web needs for access control, and are available today on a growing number of platforms.
It is important to emphasize that authorization mechanisms, such as ACLs, are largely independent of the specific authentication and encryption technologies that lie below them. The DCE infrastructure provides distributed ACLs based on DCE's current authentication mechanism-a symmetric secret key system-but it will also be able to take advantage of further advances in DCE security technology, such as support for public key encryption, as they become available.
A second important issue for our work is that the Web currently provides only limited means for grouping hypertext documents, servers, and users in coherent organizational entities. Current Web security work tends to fall at two extremes of the organizational spectrum. Some is aimed at providing solutions for unorganized sets of resources and groups of users. For example, security systems such as PGP [7] rely on each user's experience and good sense for assuring that any public keys accepted are valid. At the other end of the structuring spectrum, systems such as the proposed Commerce Net[2] security propose a specific set of authorities (financial institutions) for a specific kind of Web transaction (financial).
What is lacking, however, are the means to support groups that define themselves and control their own resources (self-administering groups). Such groups define group-local authorities to take responsibility for issues such as key management and transfer, authentication, and authorization. Self-administering groups are likely to require authorization policies at a finer granularity than those currently available on the Web via such mechanisms as partitioning documents between internal and external home pages. For example, a working group within a larger enterprise already has to deal with at least two possible access boundaries: between itself and the larger enterprise, and between the enterprise and the rest of the word.
DCE allows groups (including organizations and enterprises) to establish their own authorities and administration policies, and to control what other authorities are trusted. This provides the building blocks needed for groups to administer their shared resources in a secure and coherent manner. For example, a business unit would typically designate an administrator, along with proxies, to establish members' authentication as employees and members of the unit, to establish trust relationships with other groups, and to administer privileges and access to resources. DCE ACLs are the basis for practical access control mechanisms using this style of organization for the Web.
DCE provides a distributed infrastructure and API to develop, use, and maintain distributed applications. It is a product of the collective efforts of a number organizations spanning business and academia, and is currently being deployed on a large number of heterogeneous platforms. DCE's support for organizing distributed systems, distributed security, client/server communications, and global naming, are among the features employed by the DCE Web project.
DCE organizes distributed resources and their users in cells for purposes of administration and scaling. A DCE cell consists of a set of distributed services, users, and host machines, administered under a coherent set of security and resource organization policies. While communication can take place between cells, a cell is usually defined with an eye towards minimizing the cost of frequent communication within the cell.
DCE authentication is based on Kerberos V5 [5], a symmetric secret key facility for authentication and encryption. Trusted servers provide these services to DCE clients, servers, and users within a cell. Users log in (authenticate) to a cell, and clients and servers can mutually authenticate whenever they interact. The DCE security services include a registry where users and their attributes are defined. One such attribute is the DCE group, which provides an easy way to refer to a collection of users, and is used in authorization decisions.
DCE's authorization mechanism is DCE ACLs, which are based on the POSIX 1003.6/Draft 12 specification. An ACL is usually associated with an object: the ACLlists users (or groups of users) and the kinds of access (based on permissions) they have to the associated object. DCE applications have a great deal of latitude in interpreting ACLs. They determine which object[s] an ACL protects, and they can define what permissions are associated with a type of object, and what those permissions mean.
Cells are structural units for administration and contain local authorities for security and naming. Inter-cell trust links can be established to allow users in one cell to take advantage of the full set of services available in another cell. These links establish that each cell is willing to trust the other as an authority for the authentication and privileges assigned to users from that cell, and for authorization decisions involving objects in that cell. This allows each cell to interact in a trustworthy fashion with whatever other cells it deems appropriate. Additionally, in DCE 1.1, hierarchical cells will allow trees of cells to establish trust relationships without requiring one-to-one trust relationships to be established between all the cells.
DCE 1.1 also offers secure delegation support. Delegating servers may either impersonate a user, or may be explicitly taken into account in authorization decisions. This latter mode could, for example, allow Web access control policies to specify that a document can only be served to a proxy or caching server that knows how to honor the access control information associated with the document.
DCE uses its Remote Procedure Call (RPC) interface for communications between clients and servers. Communication over RPC may be protected against tampering (integrity-protected), as well as protected against disclosure (privacy-protected, currently with DES). In the DCE security model, clients choose the security attributes to apply to a communication, and the server decides whether these are acceptable. Authentication, if it is applied, takes place transparently to both the server and client. DCE RPC runs over a variety of transports, both connection-oriented and connectionless. Choice of transport may be transparent to the distributed applications that use DCE.
The DCE cell also provides structure for the DCE namespace. A global naming service-either Domain Name Service (DNS) or DCE Global Directory Service (GDS), which is based on the X.500 standard-are used to name and locate cells. Within a cell, the Cell Directory Service (CDS) provides a distributed, hierarchical namespace for distributed applications and other resources. Distributed applications may also maintain their own namespaces, joined to the CDS namespace, so that application-specific resources are reachable via DCE names.
The DCE Web design has been guided by the desire to fulfill the two rather contradictory requirements set out in Section 1: the DCE Web must offer a well-defined and secure organization of users and resources and yet must be smoothly and transparently integrated into the larger World Wide Web from the user's point of view.
At its simplest, a DCE Web consists of a set of DCE-capable Web servers within a single DCE cell. When a DCE-capable browser accesses a DCE Web document, DCE services are applied to the request; for example, DCE authorization can be used to determine if the access is permitted. Similarly, the browser can make use of the cell directory service to locate documents.
DCE's cell-based organization and administration of resources is directly applied to such a DCE Web. For example, the Web's security policies are implemented via the cell's security services: Web users and groups are included in the cell registry, Web users can be authenticated, and DCE ACLs can be applied to documents for fine-grained access control. Similarly, the cell directory service provides a single, location-independent namespace for Web documents maintained by servers in the cell.
Webs can also be constructed from multiple DCE cells. The cell is basically a unit of scaling, and DCE intercell authentication and global naming provide the means to scale DCE services to very large numbers of servers and users. Using these mechanisms, even a large and widely scattered set of Web servers and users can be subject to coherent security and other administrative policies in a multi-cell DCE Web. Users should not see any difference when browsing documents in single and multi-cell Webs: they need not be aware whether documents are in the same or another cell. In fact, the structure of a DCE Web is basically an administrative issue; users need not be aware of it at all.
Communication between DCE-capable browsers and servers occurs by passing standard HTTP protocol messages using the DCE RPC service. This approach, known as protocol tunneling, treats the RPC mechanism as a transport, replacing the TCP transport over which HTTP messages are normally sent. This design makes a set of DCE services--including authentication and authorization-- available to the unmodified HTTP protocol.
The DCE tunneled HTTP protocol is integrated in a standard Web browser (currently Mosaic) so that it is transparently accessible via a familiar interface. When the browser retrieves a document maintained by a DCE-capable server it uses the tunneled protocol. When it retrieves a document maintained by a standard HTTP server, it uses the non-tunneled protocol.
From the browser's point of view, the documents of a DCE Web are seamlessly integrated into the World Wide Web: documents maintained by DCE servers can contain links to documents maintained by non-DCE servers and vice versa. The documents in a DCE web are simply a subset of the documents in the World Wide Web: the only difference is that links to them use the tunneled protocol and may apply DCE security and other services.
One issue that we have not settled yet is how browsers identify links that may be accessed via the tunneled protocol. The most straightforward mechanism is to define a different protocol identifier for DCE URLs. This is what we do in our current prototype . However, such a scheme is incompatible with non-DCE browsers and cannot be used to make documents available to them. If an object's status as either a DCE or non-DCE Web document is rigidly associated with a naming scheme, then names become stale when documents are moved from one domain to the other, and two names must be exported to make a document available in both domains.
We therefore plan to provide a protocol determination mechanism that is compatible with existing browsers. One very straightforward scheme, based on DCE names embedded in standard URLs, is described in Section 4.4 of this paper. We are also considering some form of protocol negotiation.
Security is obtained by applying DCE authentication, integrity and privacy protection, and authorization to tunneled HTTP requests. Servers may make authorization decisions based on a number of factors. For example, a server may accept only authenticated requests, it may require that all requests be encrypted, etc. Most important, the server can use DCE's POSIX-compliant ACL mechanism to make an authorization decision based on the client's identity or group membership. The architecture does not dictate which policies servers must apply. Instead, our design offers server administrators a wide choice of security policies. One future goal of this project is to develop mechanisms that will make high-level security policies easy to define and administer.
Using DCE naming services, it is extremely easy to implement name-based document lookup in the DCE Web. A server for a document makes it available under the same DCE name, no matter where the server itself is located, and the browser uses the name services to bind to the correct server. Such DCE Web naming provides persistent document references that do not become stale when a server moves or a document is moved to a new server.
We also plan to experiment with using name-based document location to support replication and caching of documents for increased reliability and performance. In such a scheme, servers of replica and cached copies of a document make them available under the same name, and the browser implements a mechanism for choosing the best path to a document: for example, bychoosing a server which has previously provided fast response.
Our current prototypes simply use DCE names imbedded in URLs. However, as noted in section 4.2, our current URLs cannot be resolved by non-DCE browsers. One obvious solution to this compatibility problem is to imbed DCE names in standard http URLs that point to servers that act as proxies[11] to the DCE Web. Non-DCE browsers would make requests via the proxy, while DCE browsers would extract the DCE name and resolve it to the appropriate server directly. In the future, URNs will offer another approach to this problem, and we would like to implement at least a prototype of URN-based document lookup, using the DCE name services to provide URN to URL translation.
To the user of a DCE-capable browser, access to DCE Web documents looks exactly like access to other Web documents except that the browser provides means to set the DCE security parameters and a clear visual indication of the security attributes of each access. The only other difference is that users may see DCE-related error messages when an access fails in some DCE service, for example because of an authorization-related access refusal. The Web's DCE services provide HTML-formatted error messages to the browser when an error occurs.
To the user of a non-DCE capable browser, access to DCE Web documents can be limited or made impossible, depending on the security policies of the DCE Web. Our design for the DCE Web aims to give the Web administrator a full range of access policy choices, explicitly settable, from the most restrictive to the most open. If allowed, unauthenticated access to DCE Web documents may be provided by a server that handles both tunneled and non-tunneled protocols or via a gateway that translates non-tunneled protocol requests to tunneled requests and forwards them to a DCE server.
Our approach to developing a browser has been to develop a protocol-tunneling toolkit that can be easily applied to existing browsers to make them DCE-capable. The basic design is to transparently replace the browser's existing transport interface with an interface to a DCE module that encapsulates HTTP messages as DCE RPC data. The browser reads and writes its protocol messages without any knowledge that they are being passed to the DCE module. The DCE module in turn communicates with the server via DCE RPC.
A major advantage of this approach is that the browser's protocol processing code is unchanged. To use the DCE toolkit, the protocol simply replaces the usual communications interface with calls to the DCE layer. In our prototype we only change the semantics of one connection-related call.
Using this approach, we were able to provide a DCE tunneled protocol module for the standard WWW library (libwww) by changing only a few lines of the standard HTTP protocol processing module. In our current browser (based on Mosaic) requests to the tunneled protocol module are dispatched in the standard way, based on the URL's protocol identifier. We were thus able to integrate the tunneled protocol without any changes to the browser itself except for modifications to the user interface to support setting DCE security attributes. We believe that the same "toolkit" of DCE code can be just as easily integrated into other Web browsers based on libwww.
We changed the browser interface by adding menus that allow the user set the authentication, authorization, and encryption levels to be applied to tunneled HTTP requests. However, we are working on ways to simplify the presentation of security choices to users since, in practice, interactions among the different components of DCE security can be complex. With the current browser the user explicitly sets DCE security attributes per window. However, explicit user action could be avoided in most cases by automatically setting default security levels per URL or letting the browser discover an appropriate security level by negotiation with the server. DHTTP URLs could contain security hints to facilitate this process.
Theoretically we could apply the same toolkit approach to existing Web servers to make them DCE capable. However, we are currently not convinced that this is the correct approach for developing DCE-capable servers, though we are continuing to investigate this issue. One of the benefits of DCE is that servers can be multithreaded, based on the DCE user-space threads package. Simply applying a protocol tunneling toolkit to a typical single-threaded server sacrifices this advantage.
In the prototype we have instead opted for a fully multi-threaded server, although this required writing much more of the code from scratch. At a minimum, reengineering a server for multi-threading requires making protocol processing work routines thread-safe. Compared with this, the work of adapting the protocol-processing code to interface with DCE RPC is likely to be trivial.
We have currently implemented a simple gateway demonstration. This is an application that listens for HTTP requests on a standard port and encapsulates them for forwarding to a DCE server via DCE RPC. In essence, this performs a function similar to the tunneling toolkit, except that it is a separate executable from the browser, communicating via the standard HTTP mechanism.
Communications between the gateway and the browser are insecure (from a DCE point of view) so that servers must treat all requests from gateways as unauthenticated. (One could, of course, consider a much more sophisticated gateway that translates non-DCE to DCE trust.)
One of our goals is to provide user-perceived DCE Web performance equivalent to that of the existing Web for an equivalent level of service. For, example, an unauthenticated tunneled request should be no slower than the equivalent request over non-tunneled HTTP. Obviously, when encryption and other services are provided, users can expect to see some degradation of performance as the price of additional service.
When we measured protocol performance with an instrumented version of the current browser prototype, we found that the tunneled HTTP was about only 8% slower than non-tunneled HTTP for unauthenticated re- quests. We are confident that with some performance tuning we will be able to narrow this gap in later versions. More important, this level of difference at the protocol level does not seem to be noticeable to users, though we have yet to do any formal testing of user-perceived performance.
HTTP Tunneled HTTP Change 24917 msec. 26846 msec. -8%
In the short term, we plan on having our prototype browser and a rudimentary server available for other organizations to use by December 1994. Shortly after, we will flesh out an architecture for Web servers that want to take advantage of DCE's services, which will include resolving the issues of server design discussed in Section 5.2. We will also be looking into the best way to allow access to documents in a DCE sub-web by both DCE-aware browsers and standard browsers supporting HTTP. Besides our current gateway approach, we plan on looking into protocol negotiation, perhaps as outlined in the S-HTTP specification [9]. We also plan to investigate ways in which the DCE naming architecture can be adapted to the URN model currently under development.
More work needs to be done on the authorization needs of Web users. ACLs are the assembly-language of security policy; they are fine-grained enough to say many of the things users want to say, but only experts in the language can say it right the first time. Higher-level languages, such as rules-based languages, are needed to allow users and administrators to easily translate their site security policy to the computer mechanisms supporting it. Higher-level tools for administrators are needed to allow actions such as setting or changing the security attributes of one or more objects with a single action. The Web also requires tools for specifying the attributes of transient objects, which are created when they are accessed.
In addition, research into Web-centric security models is needed. Since firewalls are the main security mechanism available on the Web today, many organizations are restricting their documents to either internal or external. However, both business and government have traditionally used more complex models. Even the simplest business authorization models often involve four levels of restrictions on data: personnel data, confidential project data, internal data, and world readable data. Work in privacy-centric models, which provide the subject of information some inherent control over its use and dissemination, may also fill near-term Web needs. In the area of trust, a gateway approach may provide us a testbed for experimenting with models of trust relationships that are not symmetric, hierarchical, or transitive.
Other DCE features can be used to exercise potential solutions to Web deficiencies. DCE's secure communications, privileges, and interface definition language make the development of tools for secure, remote administration of Web servers possible. Operations on servers, as well as on particular documents, can be protected using DCE ACLs. Research must first be done to discover which generic server management issues apply to Web servers, and what special management interfaces are needed in the Web. DCE's support for distributed application development also make it an excellent infrastructure for prototyping distributed agent support for Web browsers.
Steve Lewontin is Principal Research Engineer at the OSF Research Institute, where he is currently working on the DCE-Web project. Before coming to the RI, he worked in the OSF Engineering group on DCE and was a coauthor of the DCE RPC interoperability and portability specification. He began his computer career writing documentation and documentation software and has also worked professionally as a graphic artist, and he considers the World Wide Web as the ideal place to bring together all these threads.
Mary Ellen Zurko co-authored an award-winning paper on a highly secure (A1) Virtual Machine Monitor, and has published in usable distributed security and foundational computer security. Before her work on DCE Web, she pioneered GUI-based, usable tools for viewing and changing DCE information, such as ACLs, at Digital Equipment Corporation. She owned the user interface for a privacy-enhanced mail prototype, and she designed the programmer's API and various pieces of the end-user interface to a CAD/CAM system. She also introduced user-perceived performance metrics to Digital. Her current research interests are defining intuitive trust models, managing electronic communities, and marrying security and usability in distributed systems.
Contact Author Email Address for Conference Committee: zurko@osf.org