1 herbert van de sompel cs 502 computing methods for digital libraries cornell university –...

1 herbert van de sompel

CS 502 Computing Methods for Digital

Libraries

Cornell University – Computer ScienceHerbert Van de [email protected]

Lecture 18 Cross-organizational authentication & authorization


Users

Digital objects

Identification& authenticity

Attributes

Authentication

Roles

Perm

itte

dO

pera

tion

s

Law

s an

d

ag

reem

en

ts

Poli

cies

Authorization

InformationManagers Access


Users and roles: theory

au

then

tica

tion

roles-dbase

110010110101100101101010000

att

rib

ute

s

policy related limitations

roles

policy relatedprivileges

X

• access• permitted operations


Users and roles: practice

au

then

tica

tion

roles-dbase

110010110101100101101010000

att

rib

ute

s


roles


collection



au

then

tica

tion

110010110101100101101010000

att

rib

ute

s


roles


collectionauthentication = = role



au

then

& a

uth

or

110010110101100101101010000

att

rib

ute

s



collection


Library: Interoperability nightmare re access management

A&I

image

FTXT

OPAC

e-print multiple • authorization• authenticationprocesses

• implicit• explicit



A&I

image

FTXT

OPAC

e-print

au

then

& a

uth

or

library

authorizations related to library’s subscriptions

libraries try to make the process opaque to users



A&I

image

FTXT

OPAC

e-print


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 Provider’s web server prompts the user’s browser for username/password


WWW-Authenticate

see http://www.modperl.com/book/chapters/ch6.html


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 Provider’s web server prompts the user’s browser for username/password

• application-based authentication• Info Provider’s web application prompts the user’s browser for username/password

sometimes a combination of IP address and authentication


Common access control approaches by Libraries

if Info Provider• application-based authentication

• Info Provider’s web application prompts the user’s 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 user’s try and access the resource directly (not via library gateway)?

considered very bad practice only for “added-value” services (personalization)



if Info Provider• browser-side authentication

• Info Provider’s web server prompts the user’s browser for username/password

then Library• can include username password in connecting URL in the “library gateway” or linking server (SFX)• http://user:[email protected]/resource.htm• but what if user’s try and access the resource directly?

• top-level links can be bookmarked



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 user’s browser• rewriting proxy• proxy will require authentication


it’s a big mess


Cross-organizational authentication and authorization efforts• users from multiple higher education institutions• users accessing multiple information providers

• Shibboleth (Internet 2) - http://middleware.internet2.edu/shibboleth/

Digital Library Authentication and Authorization Architecture (DLA3)

(Digital Library Federation, David Millman 1999)

Solution?


DLA3: general

institution a

institution b

institution z

A&I

image

FTXT

OPAC

e-print

single approach for

•authentication(certificates) •authorization (instit. LDAP)


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


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 user’s 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)


DLA3: authentication

institution a

FTXT1. request content

HTTP2. request certificate

authent3. send certificate

4. check certificate

valid CA?

user member of sub inst?

valid certificate?



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



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


DLA3: authorization

institution a

FTXT

4. ServiceClass HTTP3. Query URL

authent1. certificate

LDAP

2. check certificate

valid CA?valid certificate?

5. access


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

1 herbert van de sompel cs 502 computing methods for digital libraries cornell university –...

Documents

authentication slide

sompel library

usernamepassword slide

users browser

sompel cs

sompel www

role slide

info providers ipaddress