1. 1 herbert van de sompel CS 502 Computing Methods for Digital Libraries Cornell University – Computer Science Herbert Van de Sompel herbertv@cs.cornell.edu Lecture 18 Cross-organizational authentication & authorization

2. 2 herbert van de sompel Users Digital objects Identification & authenticity Attributes Authentication Roles Permitted Operations Laws and agreements Policies Authorization Information Managers Access

3. 3 herbert van de sompel Users and roles: theory authentication roles-dbase 110010110 101100101 101010000 attributes policy related limitations roles policy related privileges X access permitted operations

4. 4 herbert van de sompel Users and roles: practice authentication roles-dbase 110010110 101100101 101010000 attributes policy related limitations roles policy related privileges collection

5. 5 herbert van de sompel Users and roles: practice authentication 110010110 101100101 101010000 attributes policy related limitations roles policy related privileges collectionauthentication = = role

6. 6 herbert van de sompel Users and roles: practice authen & author 110010110 101100101 101010000 attributes policy related limitations policy related privileges collection

7. 7 herbert van de sompel Library: Interoperability nightmare re access management A&IimageFTXTOPACe-print multiple authorization authentication processes implicit explicit

8. 8 herbert van de sompel Library: Interoperability nightmare re access management A&IimageFTXTOPACe-print authen & author library authorizations related to library’s subscriptions libraries try to make the process opaque to users

9. 9 herbert van de sompel Library: Interoperability nightmare re access management A&IimageFTXTOPACe-print

10. 10 herbert van de sompel 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

11. 11 herbert van de sompel WWW-Authenticate see http://www.modperl.com/book/chapters/ch6.htmlhttp://www.modperl.com/book/chapters/ch6.html

12. 12 herbert van de sompel 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

13. 13 herbert van de sompel 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)

14. 14 herbert van de sompel Common access control approaches by Libraries 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:pass@www.nogood.com/resource.htm but what if user’s try and access the resource directly? top-level links can be bookmarked

15. 15 herbert van de sompel 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 user’s browser rewriting proxy proxy will require authentication

16. 16 herbert van de sompel it’s a big mess

17. 17 herbert van de sompel 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?

18. 18 herbert van de sompel DLA3: general institution a institution b institution z A&IimageFTXTOPACe-print single approach for authentication (certificates) authorization (instit. LDAP)

19. 19 herbert van de sompel 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. 20 herbert van de sompel 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)

21. 21 herbert van de sompel DLA3: authentication institution a FTXT 1. request content HTTP 2. request certificate authent 3. send certificate 4. check certificate valid CA? user member of sub inst? valid certificate?

22. 22 herbert van de sompel 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. 23 herbert van de sompel 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. 24 herbert van de sompel DLA3: authorization institution a FTXT 4. ServiceClass HTTP 3. Query URL authent 1. certificate LDAP 2. check certificate valid CA? valid certificate? 5. access

25. 25 herbert van de sompel 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