This website is no longer being maintained as of June 2010.
For current DLF information please go to: www.diglib.org
random quote Link: Publications Forum Link: About DLF Link: News
Search
Link: Digital Collections Link: Digital Production Link: Digital Preservation Link: Use, users, and user support Link: Build: Digital Library Architectures, Systems, and Tools
photo of books

DLF PARTNERS

  1. Bibliotheca Alexandrina
  2. British Library
  3. California Digital Library
  4. Carnegie Mellon University
  5. Columbia University
  6. Cornell University
  7. Council on Library and Information Resources
  8. Dartmouth College
  9. Emory University
  10. Harvard University
  11. Indiana University
  12. Johns Hopkins University
  13. Library of Congress
  14. Massachusetts Institute of Technology
  15. New York Public Library
  16. New York University
  17. North Carolina State University
  18. Oxford University
  19. Pennsylvania State University
  20. Princeton University
  21. Rice University
  22. Stanford University
  23. University of California, Berkeley
  24. University of California, Los Angeles
  25. University of Chicago
  26. University of Illinois at Urbana-Champaign
  27. University of Michigan
  28. University of Minnesota
  29. University of Pennsylvania
  30. University of Southern California
  31. University of Tennessee
  32. University of Texas at Austin
  33. University of Virginia
  34. University of Washington
  35. U.S. National Archives and Records Administration
  36. U.S. National Library of Medicine
  37. Yale University
""

DLF ALLIES

  1. Coalition for Networked Information (CNI)
  2. Inter-university Consortium for Political and Social Research (ICPSR)
  3. Joint Information Systems Committee (JISC)
  4. Los Alamos National Laboratory Research Library
  5. OCLC Online Computer Library Center
""

Comments

Please send the DLF Director your comments or suggestions.

Digital Library Authentication and Authorization Architecture

What it is

A secure, precise, standards-based, scalable mechanism, enabling information service providers both to guarantee the identity of institutional consumers (authentication) and to provide services based on the characteristics of individual consumers (authorization) while offering increased access, privacy, flexibility and richer management information to consumer institutions.

Information service providers may be traditional commercial vendors. They may also be our own institutions, enabling increased flexibility in inter-institutional transactions, e.g., federated collections.

Participants in the current DLF-sponsored pilot are the University of California (Office of the President), Columbia University, JSTOR and OCLC.

Motivation

a) Increasing problems associated with network topological (IP-address) methods

- no ISP (third-party dial-in) access to remote services

- security enforced only by physical location

- difficult/impossible to manage access for remote campuses using commercial Internet providers

- difficult for providers to implement services customized per individual

- poor management information for both providers and consumer institutions

- poor scaling properties, increasing labor to manage

b) Increasing problems with "proxy" methods

- impossible to implement newer services, e.g., those which build web addresses dynamically in the browser

- potential bandwidth bottleneck

- no management information for providers

- cache-based security violations possible for providers

c) Problems with remote user registration methods

- in opposition to strategies for single sign-on

- duplicate development work

- poor authentication

- poor management information for consumer institutions

d) Standards-based, trends promising

- certificate technology already standard in browsers

- e-commerce community positioning for certificate technology

- directory service standards increasingly part of other products (email, calendaring, enterprise-wide applications)

e) Feedback encouraging-increasing interest from higher-ed IT decision-makers

Architecture

1. Individual within consumer institution community, providing an individual digital certificate, requests service from remote provider;

2. Service provider validates authenticity of individual's issuing certificate authority, retrieves location of consumer institution's directory/attribute service from within individual's certificate, contacts that directory service-providing its own certificate as well-requesting authorization information for the individual;

3. Directory service validates authenticity of service provider's issuing authority, and responds to provider with appropriate classes of service permissible for the individual;

4. Service provider delivers appropriate service to the individual.

Design Principles

- privacy; user-specific information is kept entirely within the consumer institution

- localization of information; minimal information exchange, only what's precisely necessary for the transaction, no redundancy

- better management information on all sides

- better services possible; providers can create extensive user-profiled services with appropriate privacy

- separation between authentication and authorization systems; much more flexible classes of service are possible

Investments, per architectural component

a) for customer institutions

- certificate identity for servers

- directory service

- certificate infrastructure for individuals

b) for service providers

- certificate identity for servers

- web server extension module

History/Status

- 97-98; UCOP, UC System-wide security architecture; Columbia access management broker service

- Apr 98; Clifford Lynch white paper, issues in inter-institutional authentication and authorization; CNI discussion

- Oct 98; DLF Architecture Committee, identification of common practices

- Dec 98; CNI, UCOP/Columbia comparison presentation

- Jan 99; UCOP/Columbia/JSTOR/OCLC Pilot Launched

- Apr 99; Pilot operational

- Apr 99; CNI presentation

- May 99; CSG presentation

- Jun 99; CIC presentation

- Jun 99; Internet-2 presentation

- Oct 99; Educause presentation

- Publication with the Corporation for Research and Educational Networking (CREN) of FAQ

return to top >>