security-requirements.xml
Delivered as text/xml
[ hide source ] | [ make this the default ]
File Contents
<?xml version='1.0' ?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % myvars SYSTEM "../variables.ent">
%myvars;
]>
<sect1 id="security-requirements" xreflabel="OpenACS 4 Security Requirements">
<title>Security Requirements</title>
<authorblurb>
<para>By Richard Li</para>
</authorblurb>
<sect2 id="security-requirements-intro">
<title>Introduction</title>
<para>
This document lists the requirements for the security system for the OpenACS.
</para>
</sect2>
<sect2 id="security-requirements-vision">
<title>Vision Statement</title>
<para>
Virtually all web sites support personalized content based on user identity.
The level of personalization may be as simple as displaying the name of the
user on certain pages or can be as sophisticated as dynamically recommending
sections of site that the user may be interested in based on prior browsing
history. In any case, the user's identity must be validated and made
available to the rest of the system. In addition, sites such as ecommerce
vendors require that the user identity be securely validated.
</para>
</sect2>
<sect2 id="security-requirements-system-overview">
<title>Security System Overview</title>
<para>
The security system consists of a number of subsystems.
</para>
<para><emphasis role="strong">Signed Cookies</emphasis></para>
<para>
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.
</para>
<itemizedlist>
<listitem><para><emphasis role="strong">10.0 Guaranteed Tamper Detection</emphasis> Any tampering of cookie
data should be easily detectable by the web server.</para></listitem>
<listitem><para><emphasis role="strong">10.1 Performance and Scalability</emphasis> Validation and
verification of the cookie should be easily scalable and should not require a
database query on every hit.</para></listitem>
</itemizedlist>
<para><emphasis role="strong">Session Properties</emphasis></para>
<para>
Applications should be able to store session-level properties in a database
table.
</para>
<itemizedlist>
<listitem><para><emphasis role="strong">11.0 Storage API</emphasis> Session-level data should be accessible
via an API.</para></listitem>
<listitem><para><emphasis role="strong">11.1 Purge Mechanism</emphasis> An efficient pruning mechanism
should be used to prevent old session level properties from filling up the
table.</para></listitem>
</itemizedlist>
<para><emphasis role="strong">Login</emphasis></para>
<para>
The security system should support the concept of persistent user logins.
This persistence takes several forms.
</para>
<itemizedlist>
<listitem><para><emphasis role="strong">12.0 Permanent Login</emphasis> Users should be able to maintain a
permanent user login so that they never need to type their password.</para></listitem>
<listitem><para><emphasis role="strong">12.1 Session Login</emphasis> The security system should support
the concept of a session, with authentication tokens that become invalid
after a certain period of time.</para></listitem>
<listitem><para><emphasis role="strong">12.2 Session Definition</emphasis> 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).</para></listitem>
<listitem><para><emphasis role="strong">12.3 Stateless</emphasis> 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).</para></listitem>
<listitem><para><emphasis role="strong">12.4 Secure</emphasis> The security system should not store
passwords in clear text in the database.</para></listitem>
</itemizedlist>
<itemizedlist>
<listitem><para><emphasis role="strong">13.0 SSL Hardware</emphasis> The system must work when the SSL
processing occurs outside of the web server (in specialized hardware, in a
firewall, etc.).</para></listitem>
</itemizedlist>
</sect2>
</sect1>
