CS 502 Computing Methods for Digital Libraries Cornell University Computer Science Herbert Van de So - PowerPoint PPT Presentation

About This Presentation
Title:

CS 502 Computing Methods for Digital Libraries Cornell University Computer Science Herbert Van de So

Description:

1. herbert van de sompel. CS 502. Computing Methods for Digital ... authenticity. Attributes. Authentication. Roles. Permitted. Operations. Laws and. agreements ... – PowerPoint PPT presentation

Number of Views:73
Avg rating:3.0/5.0
Slides: 26
Provided by: wya54
Category:

less

Transcript and Presenter's Notes

Title: CS 502 Computing Methods for Digital Libraries Cornell University Computer Science Herbert Van de So


1
CS 502 Computing Methods for Digital
LibrariesCornell University Computer
ScienceHerbert Van de Sompelherbertv_at_cs.cornell.
edu
Lecture 18 Cross-organizational authentication
authorization
2
Users
Authentication
Access
Roles
Policies
Authorization
Attributes
Digital objects
3
Users and roles theory
X
4
Users and roles practice
policy related limitations
5
Users and roles practice
authentication role
policy related limitations
6
Users and roles practice
collection
policy related limitations
policy related privileges
7
Library Interoperability nightmare re access
management
8
Library Interoperability nightmare re access
management
authorizations related to librarys subscriptions
libraries try to make the process opaque to users
library
9
Library Interoperability nightmare re access
management
10
Common access control approaches by Info Providers
  • IP-address based
  • IP address of the user requesting access is
    checked with IP range of subscribing institutions
  • browser-side authentication
  • Info Providers web server prompts the users
    browser for username/password

11
WWW-Authenticate
see http//www.modperl.com/book/chapters/ch6.html
12
Common access control approaches by Info Providers
  • IP-address based
  • IP address of the user requesting access is
    checked with IP range of subscribing institutions
  • browser-side authentication
  • Info Providers web server prompts the users
    browser for username/password
  • application-based authentication
  • Info Providers web application prompts the
    users browser for username/password

sometimes a combination of IP address and
authentication
13
Common access control approaches by Libraries
  • if Info Provider
  • application-based authentication
  • Info Providers web application prompts the
    users browser for username/password
  • then Library (and user)
  • is in big trouble
  • list passwords in library gateway
  • protect the passwords from outsiders
  • but what if users try and access the resource
    directly (not via library gateway)?

considered very bad practice only for
added-value services (personalization)
14
Common access control approaches by Libraries
  • if Info Provider
  • browser-side authentication
  • Info Providers web server prompts the users
    browser for username/password
  • then Library
  • can include username password in connecting URL
    in the library gateway or linking server (SFX)
  • http//userpass_at_www.nogood.com/resource.htm
  • but what if users try and access the resource
    directly?
  • top-level links can be bookmarked

15
Common access control approaches by Libraries
  • if Info Provider
  • IP-address based
  • IP address of the user requesting access is
    checked with IP range of subscribing institutions
  • then Library
  • is somehow OK regarding local (campus-based)
    access
  • but
  • communication of IP address range to info
    providers
  • conflict with regional caching proxies
  • dynamic IP addressing
  • off-campus access proxies (in IP-range)
  • proxy configuration in users browser
  • rewriting proxy
  • proxy will require authentication

16
its a big mess
17
Solution?
  • Cross-organizational authentication and
    authorization efforts
  • users from multiple higher education
    institutions
  • users accessing multiple information providers
  • Shibboleth (Internet 2) - http//middleware.inter
    net2.edu/shibboleth/

Digital Library Authentication and Authorization
Architecture (DLA3) (Digital Library Federation,
David Millman 1999)
18
DLA3 general
  • single approach for
  • authentication
  • (certificates)
  • authorization
  • (instit. LDAP)

19
DLA3 design principles
  • privacy
  • no information identifying an individual should
    be exchanged with the information provider
  • it is enough for the information provider to
    know that an pseudo-anonymous individual is an
    authorized user from a subscribing institution
  • partitioning of information maintain admin
    information where it belongs at the institution
    (cf SFX/OpenURL)
  • minimize institution-specific information at
    info provider
  • institution knows its users, knows which types
    of users have which level of access,
  • separate authentication from authorization
    different members of institution can have
    different access rights

20
DLA3 key architectural components
  • authentication
  • user has X509 certificate (delivered by
    Certification Authority) (see http//www.youdzone.
    com/signature.html)
  • user will be requested to submit certificate to
    information provider when trying to access
  • X509 certificate certificate contains
  • information to reveal the users institution to
    the information provider
  • an extension field query URL which leads into a
    record for the accessing user within the
    institutional authorization LDAP server (cf. SFX)

21
DLA3 authentication
HTTP
authent
22
DLA3 key architectural components
  • authorization the institutional authorization
    LDAP server
  • an entry in the LDAP server contains triples
    ServiceClass
  • Vendor defined by IP jstor.org , oclc.org ,
  • Service Name defined by IP jstor/ ,
    FirstSearch ,
  • ServiceType defined by IP, accorded to user by
    institution berkeley.edu , 100053231

23
DLA3 key architectural components
  • authorization continued
  • information provider
  • reads query URL from certificate extension
  • queries the institutional LDAP authorization
    server
  • this query requires the information provider to
    authenticate itself with the LDAP server
  • the institutional LDAP server
  • knows accessing user (query URL)
  • knows the information provider the user is
    trying to access (authentication)
  • sends back ServiceClass entries for current
    user, corresponding with the information provider
    the user is accessing
  • information provider compares ServiceClass with
    policies restricting access to information the
    users wants to access

24
DLA3 authorization
HTTP
authent
25
DLA3 some considerations
  • pro
  • generic model
  • privacy
  • administration of authorization in distributed
    resources done by institution
  • definition of authorization levels by
    information providers
  • tie in with SFX/OpenURL BASE-URL of service
    component
  • con
  • deployment seems problematic due to use of
    certificates
  • for servers
  • for clients (users)
  • administration
  • portability
  • shared workstations
Write a Comment
User Comments (0)
About PowerShow.com