PRIDE

Authentication Scenario

A brief overview of a PRIDE authentication scenario is presented here. It shows how the PRIDE directory can be used as the basis for authentication, authorisation and user profiling - providing the end-user with a single access point and single username/password to multiple services.

This scenario is intended to:

Scenario

  1. User connects to PRIDE Authentication Server (PAS). The requested service name is embedded in URL, e.g.
    http://auth.pride-lib.org/BIDS-ISI/
  2. PAS asks browser for username/password using HTTP Basic Authentication.
  3. Browser supplies them (possibly after prompting end-user).
  4. PAS connects to PRIDE Directory using supplied username/password. If not OK, PAS returns failure to browser.
  5. PAS obtains list of allowed services from the PRIDE directory and compares requested service against them. May also retrieve detailed information about requested service, as necessary.
  6. If OK, PAS generates encrypted 'ticket' (username, service, timestamp) as cookie and returns HTTP redirect to browser. If not OK, PAS returns failure to browser.
  7. Browser follows redirect to PRIDE Access Module/Proxy (PAM/P).
  8. PAM/P passes 'ticket' to PAS for validation. PAS de-crypts ticket and checks timestamp. If required, PAS requests user profile information from PRIDE directory (if allowed for the requested service) (8a and 8b).
  9. PAS returns result of 'ticket' validation, timestamp information, user profiling information and information about the requested service to PAM/P. PAM/P caches this information for future use.
  10. If all OK, request is passed on to Service Provider Web server (as HTTP request if running in PAM/P proxy mode or directly if running as Apache Module - note that user profiling information can not be passed to Service Provider over HTTP).
  11. Web content returned by Service Provider (possibly based on user and user profiling information if not running in PAM/P proxy mode).
  12. Web content returned to end user browser (after re-writing embedded URLs if running in PAM/P proxy mode).
 

Notes

Browser is any unmodified standard browser that supports cookies, e.g. Netscape, IE4, IE5, etc.
Service provider server is:
  • unmodified Web server, or
  • Apache server with PRIDE Access Module.
    PRIDE Authentication Server runs stand-alone.
    PRIDE Access Module/Proxy runs:
  • embedded into Service Provider Apache Web server, or
  • colocated with PRIDE Authentication Server, or
  • stand-alone.
    All traffic between browser and Service Provider Web server is transported using HTTP.
    If PRIDE Access Module/Proxy is run in proxy mode, all Service Provider URLs in content returned from server must be re-written to route further traffic via the proxy.
    If PRIDE Access Module/Proxy is run in proxy mode, access control at Service Provider is based on IP address of proxy - though could also be based on SSL connection.
    The system will support unmodified Service Provider Web server (by running the PAM/P in proxy mode) - though this is not ideal for performance reasons (all traffic must travel via PAM/P) and because profiling information is not available to Service Provider.
    When the 'ticket' expires (becomes older than its timestamp), a failure is returned by PAM/P and the cached information is deleted.
    All failures are returned as HTTP redirects to Service Provider hosted Web pages for the service requested.
    Steps 2 and 3 could be replaced by certificate supplied from browser to PAS.
    Steps 8a and 8b could be performed directly by PAM/P rather than by PAS ??
    PRIDE Directory could be replaced by alternative authentication database, e.g. ATHENS or local UNIX /etc/passwd file, with links 4, 5, 8a and 8b modified appropriately.
    •  
    All subsequent traffic between browser and Service Provider Web server goes 7, 10, 11, 12, with profiling information obtained from PAM/P cache based on supplied 'ticket'.

    Web page by: Andy Powell and Tracy Gardner, UKOLN
    Last updated: 10-May-1999