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:
Browser is any unmodified standard browser that supports cookies, e.g. Netscape, IE4, IE5, etc.
Service provider server is:
PRIDE Authentication Server runs stand-alone.
PRIDE Access Module/Proxy runs:
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'.|