Title: CS 502 Computing Methods for Digital Libraries Cornell University Computer Science Herbert Van de So
1CS 502 Computing Methods for Digital
LibrariesCornell University Computer
ScienceHerbert Van de Sompelherbertv_at_cs.cornell.
edu
Lecture 18 Cross-organizational authentication
authorization
2Users
Authentication
Access
Roles
Policies
Authorization
Attributes
Digital objects
3Users and roles theory
X
4Users and roles practice
policy related limitations
5Users and roles practice
authentication role
policy related limitations
6Users and roles practice
collection
policy related limitations
policy related privileges
7Library Interoperability nightmare re access
management
8Library Interoperability nightmare re access
management
authorizations related to librarys subscriptions
libraries try to make the process opaque to users
library
9Library Interoperability nightmare re access
management
10Common 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
11WWW-Authenticate
see http//www.modperl.com/book/chapters/ch6.html
12Common 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
13Common 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)
14Common 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
15Common 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
16its a big mess
17Solution?
- 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)
18DLA3 general
- single approach for
- authentication
- (certificates)
- authorization
- (instit. LDAP)
19DLA3 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
20DLA3 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)
21DLA3 authentication
HTTP
authent
22DLA3 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
23DLA3 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
24DLA3 authorization
HTTP
authent
25DLA3 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