Re: authentication/authorization

On Tue, Jun 07, 2005 at 10:39:12PM +0200, Frank Tegtmeyer wrote:
> Hi all (after a long time :),

Welcome back!
 
> as I start to work with skunkweb again I would like to know which
> approach you experts choose if you have to implement closed areas in a
> website, possibly with different levels of users rights (speak: how to
> do authorization?).
> 
> My first (two years old but still working) approach was to require
> authentication through a scope configuration in sw.conf. The
> components then check that parameters are valid for the given
> user. This is not very handy and subject to errors (you may forget the
> check, of course).
> 
> I wonder if there isn't a more general approach to make components
> react according to a given security policy and a security level
> derived from the users authentication. A check against security
> requirements derived from the scope or some other source would be
> great.  Because some of you developed big sites with skunkweb I'm sure
> there is a reusable general strategy.
> 
> From the docs I found the auth service with the (misnamed) authorizer
> class - misnamed because it does authentication, not authorization.
> But it only does authentication, so it isn't the answer to my
> question.

Authentication, strictly speaking, is just the act of verifying
identity, and the auth service does do a little bit more than that --
it prevents you from accessing something if you haven't been
authenticated.  So it does do authorization, albeit only in a very
limited and inflexible way. 

> Zope does authorization based on a starting point in the object tree
> by matching roles against (required) rights. Ist there something
> similar that can be plugged into skunkweb?

The component system itself is definitely not security-policy aware.
You could build such awareness into it in a couple of ways.  One way
would be to make the vfs that AE uses security aware.  For instance,
the auth service could identify the user and set the user's role, and
another service could scope the document root on the basis of that
role, and share documents across document roots using translucent
mounts, layered in order of user privilege, so "superuser" mounts
overwrite "guest" mounts.  That would be one approach for dealing with
what resources a user might be able to access; also, you could
implement different degrees of access to resources in a property
store, and replace callComponent with a decorated version that
consulted the privilege level and intercepted the call as necessary.

This is still pretty crude, making authorization's application to
resources more granular, but not automatically providing a way to make
components behave differently according to role (although, if you used
the translucent filesystem idea, you could have different versions of
components according to role).

Another idea, implemented at a higher level, would be to have a suite
of components that implement actions dependent on user role:
admin_doSomething, guest_doSomething, friend_doSomething, etc.
callComponent could again be decorated/replaced so that you just call
<:component doSomething:> and the correct real component is
dispatched, without vfs tricks.  A bit like generic functions.
Speaking of which, looking at Eby's PEAK project is probably an good
way to steal ideas for this kind of thing. 

Of course, you could implement everything above AE, without changing
the behavior of callComponent, but then you have to restrict yourself
to the api you write; that isn't necessarily bad, however.

What is your wish list for this?  In a few months I'm going to shift
my focus to skunk4, and maybe it should make this sort of concern more
central than it has been heretofore.

js

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpiBEuqamFyFXXLIRAopkAKC4zz+BIHuQWSy7AxVya47gscxGRgCg1BwZ
mWSiD4whC2XyyRAJbpRUxDk=
=JyPl
-----END PGP SIGNATURE-----