Flexible Security Policies for Digital Libraries Catherine D. McCollum,(1) Arnon Rosenthal,(2) and Barbara T. Blaustein(1) {mccollum@mitre.org, arnie@mitre.org, btb@mitre.org} (1) The MITRE Corporation 7600 Old Springhouse Rd. McLean, VA 22102 (2) The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 Digital libraries store and make available huge volumes of data in various media and storage formats, culled from many different authors or publishers. From a security perspective, digital libraries present many of the same problems as other distributed systems, and, in particular, federated database systems, in terms of heterogeneity and autonomy, but they also have some aspects not encountered elsewhere. One is that the libraries are offered to large communities of previously unknown users or may be entirely available to the public, provided that certain conditions, such as payment for services or execution of copyright agreements, are met. These conditions can vary from organization to organization and from one document to another (see, for example, [Abrams and Schneck]). Progress is being made quickly in areas such as identifying remote users in a large distributed system through authentication technologies and protecting the authenticity of stored and retrieved documents through encryption and digital signature technologies [Kaufman, Perlman, and Speciner]. However, existing security models [Pfleeger; Castano et al.] lack the flexibility to represent the range of release policies that may be required and base their enforcement on previous specification of the user's access rights. MITRE has developed an approach that adds history to the criteria considered in access and release policies. The AMULET approach allows enforcement of flexible policies by making access contingent on execution of specified procedures [Blaustein et al.]. AMULET provides three things: A means for maintaining evidence of an execution history's use of certified, trusted code, A means for specifying extra access privileges that can be earned on the basis of the history, and A means for managing temporary, selective privileges. AMULET policies can include arbitrary procedural controls, such as a requirement to capture document-dependent logging information or generate an invoice, in addition to more traditional types of access checks. These conditions, i.e., that permission to perform a particular access is granted provided a required procedure is followed or specified characteristics are checked, are defined in the form of registered procedures and registered exemptions. Any procedure that performs actions that might justify additional access privileges can be registered. For each process, AMULET maintains a provenance, a partial history of invocation of trusted procedures. That is, a process that invokes a registered procedure may specify that a record of this invocation (and return arguments), informally referred to as a "stamp," be included in the provenance. Both the provenance and the code of registered procedures are protected from tampering. Registered exemptions specify access predicates that are used with the provenance to determine whether the process deserves additional privileges, i.e., temporary, selective exemptions from access prohibitions that the resource manager would otherwise impose. An access manager may be invoked by a process that wishes extra privileges based on its security context (the provenance, user information, time of day, etc.). The access manager executes access predicates to determine whether the specifically-desired extra privileges should be granted. It then arranges for the privileges to be granted temporarily, for the duration of the current request. To avoid impacting existing code or execution speed, most requests go directly to the underlying resource manager; AMULET facilities (writing into the provenance, testing access predicates) are invoked only upon request from an application. Existing applications (whose source code may not be modifiable) are unaffected, but also receive no extra privileges. In some cases it may be possible to invoke AMULET by intercepting "access refused" exceptions and calls to registered procedures. Consider for example, a digital library of academic journal articles, administered by a digital publishing company (DPC). Each article has two parts: a header containing an abstract, title, and authorship information; and the complete body of the article. Users are permitted to browse the headers or perform keyword searches through the body of an article after paying a search fee to the DPC. To retrieve the body of an article, a user must pay a higher retrieval fee. This simple policy involves several key elements: (1) the ability to make access decisions based on prior execution of a required procedure, and (2) the ability to allow articles to be read on behalf of the user (for a full-text keyword search) without allowing the user to read or retrieve the article unless the full retrieval fee has been paid, and (3) access rights that do not depend on prior knowledge of the user's identity. Carrying out such a policy is awkward if one must rely on current resource managers. The shortfalls are threefold: Criterion for approval: Most current resource managers have only typical identity-based access controls. We want context-based control, that recognizes whether or not the payment action has been performed, and if so, which type of fee has been paid, in making its access or release decision. Protection of data granules: Many can protect only the storage granules declared to the storage manager. For example, if an entire document is stored in the same UNIX file, UNIX cannot differentially protect parts of it. Protection of function invocation: New privileged functions cannot easily be added in many resource managers -- one is limited to built-in privileges like Read and Write. Yet one might trust a search routine, for instance, to read full text but return only a relevance measure. (Object managers and object databases offer some hope in defining new privileges, but may tend to give privilege only for functions on the stored types.) With the AMULET approach, executing a "pay search fee" registered procedure would add a "pay search fee" stamp to the user's provenance; likewise, executing a "pay retrieval fee" or "acknowledge copyright" registered procedure would earn a specific stamp. In response to a request to retrieve an article, the AMULET access manager would review the stamps in the provenance, determine whether they qualify the request for an exemption, and forward the request to the resource manager to execute with additional privileges. The exemptions are specified as access predicates on the stamps in the provenance. Thus, for example, while the resource manager would be configured not to allow the user's process to read an article body ordinarily, the registered exemptions could be written to allow the read if: (1) the retrieval payment stamp has already been obtained, or (2) the search payment stamp and "keyword search" stamp have been obtained, i.e., the read occurs in the context of a registered procedure that performs the search but does not return the text to the user. While it would be possible to write an application that receives requests, finds the requested material and checks that the appropriate payments have been made before retrieving the articles and forwarding them to the user, its effectiveness depends on being the sole means of accessing the library contents. It is far preferable to support an evolving variety of interfaces with access and release controls that can be managed separately and applied generally. In digital libraries, interfaces may include anything from Web technologies to home-grown special-purpose interfaces. Resource managers may range from object databases and distributed object managers, to legacy text processing systems, to simple UNIX file systems, and may vary widely in the sophistication of their security and resource manager capabilities. AMULET can be used to superimpose a flexible policy with more sophisticated access controls or a finer granularity of protection upon such systems. AMULET is intended to be modular, able to work in any software environment. The client procedures merely need to be able to invoke the special certified procedures (such as payment transactions). Any resource manager can be used, so long as there is some way for the AMULET access manager to execute requests with added privileges. Summary We have described the requirement and solution approach for a flexible authorization approach that allows decentralized, history-based access and release policies. Controls can be based on execution context, such as actions taken, checks made, or access as part of particular functions, rather than just user identity. Through the use of the provenance, the details of the registered procedures are separated from the statement of protection goals in the access predicates. Finally, the controls can be managed separately from front-end interfaces, application logic, or resource managers, so that they can be applied across a variety of systems. REFERENCES [Abrams and Schneck] Abrams, M., and P. Schneck, "Another View," Communications of the ACM, Vol. 39, No. 8, August 1996, p. 27. [Blaustein et al.] Blaustein, B. T., C. D. McCollum, A. Rosenthal, K. P. Smith, and L. Notargiacomo, "Autonomy and Confidentiality: Secure Federated Data Management," Proc. of the 2nd International Workshop on Next Generation Information Technologies and Systems, Naharia, Israel, June 1995. [Castano et al.] Castano, S., M. Fugini, G. Martella, and P. Samarati, Database Security, Addison-Wesley, 1995. [Kaufman, Perlman, and Speciner] Kaufman, C., R. Perlman, and M. Speciner, Network Security, Prentice Hall, 1995. [Pfleeger] Pfleeger, C. P., Security in Computing, Prentice Hall, 1989. * This work was supported by the MITRE-Sponsored Research Program. (c) 1996 The MITRE Corporation. All rights reserved.