1 / 13

The PAPI System Point of Access to Providers of Information

The PAPI System Point of Access to Providers of Information. http://www.rediris.es/app/papi/. Outline. Introduction Requirements Approximations to a solution Configurations Architecture of the PAPI system Implementation Future lines. The origin.

dung
Download Presentation

The PAPI System Point of Access to Providers of Information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The PAPI SystemPoint of Access to Providers of Information http://www.rediris.es/app/papi/

  2. Outline • Introduction • Requirements • Approximations to a solution • Configurations • Architecture of the PAPI system • Implementation • Future lines

  3. The origin • Meeting between library consortia and content providers • Original problem to solve: access control by IP address • RedIRIS committed to provide a solution • Organizations: • Spanish library consortia • CICA, CSIC, UAM, UOC, UPM, CBUC • Content providers • SILVERPLATTER • GREENDATA • EBSCO • SWETS • ARANZADI

  4. Requirements • Access control independent from IP origin • Upon successful local authentication, access must be granted during a configurable period of time to the services that the user is authorized to • User mobility • Transparency to the user • Compatibility with other commonly employed access control systems • Compatibility with Netscape/MSIE/Lynx browsers • Privacy at the user level, while easing the collection of statistics by providers

  5. HTTP request + Certificate S1 Temporary Certificates Authentication data Web page HTTP request + Certificate S2 Certificate S1 Certificate S2 Certificate S3 Web page Approximation: Temporary Certificates Authentication Server Advantages: • Temporary access to authorized services • Allows user mobility • Authentication is local to user’s organization • Technology implemented in main web servers Problems: • NOT TRANSPARENT • Password in browser DB • Choice of the right certificate • Inf. providers not adapted to this technology • Does not detect certificate duplication Web Server S1 Web browser Web Server S2

  6. Authentication data Temporary Encrypt-cookies HTTP request Encry-cookie S1 Encry-cookie S2 HTTP request Encry-cookie S3 + Encry-cookie S1 Web page Point of Access Web page Approximation: Partial Solutions Advantages: • Temporary access to authorized services • Allowsuser mobility • Authentication is local to user’s organizations • Access control is adapted to current web servers of content providers • Transparent to the user Problems: • Domain-name problems when loading cookies • Does not detect cookie copying • No transparency -> encrypted cookies • Web servers not adapted -> Points of Access Authentication Server Web Server S1 Web browser

  7. Authentication data Temporary Signed-URLs Signed-URL Encry-cookie S1 Encry-cookie S2 Encry-cookie Encry-cookie S3 Point of Access Point of Access Signed-URL Encry-cookie Approximation: Partial Solutions • Domain-name problems when loading cookies -> Cookies served by PoAs Authentication Server Web browser

  8. HTTP request + Encry-cookie S1 HTTP request Web page Web page + New Enc-cook S1 Point of Access HTTP request Collision + Encry-cookie S1 Approximation: Partial Solutions • Cookie copying -> Database of cookies Short expiration time DB of Enc-cookie Web Browser 1 New Enc-cook S1 Encry-cookie S1 Web Server S1 Web Browser 2 Encry-cookie S1

  9. URL: K_priv_AS (user code + server + path + Exp. Time + sign time) Authentication data HTTP request Web page Point of Access • Hcook: K1_PA (user code + server + path + Exp. Time + Random Block) • Lcook: K2_PA (user code + server + path + creation time) Architecture of the PAPI system Authentication Server Temporary Signed-URLs Hcook DB HTTP request + Hcook+Lcook Web browser Web Server S1 Web page + New Hcook+Lcook Encry-cookies

  10. Authentication Server Authentication Server Authentication Server Authentication Server Point of Access Point of Access Point of Access Point of Access Point of Access Point of Access Web Server Web Server Configurations User's Organization Information Provider Web Server Web browser

  11. Implementation • Status: Version 1.0.0 • Available at http://www.rediris.es/app/papi/dist.en.html • Crypt functions: • OpenSSL • Authentication modules • Local auth, LDAP, POP3 • Points of Access • mod_perl • Apache virtual servers

  12. Future Lines • Enhancement of statistic collection at PoAs • More general implementation • Servlet(s) • Management tools (both for AS and PoA) • Interaction with information access software • Align to similar initiatives • Authentication objects • Alternative protocols for exchanging them • SPARTA, Shibboleth

  13. Pilot of the system Information Providers AS: Local PoA: MEDLINE (ERL) AS: LDAP PoA: LISA DB (ERL) AS: POP PoA: Local DBs AS: POP PoA: Local DBs

More Related