Index: openacs-4/packages/acs-core-docs/www/security-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/security-design.html,v diff -u -r1.26 -r1.27 --- openacs-4/packages/acs-core-docs/www/security-design.html 16 Feb 2005 00:21:03 -0000 1.26 +++ openacs-4/packages/acs-core-docs/www/security-design.html 4 Jun 2006 00:45:24 -0000 1.27 @@ -1,4 +1,5 @@ -Security Design
Alex logo
Prev Chapter�17.�Kernel Documentation Next

Security Design

By Richard Li and Archit Shah

+ +Security Design
Alex logo
Prev Chapter�17.�Kernel Documentation Next

Security Design

By Richard Li and Archit Shah

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.

Essentials

Introduction

@@ -57,7 +58,7 @@ user_id and session_id are pulled from it and put into ad_conn.

Authenticating Secure Connections

Secure connections are authenticated slightly differently. The function ad_secure_conn_p is used to determine whether or not the URL being accessed is requires a secure login. The function simply checks if the -location begins with "https". (This is safe because the location is +location begins with "https". (This is safe because the location is set during the server initialization.)

If secure authentication is required, the ad_secure_token cookie is checked to make sure its data matches the data stored in ad_session_id. This is true for all pages except those that are @@ -79,7 +80,7 @@ manipulation of the permanent login cookies is based on 3 factors:

  • previous login: other user, same user

  • permanent: was a permanent login requested?

  • secure: is this a secure connection?

Both the secure and insecure permanent login cookie can have one of three actions taken on it: -

  • set: cookie with no expiration is set

  • delete: set to "" with max age of 0, so it is expired +

    • set: cookie with no expiration is set

    • delete: set to "" with max age of 0, so it is expired immediately

    • nothing: if the cookie is present, it remains

    The current state of the permanent login cookies is not taken into account when determining the appropriate action. @@ -185,12 +186,12 @@ signature, RFC 2109 specifies an optional max age that is returned to the client. For most cookies, this max age matches the expiration date of the cookie's signature. The standard specifies that when the max age is not -included, the cookie should be "discarded when the user agent -exits." Because we can not trust the client to do this, we must specify +included, the cookie should be "discarded when the user agent +exits." Because we can not trust the client to do this, we must specify a timeout for the signature. The SessionLifetime parameter is used for this purpose, as it represents the maximum possible lifetime of a single -session.

    RFC 2109 specifies this optional "secure" parameter which -mandates that the user-agent use "secure means" to contact the +session.

    RFC 2109 specifies this optional "secure" parameter which +mandates that the user-agent use "secure means" to contact the server when transmitting the cookie. If a secure cookie is returned to the client over https, then the cookie will never be transmitted over insecure means.

    Performance

    Performance is a key goal of this implementation of signed cookies. To @@ -219,7 +220,7 @@ External SSL mechanisms (firewall, dedicated hardware, etc.) can be used by creating two pools of AOLservers. In one pool the servers should be configured with the location parameter of nssock module set to -"https://yourservername". The servers in the other pool are +"https://yourservername". The servers in the other pool are configured as normal. The external SSL agent should direct SSL queries to the pool of secure servers, and it should direct non-SSL queries to the insecure servers.