Index: openacs-4/packages/acs-core-docs/www/security-requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/security-requirements.html,v diff -u -r1.7 -r1.8 --- openacs-4/packages/acs-core-docs/www/security-requirements.html 30 Nov 2002 17:16:24 -0000 1.7 +++ openacs-4/packages/acs-core-docs/www/security-requirements.html 28 Feb 2003 05:36:05 -0000 1.8 @@ -1,5 +1,5 @@ -OpenACS 4 Security Requirements

OpenACS 4 Security Requirements

+OpenACS 4 Security Requirements

OpenACS 4 Security Requirements

by Richard Li
OpenACS docs are written by the named authors, but may be edited by OpenACS documentation staff. @@ -15,34 +15,34 @@ vendors require that the user identity be securely validated.

Security System Overview

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.).

View comments on this page at openacs.org