Security Design

By Richard Li and Archit Shah

+Security Design

Prev	Chapter 15. 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

OpenACS 4 Security Requirements

Introduction

@@ -41,7 +41,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.

Details

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 @@ -84,7 +84,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