| Prev | Chapter�10.�Kernel Documentation | Next |
|---|
-
-by Richard Li, Archit Shah
+
This document explains security model design for OpenACS 4. The security system with the OpenACS core must authenticate users in both secure and insecure environments. In addition, this subsystem provides sessions on top of the @@ -42,7 +40,7 @@ for a secure authentication token. However, the basic architecture here lays the foundation for a secure system and can be easily adapted to a more secure authentication system by forcing all logins to occur over HTTPS.
The authentication system issues up to four signed cookies (see below), -with each cookie serving a different purpose. These cookies are:
name value max-age secure? ad_session_id session_id,user_id SessionTimeout no ad_user_login user_id Infinity no ad_user_login_secure user_id,random Infinity yes ad_secure_token session_id,user_id,random SessionLifetime yes
ad_session_id
reissued on any hit separated by more than SessionRenew seconds from the +with each cookie serving a different purpose. These cookies are:
| name | value | max-age | secure? |
| ad_session_id | session_id,user_id | SessionTimeout | no |
| ad_user_login | user_id | Infinity | no |
| ad_user_login_secure | user_id,random | Infinity | yes |
| ad_secure_token | session_id,user_id,random | SessionLifetime | yes |
ad_session_id
reissued on any hit separated by more than SessionRenew seconds from the previous hit that received a cookie
is valid only for SessionTimeout seconds
is the canonical source for the session ID in ad_conn
ad_user_login
is used for permanent logins
ad_user_login_secure
is used for permanent secure logins
contains random garbage (ns_time) to prevent attack against the secure hash
ad_secure_token
is a session-level cookie from the browser's standpoint
its signature expires in SessionLifetime seconds
contains random garbage (ns_time) to prevent attack against the secure @@ -85,7 +83,7 @@ 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. -
previous login state permanent login requested secure connection action on insecure action on secure other y y set set same y y set set other y n set delete same y n set nothing same n y nothing delete other n y delete delete other n n delete delete same n n delete delete
ad_user_login +
| previous login state | permanent login requested | secure connection | action on insecure | action on secure |
| other | y | y | set | set |
| same | y | y | set | set |
| other | y | n | set | delete |
| same | y | n | set | nothing |
| same | n | y | nothing | delete |
| other | n | y | delete | delete |
| other | n | n | delete | delete |
| same | n | n | delete | delete |
ad_user_login callssec_setup_session which actually calls sec_generate_session_id_cookie to generate the new cookie with refer to the appropriate user_id. If the connection is secure @@ -152,7 +150,7 @@ sessions whose first hit was more than SessionLifetime seconds (1 week by default) ago. Session properties are removed through that same process with cascading delete. -
Session properties can be set as secure. In this case, ad_set_client_property will fail if the connection is not secure. ad_get_client_property will behave as if the property had not been set if the property was not set securely.
@@ -322,12 +320,12 @@ in the URL and get it back on the next hit, the sessions system would continue to work.
Problems that arise: -
URL sharing could be dangerous. If I happen to be browsing Amazon while logged in and I email a friend, he could conceivably receive it and follow it before my session has expired, gaining all of the privileges I -had.
User-entered URLs are harder to handler. If a user is in the middle of a session and then types in the URL of some page, he could be kicked out of his -session.
+session.
Both of these problems can be mitigated by doing detection of cookie support (see the section on robot detection). To help deal with the first problem, One