The World-Wide Web (W3) provides the means to link different kinds of documents into hypertext collections. Most of today's web sites centralize the documents that form a collection in a single location. However, it is possible to create distributed collections by linking documents which are stored in different servers.
Distributed hypertext collections bring the advantage of being able to store parts of a collection in servers which are closer to authors. For example, in an extranet made of different research centers, we can store the documents generated by each research center in their own local servers, without precluding the linking of a document to any other one in the extranet.
The W3C SMIL Recommendation  offers another potential application for distributed collections. For example, a SMIL document can be stored in one server and describe the presentation of multimedia contents stored in other servers. The contents could be produced by other authors and be leased to the SMIL author.
Unfortunately, distributed hypermedia collections not only bring benefits, but also new authorization problems. It is necessary to coordinate user administration, specification of access rights, and revocation of authorization for the documents that belong to a collection [12,11]. Different research and commercial techniques have been proposed to solve some of these problems [2,8,14]. However, these solutions are not well adapted for distributed collections, impose the use of an enhanced browser, impose the use of an intermediary proxy or gateway, or impose a security policy.
In this paper, we propose WDAI, a simple W3 distributed authorization infrastructure for collection of documents that may be stored in different servers. The main features of WDAI are as follows (not given in any particular order):
The next section presents the WDAI design. Section 3 gives an informal security analysis of WDAI. Section 4 describes five security policies and shows how they can be interpreted under WDAI. There are other techniques that partially address the needs for distributed W3 authorization; some of them are discussed in Section 5. Section 6 concludes the paper and presents some of the perspectives for future work on WDAI.
In this section we describe how our distributed authorization infrastructure works. We start with a discussion of the assumptions that motivate some aspects of our design.
Since the inception of W3, a user may, technically, make a uni-directional link to any other document in any other server . The W3 philosophy makes it the responsibility of the owner of a document to establish access rights to the document. However, when trying to control access to a distributed collection of documents, it is necessary to coordinate the authorization information used to describe and to evaluate the access rights of users. We represent this need for coordination by grouping collections into authorization domains. An authorization domain may comprise one or more collections, but a collection may not belong to more than one domain. Documents may belong to more than one collection even if those collections belong to different authorization domains.
In general, when a server tries to authorize a request for its resources, the server needs to evaluate the request against the authorization information which specifies the access rights of the user . In WDAI, part of this information is local to each server and part of it is coded inside an X.509v3  based authorization certificate that the browser includes in each request. Because of certificate revocation concerns, our infrastructure assumes that there is a loosely secure synchronized clock in the authorization domain. This problem is similar to the one faced by Kerberos based systems . [9,13] propose some solutions on how to achieve secure clock synchronization.
Distributed collections also introduce the problem of user administration [2,12,11]. The security administrator must provide updated authentication and access control information to all the document servers in its domain. WDAI simplifies user authentication as only the authorization server needs to share authentication information with the users. However, in order to make document servers independent of other servers, each server needs to have a local copy of the access control information specifying the rights of users over its documents. User administration can be simplified by using security policies which are not based on user identity. These policies and the distribution of access control information are current research topics. For the purpose of this paper, we assume that this information is already available at the document servers.
A user should be able to use any standard browser he wants to consult a collection. This includes the case where the user goes to a cybercafé, thus precluding the download of plug-ins or other special programs. Our solution is to use the authorization certificate both to exchange authorization and authentication information. For the browser, there's no difference between an authorization certificate and a public-key certificate. The browser should be capable of running HTTP over a secure protocol, such as SSL, which guarantees both authentication and confidentiality. In addition, the browser must be able to download X.509 certificates and be able to present them to a server. Both of these features are supported by current SSL-enabled browsers and don't require a new public-key infrastructure. The details of SSL are not important for the infrastructure, so SSL could be replaced by other protocols.
The browser should be trustworthy while it is being used . It is difficult to control what a browser or a user can do with the browsed documents. In order to avoid overloading the infrastructure with specific precautions against those problems, we assume some trust in the browser. This implies that the browser doesn't have security faults and that the system in which it is running is under the control of the user. It also implies that we trust authorized users.
In WDAI, document collections are grouped into authorization domains. In addition, an authorization domain comprises a number of document servers, an authorization server, and a security administrator (Fig. 1).
In an authorization domain, we distinguish two kinds of authorization: a global authorization enforced by the authorization server and a local authorization enforced by each document server.
The authorization server is responsible for the global authorization to the collections in the domain. It is also responsible for the global authentication of users to the domain. The server will grant users authorization certificates according to the information stored in an authorization database. An authorization certificate is an X.509 certificate which includes not only a public-key, but also authorization attributes. Authorization certificates are exchanged between browsers and document servers during the authentication protocols.
Document servers are responsible for the local authorization to the documents that they store. We represent the security policy which governs the access to each document by means of an extended access control list (EACL). When receiving a request, the server first authenticates the user by means of the authorization certificate. The server then determines the user's access rights by evaluating the authorization attributes stored inside the certificate together with the EACL. In order to validate an authorization certificate, a document server needs to know the public-key of the authorization server.
The security administrator is a conceptual entity. It represents the need for coordinated administration of the information stored in the authorization database and in the EACLs.
The following scenario explains the interaction between these components. Suppose that our distributed collection represents an electronic library. The security policy of the domain allows an authorized user to consult all the documents in the collection. For this example, we consider that every authorized user has a password protected account on the authorization server. To consult the library, user Bob proceeds as follows:
In the above protocol, we described several cryptographic operations on the client side: the downloading of public-key certificates, the generation of a key-pair, the selection of a default user public-key certificate, and the removal of a certificate. All of these operations are supported by today's most popular SSL-enabled browsers [16,17].
Note that the authorization server also acts as a certification authority . In the above example, the authorization server shares a secret (the password) with the user. After having authenticated the user and authorized his request, the server will grant him an authorization certificate. Such certificate contains a public-key that the document servers should use to authenticate the user. This mechanism eases user administration as the document servers don't need to share any authentication information with the users; they just need to know the public-key certificate of the authorization server to be able to validate the authorization certificates.
WDAI doesn't impose any policy on what requirements the user must satisfy in order to acquire an authorization certificate. Our example describes a policy where the user must have some kind of account on the authorization server. In another policy, the user could have presented a public-key certificate to the authorization server, instead of a password. Still another policy could be one where the user sends a credit-card number instead of a password and buys a time-limited certificate.
We will now describe more in detail the structure of authorization certificates, of the EACLs, and the revocation of such certificates. Appendix A gives a more formal description of the authorization protocols that were mentioned in the scenario.
WDAI uses authorization certificates to exchange authorization information between browsers and servers. These certificates are generated by the authorization server.
The authorization certificates are based on the latest version (version 3) of the X.509 certificates . X.509v3 certificates permit the integration of user defined data, so called extensions, into the certificate. This property, which allows security administrators to bind arbitrary attributes to a public-key, makes certificates more flexible, bringing them closer to the concept of ECMA's Privilege Attribute Certificates [6,5].
Table 1 summarizes the attributes which characterize an authorization certificate. The certificate comprises four kinds of attributes: authentication attributes, authorization attributes, validation attributes, and other standard X.509 attributes (not shown in the table).
|User's session public-key|
|Collection unique identifier|
|Collection instance counter|
|Serial number of the authorization certificate|
|Validity period of the authorization certificate|
|Unique identifier of the authorization server|
|Unique identifier of the authorization server's public-key certificate|
|Signature of the certificate by the authorization server|
The authentication and validation attributes are those defined in X.509. The former provide the public-key of the user. The latter protect the certificate against forgery and specify the certificate's validation period. While X.509 certificates is issued by a certification authority and is expected to have a relatively long life, an authorization certificate is issued only by the authorization server and has a short life.
The authorization attributes constitute our principal extension
to X.509. The
collection unique identifier and the
collection instance counter attributes identify an
instance of a collection in a domain. For example, the collection
unique identifier could be made of the domain's name, a user-readable
name, and a binary identifier. The counter allows to distinguish
between instances of a collection and is used for revocating active
certificates. We'll describe the revocation of certificates later
The other authorization attributes give the privileges of the user, such as user id, groups, roles, security level, and so on, and they may complement the control attributes of EACLs. The value and type of these privileges depend on the security policy of the domain and are not defined by WDAI. Section 4 gives some example on how privileges can be used to implement different security policies.
EACLs specify the access rights of users over the documents stored in a server. Each document is bound with an EACL. As Table 2 shows, each entry in the EACL comprises both authorization and validation attributes.
|Authorized HTTP request methods|
|Collection unique identifier|
|Collection instance counter|
|Unique identifier of the authorization server|
|Authorization server's public-key certificate|
The authorization attributes describe the access rights of
users over the document. We first have the valid HTTP request
methods that a user may make on the document. Then, according
to the security policy, we may have one or more
attributes that complement the
found in the authorization certificate; for example, user id,
groups, roles, and so on.
The validation attributes are used to authenticate the certificate itself. They specify both the collection instance in which the authorization certificate is valid and the current public-key of the authorization server that can issue such certificate.
Note that each EACL entry identifies both a collection and an authorization domain. This makes it possible to share documents among different collections and domains.
The previous sections describe how a user obtains an authorization certificate and how he uses it to request a document. This section briefly examines the revocation of such certificate.
The inclusion of a validity period in the authorization certificates provides an implicit revocation of the certificates. However, in some cases, one may need to make an explicit revocation of active certificates; for example, when public-keys are compromised, when the security of a user or an authorization server is compromised, or when the security state of a document or of a collection of documents evolves. In these examples, the revocation can have different ranges:
We'll now briefly describe how to take into account all of the above by means of the validation attributes stored in the authorization certificate and in the EACL. For simplicity, we'll consider that there is only one authorization domain. If a revocation operation spans multiple authorization domains, the operation should be repeated for each concerned domain.
collection counterattribute. Valid authorization certificates need to have a
collection countervalue equal or bigger to that of the EACL entry. By updating the EACL entry, we can then forbid the use of existing certificates to access the document. The security administrator must coordinate this operation with the authorization server, to insure that new certificates will have a valid counter value.
In theory, all of the above revocation techniques can be supported in WDAI; however, in practice, their implementation presents some problems. The first technique requires that all servers keep a copy of the invalid certificates until their expiration. All but the second technique require that the security administrator propagates some security information to all the concerned document servers.
The fourth technique is the most interesting of all as it allows the protection of documents against the compromise of the authorization server. It can be implemented by storing the public-key certificates of authorization servers in directory servers, and then having each document server periodically retrieve the public-key certificates of the authorization servers which are cited in its EACLs. The retrieval period must be fixed in function of the number of public-keys that must be downloaded, the number of document servers in the domain, and the trust required by the security policy. A document server can also detect when an authorization server's public-key certificate has changed by means of the validity period attribute given in the authorization certificate.
The previous sections describe the design of WDAI. This section analyses the security properties that it achieves. The main theme of these properties is how well WDAI can take the compromise of its elements. The authentication protocol is responsible for protection against message replay, so it's not included in our analysis. Table 3 gives the summary of our analysis.
|Authorization certificate (theft)||Without effect, countered by user authentication.|
|Authorization certificate's private-key (browser or user compromise)||Compromise of a collection.|
|Document server||Compromise of all the documents in the server.|
|Authorization server's private-key||Compromise of all the documents in the domain.|
As noted earlier, the only protection that WDAI offers for the compromise of an authorization certificate is its implicit or explicit revocation. The former is costly in time, the latter is costly in complexity and resources.
Note that the the compromise of the private-key of the authorization server has the strongest impact on the system. The recovery of such compromise requires changing or deleting the server's public-key certificate. The speed of recovery depends on how often the document servers refresh their copy of this certificate and whether an attacker can block that refresh.
In this section, we describe how the security infrastructure can be used to implement five different security policies. The first three policies, which we name all-or-nothing, identity-based, and group-/role-based , can be found today in many web sites. The last two, multi-level security and collection-based [12,11], are examples of two potential policies. Table 4 gives an informal description of these policies.
|All-or-nothing||Authorized users may access all the documents in the authorization domain.|
|Identity-based||Each document must state which users can access it.|
|Role-, group-based||A user belongs to or can assume one or more user groups/role-names. Documents state which groups/roles users must belong to/assume to access them.|
|Multi-level security||All documents have a security classification and all users have a security level. Users may not access documents having a higher classification rate than their own security level.|
|Collection-based||All the documents are grouped into collections and the granularity of protection is a collection.|
Interpreting a security policy under WDAI is a two step procedure, which involves the generation of an authorization certificate and the selection of security attributes that will be stored both in the certificate and in the EACLs. The authorization server makes the first decision on whether to give an authorization certificate to the user and, if this is the case, which privilege attributes should be included in the certificate. This procedure depends on both the WDAI implementation and the security policy of the domain.
|security policy||authorization certificate||EACL|
|Identity-based||user id||user id|
|Role-, group-based||role name/group name||role name/group name|
|Multi-level security||security level||security classification|
|Collection-based||collection name||collection name|
The selection of security attributes follows closely the description of the security policy. Table 5 shows the privilege and control attributes that could be used to implement the policies. Note that the all-or-nothing policy doesn't use any security attributes, as it only requires the presentation of a valid authorization certificate.
In some cases, a domain may have multiple security policies. For example, one document server may follow the all-or-nothing security policy and another one an identity-based policy.
Rather than having a user request two different authorization certificates, the authorization server can include all the security privileges of the user in a single certificate. Document servers can then retrieve from the certificate the attributes they need to authorize a request. Some convention should exist in the domain in the way of describing such attributes in the certificate, e.g., by using an XML DTD, so that document servers can find and interpret them easily.
The ECMA-138 standard  and the Generic Authorization and Access Control API (GAA-AAPI)  propose an extensive list of security attributes which may be used to implement these and other security policies.
The RBAC/Web system [3,2], developed by NIST, is an implementation of role-based access control for W3. The system comprises document servers which enforce RBAC at the granularity of individual URLs, a centralized authorization database, and an administrative tool that allows a security administrator to define roles, inter-role relationships, and assign roles to users. A user starts a browsing session by first contacting a session manager service to select an active role. When the user requests a document, the document server uses a secure channel to forward the user's request and authentication information to an RBAC/Web authorization server. Upon reception of the the authorization decision, the document will either return the document or an error message to the user.
Being based on a centralized authorization server, RBAC/Web has simple user administration needs and supports the instant revocation of access rights. However, there's a strong dependency on the availability of the server and each request for a document implies an additional request to the authorization server. In WDAI, once the user obtains an authorization certificate, there is no further need to contact the authorization server during the session. However, the explicit revocation of active authorization certificates can be complex. Also, user administration can be complex as there's a need to synchronize the EACLs of the documents that belong to a collection. User administration can be simplified by using non-nominative security policies [2,12].
Both OSF's DCE-Web [14,15] and SSE's TrustedWeb  are systems which can be used to support distributed authorization in a W3 environment. WDAI and both these systems work under a similar principle: a user first obtains a certificate from a security server. The certificate includes both authentication and authorization information. From then on, the user presents the certificate to access documents stored in other servers. The document servers maintain their own access control lists.
DCE-WEB and TrustedWeb provide mature interfaces for administrating the user's access rights. Both systems support a wide variety of security policies, including role-based ones. However, in both systems, the handling of certificates requires the installation of a custom proxy in the user's workstation, or, in the case of DCE-WEB, the use of an enhanced browser or of a specialized gateway. In WDAI, authorization certificates are based on X.509v3 certificates and can be handled by any standard SSL-enabled browser. Thus, there's no need to enhance browsers or to use a custom proxy. WDAI doesn't yet specify any administration interface.
W3 has the potential to distribute collections of documents over a number of servers. WDAI provides a simple infrastructure for controlling access to such collections. The principal contributions of WDAI as follows:
Finally, we believe that the most important contribution is to provide a simple infrastructure for experimenting and developing new W3 distributed authorization technologies. Our wish list for future work on WDAI includes:
Note that existing distributed systems technology can answer many of the above points. When possible, future work on WDAI should try to integrate that technology into a W3 context.
We are currently building a prototype of WDAI, code-named Tartu, around the Apache HTTP server and mod_ssl  (support of HTTPS inside Apache). We have working authorization and document servers and have been successful in generating the authorization certificates and using them from SSL-enabled browsers. We are now working on an Apache authorization module for providing customizable access control rules. Tartu will be distributed as Open Source.
I thank the reviewers, Ralph Swick, and Frédéric Séraphine for their valuable comments and recommendations. of this paper. I also thank Gareth Rees and Michael McClennen for providing useful insight which allowed me to generalize WDAI's design.
WDAI defines two authorization protocols, the request for an authorization certificate protocol and the request for a document protocol. Both of these protocols are built over HTTP and HTTPS and use the standard HTTP methods.
In order to simplify the description of the protocols, we'll assume that the authentication of a principal and the setup of a secure channel take place immediately after the exchange of the principal's public-key certificate. Table A.1 gives the notation used to describe the protocols.
|A --> B : M||Principal A sends a message M to principal B.|
|M1, M2||Concatenation of two messages.|
|CKUA||The public-key certificate of principal A.|
|AuthorCertA||The authorization certificate of principal A.|
|M ?||A request for message M|
A user begins a session by first obtaining an authorization certificate from the authorization server. Figure A.1 summarizes the message exchanges.
|authentication of the authorization server|
|1.||Browser --> Authorization Server||:||CKU Authorization Server ?|
|2.||Authorization Server --> Browser||:||CKU Authorization Server|
|request for the authorization certificate|
|3.||Browser --> Authorization Server||:||AuthorCert collection ?|
|authorization of the request|
|4.||Authorization Server --> Browser||:||Authorization Information collection ?|
|5.||Browser --> Authorization Server||:||Authorization Information collection|
|6.||Authorization Server --> Browser||:||
WDAI doesn't define the authorization information of Steps 4. and 5.; it's up to the security administrator to define its type and value. For example, it could be a login/password pair, a public-key, a credit-card number, and so on.
Note that only the authorization server needs to be aware of this authorization information. The authorization certificate will provide the authorization and authentication information needed by the document browsers.
Once the user has obtained an authorization certificate, he may start consulting the documents of the collection. Figure A.2 shows the message exchanges.
|1.||Browser --> Document Server||:||CKU Document Server ?|
|2.||Document Server --> Browser||:||
CKU Document Server,
AuthorCert collection ?
|3.||Browser --> Document Server||:||AuthorCert collection|
|request for the document|
|4.||Browser --> Document Server||:||Document ?|
|authorization of the request|
|5.||Document Server --> Browser||:||
Although the protocol seems quite complex, in practice, it's implemented as a single URL. For example, in Tartu, our prototype implementation of WDAI, URLs for protected documents have the following form:
In the above example, the authorization certificate gets exchanged during the SSL authentication protocol. The server will first authenticate the user using the public-key stored in the certificate. It will then authorize the user using the authorization information provided by the same certificate.
The error message can give be a classic
message. Following the security policy, the message could tell
the user what kind of authorization certificate he needs, give
the list of all the collections where the document is included,
and give the URL of the authorization servers which can deliver
the authorization certificates. This information is already present
in the document's extended access control list.
José Kahan joined the technical staff of the World Wide Web Consortium (W3C), at INRIA Rhône-Alpes in January 1996. He participates in the development of Amaya and various other projects. His research interests include distributed systems, W3 security, and hypertext mailing list archives. José holds a Ph.D. in computer science from the Université de Rennes I (1997) and a specialization degree in computer networks from the École Supérieure d'Électricité (SUPELEC), Rennes.