OSSP sorp SPECIFICATION ======================= Mandatory Requirements ---------------------- o URL rewriting on redirects and in HTML content (hyperlinks) (important for full backend hiding and avoiding of by-passing traffic) o full HTTP/1.0 and HTTP/1.1 compliant frontend service (important for full conformance with browser features and performance) => apache, squid, ?? o HTTPS/HTTP 1.0/1.1 to HTTPS/HTTP 1.0/1.1 proxy functionality for backend service (to reduce load and complexity on backends) => apache, squid, ?? o forwarding of client IP and HTTP/1.1 "Host:" header to backend servers (for correct logging and virtual hosting on backends) => apache mod_xxx, ?? o backend service selection based on - HTTP/1.1 Host header (for real virtual hosting on frontend) - URL rewriting rule (or at least URL prefix matching) (for seamless linking of backends into frontend URL namespace) - user authentication information (for sticky user backends, etc.) => apache mod_rewrite? o user single sign-on with stickyness and automatic sign-on expiring (for comfortable sign-on over browser restarts and security) o authentication via one or more of the following credentials: - userid+passwd (for standard authentication) - SSL client certificate (for elegant authentication) - host-based ACL (for by-pass authentication) - authentication backends: - Kerberos Tickets? - LDAP? - SQL? - S/Key OTP? - PAM? - SASL? - Local PW o mapping of incoming (and successfully authenticated) authentication method and identity to perhaps different authentication method and identity on backend server communication. o automatic session tracking in frontend service (for reducing complexity on backends) - via HTTP Cookie key "session" (read-write) - via URL QUERY_STRING key "session" (read-write) - via SSL client certificate (read-only) o easy remote session information retrival from backend servers (for storing sessions on frontend only and still have on backends) o extendable user session information set (for flexibility in the backends and to avoid DBs there, too) o easy administration of user accounts (passwords!) and session information via Web UI (for obvious administration of whole setup) o allow bookmarking of subpages by redirecting from subpage request to login on missing session and after loggin in again back to subpage (for supporting subpage bootmarking) Optional Requirements --------------------- o HTTPS sticky pass-through connections (for HTTPS on backends) o server side include (SSI) or other dynamic content expansion in backend response on frontend server (for global navigation bars, headers, footers, etc) o load balancing over multiple backend servers (for performance) o automatic backend disabling on downtime/error if multiple backends exist o caching of backend responses (for performance) o content manipulations - splash screen additions - header/footer/css additions - watermark additions (for global services) o pre-fetching from backend servers of inline images and referenced pages Run-time Pseudocode ------------------- read client-request (CReq) from client create backend-request (BReq) by copying CReq extract request URL select backend URL and insert into BReq as new URL extract from IReq and remove from BReq authentication id 1. from QUERY_STRING 2. from HTTP Cookie header 3. from SSL client certificate if (URL requires authentication) { check authenentication id; if (not exists or is invalid authentication id) { ... stop; } optionally map authentication id according to backend URL insert (optionally mapped) authentication id into BReq as - QUERY_STRING addition - HTTP Cookie header } send BReq request to backend server read BRes response header from backend server extract response code from BReq filter BRes to IRes if (redirect) { inverse map Location header according to backend selection rules } if (code eq 200/OK and content-type == HTML) { while body is read in junks inverse map hyperlinks according to backend selection rules } else { while body is read in junks pass through unchanged }