Figure 1: An authorization domain
e-mail: kahan@ccett.fr
The World-Wide Web (WWW) organizes networked information into sets of hypertext documents [Ber94b]. A hypertext-document mainly comprises links to media contents, links to other documents, and rules precising the presentation of contents and the traversal of links. We refer to a set of inter-linked documents and nodes as a presentation tree. We refer to the entry point of a presentation tree as a root document. In addition, we use the term node to refer to either a document or a content.
The nodes of a presentation tree can be stored in one or more servers. In the WWW information retrieval cycle, a client first retrieves a root document from a document server. In function of the document's structure and the user's actions, the client then follows the document's links to retrieve other contents and documents from the same server or from other servers.
One of the major requirements for authorization in the WWW is to provide the means to allow access by certain known users as well as to restrict access by these users to specific nodes, independently of the location of the nodes. We can view access-granting from three point of views: the node level, the document level, and the presentation tree level. Authorization at the node level is done independently of the node's status in a document or in a presentation tree. If the node is a document, granting access to it does not grant access to the nodes that correspond to the document's outgoing links. Authorization at the document level involves the granting of access to the document and to the nodes that correspond to the document's outgoing links; for example, granting access to linked media contents. Authorization at the presentation tree level involves the granting of access to all the nodes that compose a presentation tree.
A minor requirement for authorization in the WWW is that it must be flexible enough so that it is not affected by eventual node migration [Ber93] from one server to another. User's rights to an object must migrate together with the object.
The existing proposals for authorization on the WWW [Luo95, Lew94] are based on access-control lists (ACL) [San94]. An ACL is associated to each of the nodes controlled by a node server. Each entry of a node's ACL is a tuple that comprises a client's identity and the access rights that the client has over the node. For each node request, the server compares the authenticated client's identity against the object's ACL, granting the access if the client has an entry in the list and if the entry comprises the requested access mode. Node migration is supported provided that the node's ACL migrates too.
These approaches present a limitation when the nodes are stored in different servers: changing a client's access rights at either the presentation tree or document levels requires a coordinate updating of the ACLSs of all the involved nodes. This updating operation could become an administration bottleneck if the status of clients changes very often.
The capability-based authorization model is designed to provide distributed authorization at the presentation tree and the document levels independently of the distribution of the nodes. The model groups node servers into authorization domains. The node servers condition access to their nodes to the presentation of appropriate capabilities [San94]. Clients acquire capabilities in two ways: from an authorization server and from document servers. The authorization server grants clients delegated capabilities for retrieving root documents. Document servers grant clients delegated capabilities that correspond to a requested document's outgoing links to other nodes.
In comparison to the ACL-based authorization schemes, the model simplifies the administration of clients: all access granting and revocation operations are done at the authorization server. Indeed, without an initial capability, a client will not be able to access any node in a presentation tree. Thus, only the authorization server may eventually need to know its potential clients. However, to achieve this simplification , the model requires an additional transaction to an authorization server, an increase of the level of trust placed on some of the node servers, and a scheme for revoking delegated capabilities.
Section 2 describes the capability-based authorization model. Section 3 introduces extensions to the model in order to support node migration and groups. Section 4 presents an overview of a prototype of the model. Section 5 concludes this paper.
The model comprises the grouping of node servers into authorization domains, an installation phase where capabilities are generated, and a consultation phase where clients retrieve and present capabilities. We will now describe more in detail these phases, the properties of capabilities, and the limitations of the model.
An authorization domain represents a group of servers that enforces an authorization policy [ECM88]. This section describes the entities found in a domain and the assumptions that the model takes on the environment.
Figure 1: An authorization domain
An authorization domain comprises a security administrator (SA), an authorization server (AUS), and several node servers (Figure 1). The SA is an off-line server that generates capabilities for documents (Dcap) and contents (Ccap) and transmits them to the other servers in the domain. The AUS stores and delegates capabilities for accessing root documents. Document servers store and delegate lists of capabilities associated to the documents they manage. In addition, node servers control that clients present appropriate capabilities before granting access to their nodes.
We assume that in an authorization domain:
For each document in the domain, the SA generates a list of capabilities that corresponds to a document's outgoing links. The SA then transmits these lists to the document servers that manage the corresponding documents. In addition, the SA generates another list of capabilities for accessing the root-documents and sends it to the AUS.
The SA may follow a capability-assignation policy to evaluate if it must or not associate a capability to a document's link. The policy may take into account, among other factors, the consultation context, the document's presentation tree, the type of servers that store the nodes, and the information contained in the nodes. For example, let us consider a presentation tree where the documents keep a hierarchical order. A possible assignation policy for this tree is to assign capabilities only to the links going to children documents.
The SA is the only entity that can generate new capabilities. This simplifies the control and the validation of capabilities.
In this phase, clients consult different servers in an authorization domain to retrieve capabilities and nodes. Servers grant capabilities to clients by means of a delegation operation (cf. Section 2.4).
Step Direction Message
1.1.1 Client to AUS: ReqRootDcap +
[authorization information]
1.1.2 AUS to Client: RepDDcap
1.2.1 * Client to Document Server: ReqDocument + DDcap
1.2.2 Document Server to Client: RepDocument + {Dcap}+ {Ccap}
1.3.1 * Client to Content Server: ReqContent + DDcap
1.3.2 Content Server to Client: RepContent
Table 1: Message exchanges during the consultation phase
Table 1 summarizes the message exchanges between a client and the domain's servers. The messages are grouped into sets of requests and replies. The capability validation operation requires that a client authenticates itself when presenting a capability to a node server. We add a ``*" symbol to the message exchanges that require this authentication. Moreover, we distinguish delegated capabilities by prefixing them with a ``D'' letter.
First a client requests a capability for a root document from an AUS (1.1.1). In function of the AUS's authorization policy, the client may need to include in its request additional authorization information. This information is implementation dependent; for example, the authorization information could be another capability, a Kerberos ticket [Ste88], or a password. The model does not specify the type or values of this parameter.
Having authorized the request, the AUS delegates the appropriate root-document capability and then sends it back to the client (1.1.2). The client includes this capability in its request for a root document (1.2.1). If the capability is valid, the document server delegates the document's list of capabilities. The server then sends the delegated list and the root document to the client (1.2.2). In function of the document's structure and the user's actions, the client uses the delegated capabilities to retrieve other contents (1.3.1-1.3.2) and documents (1.2.1-1.2.2). Note that there is no difference between the retrieval of a root-document and that of another document.
When it does not possess a capability for a document, the client must contact the AUS that belongs to the same domain as that document. The client can be informed of the AUS network address by means of a special error message, such as the one that HTTP uses to indicate lack of authorization [Ber93].
Up to now we have described how the entities of the domain exchange capabilities between themselves. This section briefly describes the format, generation, delegation, and revocation of capabilities. A previously published article [Kah94] describes further in detail these properties.
We based the format of the capabilities in that of the privilege attribute certificates (PAC) defined by the standard ECMA-138 [ECM89]. Following this standard, capabilities are protected against their unauthorized modification and use by inclusion of the grantor's signature and the grantee's identity, respectively. The second type of protection also requires the authentication of the grantee.
attribute description
Node identifier Unique identifier of the node in the
authorization domain; e.g., a URL.
Access rights Rights that the capability confers
over the node.
Validity period The lifetime period of the capability.
Capability identifier Unique identifier for the capability.
Grantor server The server that can delegate
this capability.
SA identifier The SA that generated the
capability.
SA seal A digital signature on the capability
by the SA.
Table 2: Capability attributes
Table 2 shows the different attributes of a capability. In our model, both the AUS and document servers grant capabilities by means of a delegation operation [Var91, Neu93, Low94]. Table 3 gives the attributes of a delegated capability. The grantor server and grantor server seal attributes allow delegated capabilities to self-authenticate the grantor servers.
attribute description
Capability cf. Table 2.
Delegated access rights Subset of the capability's access rights
that the delegated capability grants.
Authorizator cf. Table 4.
Grantor server seal A digital signature on the delegated
capability by the grantor server.
Table 3: Delegated capability attributes
A delegated capability's authorizator attribute is a special capability that the AUS generates when delegating a root-script capability (Table 4). The authorizator indicates the identity with which a client must authenticate itself when presenting a delegated capability. In function of the domain's authentication services, the value of this attribute could be an internet address, a password, or a public-key [Low94]. The authorizator's validity period attribute indicates the lifetime of a delegated capability. As during a session an authorizator is propagated to all delegated capabilities, the value of this attribute indicates the total time a client has for consulting a presentation tree.
attribute description
Client identifier Identity of the grantee client.
Validity period Lifetime of the authorizator.
Authorizator identifier Unique identifier for the authorizator.
AUS identifier The AUS that granted the authorizator.
AUS seal A digital signature on the authorizator
by the AUS.
Table 4: Authorizator attributes
The model supports five capability-revocation techniques: revocation by time, revocation by capability identifier, revocation by client and node identifiers, and revocation by node identifier.
This section briefly describes the main limitations of our authorization model.
Document server vulnerability. As a document server can delegate capabilities, the infiltration of this kind of server may affect other node servers.
Eventual lack of performance. To validate a delegated capability, a node server needs to verify three seals: the SA's seal of the capability, the AUS's seal of the authorizator, and the grantor server's seal of the delegated capability. When requesting a document, one must add to the validation time, the time needed to delegate the document's associated list of capabilities.
Regeneration of capabilities. Whenever the validity period of a capability expires, the SA must regenerate that capability. Moreover, if the SA's seal is compromised, the SA must warn all of the node servers belonging to its domain and regenerate all of the existing capabilities.
Order of consultation. If a client wishes to retrieve a document that is inside a presentation tree, the capability-assignation scheme constrains the client to request the root document and to follow the tree's structure to reach the desired document. This limitation may be partially avoided by having the AUS grant capabilities for different documents belonging to a same presentation tree.
Evaluation of client consultation time. The authorizator indicates the total time that a client has for consulting a presentation tree. However, it is not simple to give an estimation of this time: one must consider the workload of the node servers and the network, the user idle time, ... If the authorizator validity period is not correctly evaluated, a client may not be able to travel to all the nodes belonging to a presentation tree.
This section describes the following extensions to the model: node migration by redirection [Ber93], and group support, an alternate method of authorization.
Step Direction Message
2.1.1 * Client to Document Server 1: ReqDocument + DDcap
2.1.2 Document Server 1 to Client: RepRedirection + DDcap
2.2.1 * Client to Document Server 2: ReqDocument + DDcap
2.2.2 Document Server 2 to Client: RepDocument + {DDcap} + {DCcap}
Table 5: Support of node redirectionTable 5 shows a method to take into account this migration technique. When a document migrates from document server 1 to document server 2, it leaves, together with its new URL, a capability for accessing it on server 2. A client requests the document from document server 1 in the usual way (2.1.1). Document server 1 answers back with the redirection message and a delegated capability for accessing the document at server (2.1.2). The client then uses this capability to request the document from server 2 in the usual way (2.2.1-2.2.2). This scheme is the same for content migration.
Figure 2: Group support overview
The group support extension allows to remove most of the limitations of the authorization model. Figure 2 shows the modifications to the authorization model.
In this extension, each node is associated with an ACL. Each entry in the ACL is a tuple that stores a group name and the access rights that the group has over the node. Group names correspond to presentation trees. Thus, all the nodes of a given 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.
Step Direction Message
3.1.1 Client to AUS: ReqGroupcap +
[authorization information]
3.1.2 AUS to Client: RepDGroupcap
3.2.1 * Client to Document Server: ReqDocument + DGroupcap
3.2.2 Document Server to Client: RepDocument
3.3.1 * Client to Content Server: ReqContent + DGroupcap
3.3.2 Content Server to Client: RepContent
Table 6: Group consultation phase
Table 6 shows the modifications to the consultation phase. First, a client requests the AUS a group capability for a given presentation tree (3.1.1). The client's request still includes authorization information that allows the AUS to authorize the request. If the request is valid, the AUS answers back with a delegated group capability (3.1.2). This capability has the same format as a delegated capability but uses a group name identifier attribute instead of a node identifier attribute. For each node request, the client presents the delegated group capability (3.2.1-3.3.2). During the validation process, node servers verify that the ACL of the requested node includes an entry corresponding to the capability's group name identifier and that the requested access is comprised in the entry's access rights. Support of node migration is the same as that described for the ACL schemes (cf. Section 1.2).
We now discuss how this extension changes the limitations of our model. As document servers do not delegate capabilities, compromise of such a server does not affect other node servers. This authorization scheme is faster than the precedent one as it only requires one delegation operation. A client can retrieve the nodes of a presentation tree in any order it wishes. This authorization scheme still requires the evaluation of the client consultation time for a presentation tree.
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 many presentation trees.
In order to validate the concepts of the model, we built a prototype of the model, the group extension, and the node redirection extension. We used as a base NCSA's WWW client (Mosaic 2.4) and server (httpd 1.3). This WWW system proposes an interface to an external PGP/PEM cryptographic layer [Mcca, Zim94] that provides peer-entity authentication, message integrity, and message confidentiality services.
Figure 3: A layer view of the prototype
To implement the client and node server components of the model, we decided to just insert an external authorization layer between the WWW and the PGP layers, reusing the existing WWW intra-layer interface communication (Figure 3). This allowed us to quickly arrive to a working prototype without having to make any major modifications to the WWW code. The authorization layer uses the PGP layer to delegate and validate capabilities and to authenticate clients. We implemented the SA as a simple program that reads a specification file and outputs capabilities lists. We implemented the AUS using the node server code and a form associated with a CGI script [Mccb].
There are two possible choices for notifying a client when access to a node requires a capability: define a special URL, or use an error reply message to indicate the lack of authorization [Ber93, Luo93]. We chose the latter because we wanted to have a compatibility with existing documents.
The prototype uses public-keys as the value of the server and client identifiers of the capabilities [Low94]. Grantor servers authenticate themselves to node servers by signing the delegated capabilities. Note that capabilities provide all the information a server needs to verify the different signatures. To authenticate clients, we use NCSA's implementation of PGP/PEM messages [Mcca] to encapsulate the request and reply messages. In addition, we slightly modified the PGP/PEM request message to include a copy of the client's public-key. Note that the client-authentication scheme can be replaced by a more complete one, such as S-HTTP [Res94], without affecting the authorization model.
** BEGIN DELEGATED CAPABILITY LIST ** **BEGIN DELEGATED CAPABILITY** /* Access rights and node's URL */ GET http://ihm2/auth_demo/cap_prot/mona_lisa.xpm /* Expiration date of the capability */ Fri Nov 10 18:16:13 1995 /* Identity of grantor server */ -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK----- /* Signature of the capability by the SA */ -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- /* Expiration date of the delegated capability */ Thu May 4 19:43:14 1995 /* Signature of the authorizator by the AUS */ -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- /* Signature of the delegated capablity by the grantor server */ -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- **END DELEGATED CAPABILITY** **END DELEGATED CAPABILITY LIST** /* Standard HTTP Reply */ HTTP/1.0 200 OK ...Table 7:HTTP reply message prefixed with a capability (abridged)
To exchange capabilities between clients and servers, we added a capability header to the HTTP request and reply messages. Table 7 shows an annotated reply message containing a document and one content capability. The highlighted attributes correspond to the authorizator. Note that the client's public-key is not found inside the authorizator because it is already included in the PGP/PEM message.
Scheme Mean time (s) ACL (1000 entries) 0.72 Capability (one delegation) 6.16 Group capability (1000 entries) 3.68Table 8: Server performance evaluation
Although performance was not an issue for our prototype, we made some measures on the server side [1]. The average times for delegating and verifying a capability were 2.3 s and 3.2 s, respectively. The verification operation is slower than the delegation one because it makes several file system calls. Table 8 compares the server overhead for processing a request for a document using the different authorization schemes. The document included a link and an associated capability. These measures do not take into account the user authentication process. As we can observe, the performance of the group capability scheme could approach that of the ACL scheme if the capability verification operation were improved. This is not possible for the standard capability scheme, as the server performance depends on the number of capabilities associated to each document.
Existing ACL-based authorization schemes for the WWW require that a node's ACL includes the identity of the clients that may retrieve it. This scheme presents presents a limitation when the nodes are distributed: access granting or revocation at the presentation tree and document levels needs the updating of the ACLs of all involved nodes.
The capability-based model simplifies the administration of clients as granting and revocation of access is reduced to controlling access to root-document capabilities stored at the AUS. Node servers control access to their nodes by requiring the presentation of a valid capability. In addition, document servers delegate capabilities that correspond to a document's outgoing links.
The model has some limitations: the revocation of delegated capabilities, the need to place a higher trust on document servers, the imposition of an order of consultation, the regeneration of compromised capabilities, and an eventual lack of performance. We proposed a group extension to the model to remove the first three constraints. This extension associates ACLs to each node, but instead of including the identity of the authorized clients, it uses the identity of the presentation trees that comprise the node. The AUS now furnishes clients capabilities that grant access to all the nodes of a presentation tree. The principal limitation of this extension is the need to have a unique identifier for each presentation tree.
The ACL-based schemes supports node migration provided that the ACLs migrate with the nodes. The capability-based model supports node migration by leaving a capability granting access to the new location of the node. The group-cabability extension supports node migration in a similar way to that of the ACL schemes.
We estimate 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.
Moreover, our model can also be used as a base for providing anonymous type access to a presentation tree: the value of the authorizator's {\tt client identifier} does not have to correspond to the real identity of a user. For example, the AUS may generate an asymmetric key-pair and communicate it to the client at the same time as the delegated root document capability.
In the short term, the security properties of the model need to be formalized and validated. In addition, more work on the prototype is necessary to find how to offer a performance closer to that of the ACL scheme. This could involve using smaller client public-keys and integrating the authorization layer directly into the WWW code.
We thank the reviewers of this paper for their helpful remarks. This work was financed by a grant from CONACyT, a mexican public institution, and the CCETT.