| Prev | Chapter 7. Kernel Documentation | Next |
|---|
+
+ OpenACS docs are written by the named authors, but may be edited + by OpenACS documentation staff. +
Virtually all web sites support personalized content based on user identity. @@ -15,36 +15,34 @@ vendors require that the user identity be securely validated.
The security system consists of a number of subsystems. -
Signed Cookies
+
Signed Cookies
Cookies play a key role in storing user information. However, since they are stored in plaintext on a user's system, the validity of cookies is an important issue in trusting cookie information. Thus, we want to be able to validate a cookie, but we also want to validate the cookie without a database hit. -
10.0 Guaranteed Tamper Detection Any tampering of cookie -data should be easily detectable by the web server.
10.1 Performance and Scalability Validation and +
10.0 Guaranteed Tamper Detection Any tampering of cookie +data should be easily detectable by the web server.
10.1 Performance and Scalability Validation and verification of the cookie should be easily scalable and should not require a -database query on every hit.
Session Properties
+database query on every hit.
Session Properties
Applications should be able to store session-level properties in a database table. -
11.0 Storage API Session-level data should be accessible -via an API.
11.1 Purge Mechanism An efficient pruning mechanism +
11.0 Storage API Session-level data should be accessible +via an API.
11.1 Purge Mechanism An efficient pruning mechanism should be used to prevent old session level properties from filling up the -table.
Login
+table.
Login
The security system should support the concept of persistent user logins. This persistence takes several forms. -
12.0 Permanent Login Users should be able to maintain a -permanent user login so that they never need to type their password.
12.1 Session Login The security system should support +
12.0 Permanent Login Users should be able to maintain a +permanent user login so that they never need to type their password.
12.1 Session Login The security system should support the concept of a session, with authentication tokens that become invalid -after a certain period of time.
12.2 Session Definition A session is a sequence of +after a certain period of time.
12.2 Session Definition A session is a sequence of clicks by one user from one browser in which no two clicks are separated by -more than some constant (the session timeout).
12.3 Stateless The security system should not require +more than some constant (the session timeout).
12.3 Stateless The security system should not require state that is stored in the server. Required state may reside only in the user request (including cookies), and in the database. A single user should be able to log in to the system even if the user is sent to a different -AOLserver for each step of the login process (e.g., by a load balancer).
12.4 Secure The security system should not store -passwords in clear text in the database.
13.0 SSL Hardware The system must work when the SSL +AOLserver for each step of the login process (e.g., by a load balancer).
12.4 Secure The security system should not store +passwords in clear text in the database.
13.0 SSL Hardware The system must work when the SSL processing occurs outside of the web server (in specialized hardware, in a -firewall, etc.).