Subject: [TOOLS-DEVELOPMENT] Notes about tools authentication model

From: <[email-masked]>
Date: Mon, 28 Sep 2009 13:43:15 +0200

Here's my summary from the call on Friday (with Glen, Karen, Alexa,
Russ, Henrik, and me). I might have gotten something wrong,
so please yell if this doesn't match your recollection :)

Best regards,
Pasi

--------------------

- We're beginning to add access-controlled functionality to the Django
datatracker code, since it makes no sense to have totally separate
"public tracker" and "non-public tracker" code.  The first
access-controlled functionality will be common tasks done by IESG
(such as balloting).

- When moving access-controlled functionality to Django, the first
priority is given to functionality used by several community members
(as opposed to functionality used only by the secretariat) that is
used often (not just once a month) and that's relatively simple.  The
amount and complexity of the code should be kept limited, since bugs
in code that modifies the database could have more serious
consequences than public read-only pages.

- For authentication, the existing Apache htpasswd files will be used.
These files are maintained by the secretariat the same way as
currently (change requests via email/RT). For the time being, there
won't be any automatic functionality for creating accounts or
resetting lost passwords.

- The Django code will not access the htpasswd files in any way; the
actual authentication is done by Apache. Apache configuration needs to
be modified so that "/login/" URL (or something -- details TBD)
requires a password.  Django's authentication framework gets the user
name from the REMOTE_USER environment variable set by Apache
(this requires Django version 1.1).

- Apache will not request authentication for any other URLs; instead,
access control is done by Django code (based on a cookie set by the
login page). Pages that absolutely require authentication would
redirect the client to /login/; other pages might show different views
to unauthenticated users (e.g., anyone can view the ballot page, but
the "Edit" button is visible only for IESG members).

- For authorization information (who is allowed to do what), Django
will use the existing database tables (used by current Perl CGI
scripts) that tell e.g. which users are IESG members, who is chairing
what WG, and so on. It would also be possible to read the Apache's
.perms file, but it's not clear if this would be needed.

- I have not yet worked out all the details how this will be
implemented, especially how this works with Django's Group and
Permission objects.

The next actions will be 

- Henrik and Pasi will work on getting the current functionality
(without authentication) working with Django 1.1, and deploying
it (possibly even before Hiroshima).

- Pasi will modify the Django authentication code to implement the
above, and do one simple access-controlled functionality (probably
IESG balloting) as an example/test.

- Henrik will talk with Glen about using Django's admin framework
to replace some of the current secretariat tools.

------------------------