ossp-pkg/sorp/SPEC.txt
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
}
