[plt-scheme] Looking for a security consultant with PLT web server experience
On Mon, Oct 5, 2009 at 6:25 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Seems like PLT has been putting a lot of energy into the Web server and
> servlets in the last year or two. I'd first find out whether this is
> something they want to look into right now. (Just yesterday, I found that
> Ryan Culpepper had scooped me on macro keyword support, after I'd recently
> slaved over a hot syntax-rules to do the same thing. :) In any case, I
> would try to make sure I understood PLT's rationale for everything upfront,
> to save a lot of energy.
>
> I'd be happy to kibitz on this, and am especially curious about a model for
> session vs. session-independent URLs, but unfortunately I can't volunteer
> coding work right now.
I can volunteer a limited amount of coding work, insofar as this is
the problem that we're trying to solve. That said, my partner and I
are both new enough at Scheme that our coding contributions may not be
that helpful.
As to the design goals, what I'm trying to achieve in my web-app is
actually pretty simple, and is probably something that everyone using
the server for apps would like to have:
1) A user can be securely and unambiguously authenticated.
2) The authentication system must be simple to implement by the
web-app author...ideally, it would just consist of a single standard
function call, or even just a decoration on the servlet declaration.
3) The authentication system must be easy to integrate with external
data stores (databases, etc).
4) Once a user has authenticated, the server stores a new session
object which will be available to servlets. This object contains the
username of the current user, along with other information dependent
on the needs of the app.
All of the above should be pretty much standard across any web app
that wants to do user login. The following are my thoughts on a
security model; those may or may not suit other people.
1) A "page" in a webapp is the unit of security granularity (*).
2) Pages are either "public" or "private"; is-public? and is-private?
query for these.
3) All pages have an 'authz' and 'on-fail' procedure. These have
default values and can be specified on a per-page basis.
4) When a page is requested, its authz procedure runs before the page
function runs. If authz => #t, the page runs, else the on-fail
procedure runs. The on-fail procedure is never run unless authz
fails.
5) The default on-fail procedure is (lambda (sess) (redirect-to-page
default-error-page))
6) The default authz procedure is:
(lambda (sess)
(or (is-public?)
(allowed-user? sess)
(allowed-role? sess)))
7) Private pages have two (by default, empty) lists associated with
them: allowed-users and allowed-roles. The first contains
usernames allowed to access the page. The second contains roles
(e.g. "admin", "dev", "basic-user", "premium-user") that are
allowed to access the page. In order to access the page, the
current user must either be in the allowed-users list or have one
of the roles appearing in allowed-roles.
8) Every webapp has a default-error-page function generated for it by
default; this function renders a blank page with a standard message
like "Oops, sorry, we couldn't do that. You may need to login."
This function can be overriden.
(*) In most casess, a "page" as used above will be a full page in the
browser, but it could also be a self contained component such as a
formlet, which then gets composited into other pages.
This model could be extended a lot. For example, pages could have a
chain of authz procedures, and the author could specify whether to
combine them with AND or OR. Combining with AND makes it easy to
write complicated authentication logic as a series of filters.
Combining with OR makes it easy to allow for exceptions: all premium
users, plus this one basic user who did us a favor once.
On the principle of KISS, however, I'm starting off without these extensions.
What do you all think?
--Dks