3 A capability-based authorization model
6 Implementation considerations
The World-Wide Web (WWW) [6] organizes information into sets of hypertext documents, where a document comprises links to media contents, links to other hypertext documents, and rules specifying the presentation of contents and the traversal of links. We refer to a set of related inter-linked documents, such as the sections of this paper, as a presentation tree. We refer to the entry point of a presentation tree as a root document. Finally, we use the term node to refer to either a document or a content.
WWW supports the distribution of nodes by providing node-naming structures (e.g., URLs [5]) and information retrieval protocols (e.g., HTTP [4]). By storing nodes according to their type in specialized servers, the system's overall load and capacity can be better balanced.
The use of hypertext structures requires a coordinated authorization approach. Granting access to a document should also involve granting access to the contents linked to that document. Otherwise, users would not be able to correctly perceive the document. Similarly, granting access to a presentation tree should involve granting access to all the documents that constitute the tree. Otherwise, a user would not be able to consult the presentation tree as intended.
Despite the support of distribution in WWW, little progress has been made in providing coordinated authorization under this context [24].Existing WWW authorization approaches for distributed nodes are based on Access Control List (ACL) mechanisms [19]. These approaches require either that node servers know their potential clients or that node requests involve a consultation with an authorization server. The former approach presents a client administration problem when the client population changes at a fast rate. The latter approach presents a potential performance bottleneck as the processing of a node request depends on the availability of the authorization server.
The following sections present a distributed authorization model which supports authorization at the presentation tree and document levels for distributed documents and contents. In this model, only one server needs to know its potential clients, while node servers make local authorization decisions using capabilities presented by their clients. The model supports a sequential access mode to presentation trees. An extension to the model provides a non-sequential access mode. Section 2 gives key authorization requirements for the model. Section 3 describes the authorization model. Section 4 presents extensions to support node migration techniques. Section 5 presents a group extension which provides the non-sequential access mode. Section 6 describes our experiences in building a prototype of the model. Section 7 reviews related work in the field. The paper ends with a summary and some perspectives.
This section gives a brief summary (in no particular order) of the key requirements that have shaped our authorization model.
The capability-based authorization model groups node servers into authorization domains. Clients wishing to retrieve nodes from these servers must include appropriate capabilities [19] in their node requests.
In addition to node servers, an authorization domain comprises a Security Administrator (SA), responsible for the generation and installation of capabilities, as well as an Authorization Server (AUS), responsible for granting root document capabilities (Figure 1). Although node capabilities share the same format, we distinguish hereafter between a capability for accessing a document (Dcap) and a capability for accessing a content (Ccap) in order to explain the properties of the model.
Figure 1: Authorization domain overview
During an installation phase, the SA generates for each document in the domain a list of capabilities which corresponds to the document's outgoing links to other nodes. The SA may follow a capability association policy to evaluate whether a capability should be associated with a link. For example, the policy could specify that only links going to children nodes should be taken into account. The SA installs these lists in the node servers that handle the corresponding documents. Moreover, the SA generates a list of capabilities that grant access to the root documents and installs it in the AUS. As the SA is the only entity that can generate new node capabilities, capability control and validation is greatly simplified. A node can be shared among different documents by associating capabilities for that node to those documents.
During a consultation phase, clients acquire nodes and capabilities. The AUS grants clients delegated capabilities for accessing root documents. Document servers grant clients documents and delegated versions of the corresponding lists of capabilities.
The AUS is the only server in the domain that needs to know its potential clients in order to authorize the granting of a capability for a root document. Node servers do not need to know their potential clients; they just require that their clients present appropriate capabilities to be able to authorize the node requests.
A capability includes attributes that allow a node server to validate it locally without needing to consult an additional server. In this way, a node request only involves one server.
The capability assignation scheme imposes a sequential order for document consultation. Section 5 describes a group extension to the model which allows a non-sequential access to nodes.
The rest of this section describes the assumptions taken in the environment, the properties of capabilities, the message exchanges during the consultation phase, and the limitations of the model.
We assume that in an authorization domain:
This section briefly describes the format, generation, delegation, and revocation of capabilities. A previously published article [8] describes further in detail these properties.
We based the format of the capabilities on that of the privilege attribute certificates (PAC) defined by the standard ECMA-138 [7]. According to this standard, a capability is generated by a grantor which then sends it to a grantee. Protection of a capability against its unauthorized propagation is achieved by including the grantee's identity inside the capability and requiring grantee authentication during the authorization process. Protection of a capability against its unauthorized use with another target is achieved by including the target's identifier inside the capability. Protection of a capability against its unauthorized modification and forgery is achieved by having the grantor server sign the capability.
Table 1: Capability attributes
Table 2: Delegated capability attributes
Table 1 shows the different attributes of a capability. Both the AUS and document servers grant capabilities by means of a delegation operation [15][17][23]. Table 2 gives the attributes of a delegated capability. A grantor server proves its right to delegate a capability by signing the delegated capability. A node server can verify this signature using the capability's grantor server identifier attribute. In this way, delegated capabilities can self-authenticate grantor servers.
Table 3: Authorizator attributes
A delegated capability's authorizator attribute is a special capability that the AUS generates when delegating a root document capability (Table 3). The authorizator's grantee identifier attribute (GIA) specifies the identity with which a client must authenticate itself when using the delegated capability. For instance, the value of the GIA could be an IP network address or a public key [15]. The authorizator's validity period attribute indicates the lifetime of a delegated capability.
The AUS is the only domain entity that can generate authorizators. Two reasons lie behind this choice. Firstly, this restriction removes the risk of having a compromised server assign unauthorized lifetimes to its delegated capabilities. Secondly, this restriction diminishes the risk of having a compromised server grant delegated capabilities to an unauthorized client.
During a session, a node server propagates the authorizator from the delegated capability associated with a request to the capabilities it will delegate. As there is only one authorizator per consultation session, the authorizator's validity period attribute also indicates the total time available to a client for consulting a presentation tree.
As with all capability-based systems, revocation of capabilities is a major issue. The validity period attributes, together with the global clock, guarantee the revocation of capabilities. Moreover, the different identifier attributes can be used to revoke capabilities before their validity expires.
This phase comprises three different protocols which allow a client to retrieve a capability for a root document, a document, and a content respectively.
In the following protocols, we use the terms Request-Node and Response-Node as a shorthand notation for the actual information retrieval protocol data units used by WWW. Moreover, capabilities are distinguished from the WWW protocol data units. Finally, we show the client authentication process as a separate protocol step. The above conventions help illustrate the properties of the protocol and should not be seen as implementation guidelines.
Table 4: Root document capability retrieval
Retrieval of a root document capability. This protocol is as follows (Table 4):
1. The client first requests a root document capability from an
authorization server. According to the security policy of the AUS, the
client may need to include additional authorization information, such
as a password or another capability. The model does not specify the
type or values of this parameter.
2. In order to authorize the request, the AUS may use
the client's authorization information, the URL of the document
document, and any other additional security information which the AUS may have on the client. Having authorized
the request, the AUS generates an authorizator and delegates the
requested capability. Finally, the server returns the delegated
capability to the client (we distinguish delegated capabilities with a letter
"D" prefix).
Table 5: Document retrieval
Document retrieval. This protocol allows a client to retrieve a document and the document's associated list of capabilities (Table 5):
1. The client first authenticates
to the document server according to the value of the GIA.
2. The client then requests the document adding the appropriate capability to the request.
3. The document server authorizes the request by verifying the integrity
and validity of the delegated capability. Moreover, the server compares the authenticated
client's identity against the value of the GIA.
Having authorized the request, the document server uses the authorizator from the client's
delegated capability to delegate the list of capabilities associated to the requested
document. The server then returns the document and
the delegated capabilities to the client.
Table 6: Content retrieval
Content Retrieval. This protocol is similar to the preceding one with the exception that no delegated capabilities are returned to the client (Table 6). Indeed, contents do not have links to other nodes.
This section describes how the model may support two existing node migration techniques: node migration by redirection [4], and node migration by use of Uniform Resource Names (URNs) [18][21]. We assume that the reader is familiar with both techniques.
Table 7: Node redirection support
In this method, a migrating node leaves a URL for its new location together with a capability for accessing it on the new server (Table 7):
1 and 2. A client requests a protected document from document server 1.
3. Document server 1 replies with the document's new URL
and a delegated capability for accessing the document at its new
location.
4, 5 and 6. The client then uses this capability to request the document
from server 2 as described in a precedent section.
A limitation of this method is that each time a node migrates, the retrieval protocol is increased by the first three protocol steps. This is not practical when nodes migrate frequently from one server to another. Another limitation is an increase of the trust placed on content servers: content servers can now grant access to other content servers.
A URN is a logical reference to a node. Name servers provide a resolution of URNs into URLs. This scheme can be integrated into the model by defining a URN capability type that, instead of granting access to a node, grants access not only to a node's URL but also to an appropriate capability for requesting that node. Document servers now store URN capabilities along with documents. Name server store node capabilities along with the URLs.
Table 8: URN support
The protocol is as follows (Table 8):
1 and 2. A client requests a protected document from the document server.
3. The document server returns a delegated list of URN capabilities
and the document.
4 and 5. Before retrieving a document, the client contacts
the name server to find the document's URL. As with a node request, the
client must authenticate itself to the name server and present an
appropriate capability.
6. Having authorized the request, the name
server returns the URL and a delegated version of the corresponding
capability.
A limitation of this method is that both content and name servers must be trusted as they can grant access to other servers. Note that with this method, a client always executes the same number of protocol steps to retrieve a node, regardless of how many times the node has migrated.
The group extension supports non-sequential access to nodes. Figure 2 shows the modifications to the authorization model.
Figure 2: Group support overview
In this extension, each node is associated with an ACL. Each entry of the ACL is a double-tuple which includes a group name and the access rights that the group has over the node. Group names correspond to presentation trees. Thus, all the nodes used in a presentation tree have the same group entry. On the other hand, the entries of a node's ACL correspond to all the presentation trees that use that node. In order to retrieve any of the nodes used in a presentation tree, a client needs to join a group capability (Groupcap) to its node requests. A group capability, which is granted by the AUS, gives a client access to a presentation tree for a given time. The format of this capability is the same as the one shown in Table 1, but includes a group name instead of a node identifier.
Table 9: Group extension protocol
The message exchanges for this protocol are similar to those described in Section 3.4 (Table 9). Document servers do not have to delegate capabilities as the client only needs one group capability to access any node of the tree. To authorize a node request, node servers not only have to validate the capabilities, but they also have to validate the capability and the request against the node's ACL. The group extension is independent of node migration techniques as it merely requires that a migrating node's ACL migrate too.
We shall now discuss how this extension affects the limitations of our model. As a document server no longer delegates capabilities, the compromise of such a server does not affect other node servers. This authorization method is faster than the preceding one as it only requires one delegation operation. A client wishing to follow a bookmark link to a document still needs an appropriate capability. Once the capability expires, the client just needs to acquire a new group capability to reuse the bookmark link. This authorization scheme still requires the evaluation of the client consultation time for a presentation tree. Node migration support does not place any additional trust in content servers or name servers.
The principal limitation of this extension is that each presentation tree needs to have a unique identifier. Another limitation is that the inclusion of an existing node into a presentation tree requires the updating of the node's ACL. Finally, searching a node's ACL may be cumbersome if the node is a component of several presentation trees.
This section describes the principal choices and problems we have encountered while implementing the model. [9] describes the implementation in further detail.
In order to validate the concepts of the model, we have developed a prototype of it which includes the node redirection support and the group extension. We chose to build the prototype on NCSA's WWW client (Mosaic 2.4) and server (httpd 2.3) as this system proposes hooks to a PGP/PEM enciphering layer [16]. We used these hooks to "plug-in" an authorization layer to the system. This allowed us to quickly arrive at a working prototype.
The prototype uses the technique described in [15] to implement self-authenticating capabilities. Asymmetric keys are used to sign capabilities as well as to authenticate the grantor servers. The AUS's and SA's public keys are distributed to the node servers during the installation phase. The public keys of grantor servers are used as the value of the capabilities' grantor server identifier attribute, and are thus distributed inside the capabilities. Grantor servers use their private keys to sign the capabilities which they delegate as proof of their identity. Thus, each delegated capability contains the signature of a grantor server and the public key which allows to verify the signature.
A similar technique is used to authenticate clients. Clients uses their private keys to sign every request they make. When a client requests a capability from the AUS, the client includes in the request its identity and the root document's URL. In order to authenticate the client, the AUS must retrieve the client's public key from a local file or from a key certification center. Having authorized the request, the AUS creates an authorizator using the the client's public key as the value of the GIA. As the client's public key is distributed inside the authorizator, node servers can authenticate the client without having to contact other servers.
The above technique can be modified to minimize the use of a client's public key. In this variation, the AUS creates a session asymmetric key pair and uses the session public key as the value of the GIA. The AUS first enciphers the session private key using the client's public key and then sends it together with the delegated capability to the client. Thereafter, the client uses the session private key to sign its requests. The session key pair remains valid during the lifetime of the authorizator.
To exchange capabilities between clients and servers, we added a header to the HTTP messages. The drawback of this method is that the client had to be modified so that it could add and remove capabilities to and from messages. [3] proposes an alternative method whereby capabilities are exchanged inside documents. In this method, document servers embed each of a document's delegated node capabilities into their corresponding node's URLs before returning the requested document. The advantage of this method is that clients do not need to be modified: clients use augmented URLs in the same way as they use normal URLs. The drawback of this method is that document servers must parse each requested document.
A problem we have come across with the implementation of the group extension is that clients acquiring more than one group capability cannot tell which one they must use. As the implementation effectuates all authorization exchanges on the HTTP level, the documents do not provide any hint as to what group capability a client should present when following a link. As a consequence, clients have to try their group capabilities one after another until they score a hit. A solution to this problem is to have node servers return unauthorized messages which list all the group names associated with a node. This solution is not practical because popular nodes may be used in several presentation trees. Moreover, clients have to waste a transaction to find out which capability they must use. Another solution is to modify the client so that it remembers which group capability it used when it successfully followed a link. In this way, the client can use the same group capability when following other related links.
This section briefly mentions related work that has been done in the area of coordinated WWW distributed authorization.
DCE Web [14][13] is an on-going project to marry OSF's Distributed Computing Environment with WWW. DCE Web adds to WWW the advantages of DCE security, which include distributed authentication, consistent group administration across a domain, protection of nodes with ACLs, and remote administration of ACLs. Client authentication is implemented using a conventional key trusted third party scheme derived from Kerberos [22]. Rather than having each server define its own groups, groups are handled by the same third party which handles user authentication. The authentication credentials, which a user retrieves to contact a server, include the user's group attributes. Although DCE Web does not explicitly support coordinated authorization for distributed documents and contents, it provides several tools that can be used to reach that goal. For example, DCE Web's group support can be used to implement our model's group extension using a conventional key cryptosystem.
The Phoenix project [12] is a distributed hypermedia authoring system which integrates access control information to hypermedia documents. Documents are protected by means of ACLs; however, instead of storing the documents together with the ACLs, each document includes an HTML mark-up element that giving the URL of an ACL. To authorize document requests, a document server sends the requested method, the ACL URL reference, and the authenticated client-name to an authorization server. The authorization server retrieves the ACL, searches it for an adequate entry, and returns the authorization result to the document server. Authorized users can change both the ACL and the links that point to it in a remote fashion. Phoenix can support coordinated authorization by having different documents share the same ACL. We were not able to find out how Phoenix protects contents or other non-html objects. Compared with Phoenix, our model protects documents without needing to modify them. Authorization in our model is handled locally by each node server whereas Phoenix uses a centralized authorization server. In our model as well as in Phoenix, only one server needs to know its potential clients.
Hyper-G [2][10] is a second-generation, large-scale distributed hypermedia system which uses an object-oriented database layer to provide, among other features, information-structuring and link-maintenance facilities, as well as a hierarchical access control scheme. Contents are stored outside of the database. Access can be restricted to contents, documents, and presentation trees to certain groups of users. Hyper-G also supports the modification of the database by authorized clients. A Hyper-G system comprises a link server and a collection of content servers. The link server is responsible for handling the database and authorizing the client requests. In a typical session, a client authenticates itself to a link server and then sends its node requests to it. Requests can be either for information contained in the database or for contents. In the latter case, it is the link server, and not the client, which contacts the content server and instructs it to send the contents to the client. Both our model and Hyper-G provide authorization at both the presentation tree and document levels. Hyper-G's use of a centralized server allows it to provide an even finer level of authorization granularity. Moreover, the use of a centralized server provides a practical client and database administration. Our model uses a distributed authorization approach. Although our model simplifies client administration, it presents problems when trying to revoke capabilities before their validation period expires. In both models, only one server needs to know its potential clients.
Sessioneer [3] is a recently proposed framework which is close to our authorization model. Sessioneer uses certificates (similar to capabilities) to control access to documents. Clients authenticate once when retrieving a root document. Document servers parse each requested document and embed certificates into the document's outgoing node links. Clients automatically use those certificates when traversing a link. Although some possible attributes of certificates are cited, such as the client's identity, client's IP address, and time stamps, Sessioneer leaves the definition of a certificate format to the applications. This model does not require any modification of clients nor servers. As in our model, user annotations have a limited life. Our model defines a more specific capability format in order to reach the goal of distributed authorization. It should be possible to combine both approaches in order to enjoy the advantages of each.
We believe that supporting coordinated authorization for distributed documents and contents is an important issue for WWW systems as it will not be always possible to store everything in a single server. By storing nodes according to their types into specialized servers, the overall workload of the system will be better balanced.
We have presented an authorization model that provides coordinated, distributed authorization at the presentation tree and document levels. The use of capabilities as an access-control mechanism simplifies the administration of clients and distributes the authorization process among different node servers. The model provides both sequential- and non-sequential access modes. The model supports existing WWW node migration techniques. We also explained choices we have made and problems we have encountered while building a prototype of the model. Some solutions to those problems were also proposed.
We believe that our authorization model can be used to protect access to persistent presentation trees when the client population changes at a fast rate; for example, an electronic public library where a client buys access for a limited period.
Other authorization approaches use centralized authorization servers which are consulted each time a client requests a node. A deeper comparison of both distributed and centralized authorization approaches is necessary to know in what situations each one might be better used.
The author sincerely thanks the Program Committee of INET'95 for their financial support for publishing and presenting this paper. This work was financed by a grant from CONACyT, a Mexican public institution, and the CCETT, a France Telecom joint research center for broadcast and telecommunications.
José Kahan is a PhD candidate in Computer Science at the Université de Rennes I (France). He is working on authorization issues and models for distributed hypermedia consultation services. He holds a specialization degree in Computer Networks from the Ecole Supérieure d'Electricité (France), and a degree in Electronics Engineering from the Universidad Autonoma Metropolitana-Azcapotzalco (Mexico).
Author contact (expires October 1995):
CCETT AMS/ARM
4, rue du Clos-Courtel BP 59
35512 CESSON-SEVIGNE CEDEX
FRANCE