On Tue, 2001-11-20 at 19:10, Tavis Rudd wrote:
> > Another issue with roles/groups: how to contextualize them. In
> > Zope you have Aquisition and the ACL folders, so that you can give
> > permissions to a section of the path to a user. In my own
> > programming, I've found situations when you want to say "this
> > person is a X with respect to class Y", like "this person is an
> > editor of book X". This doesn't fit into normal ACLs, except by
> > way of a combinatorial combinations of classes and roles into
> > specific groups -- like having editor_book1, editor_book2,
> > editor_book3, etc.
> With 'actions' you can do this quite easily. "Group X is allowed to
> edit book1, but can only view book2." That's why I dislike the term
> 'roles'; it implies a strict connection between 'groups' and
> particular 'actions'.
That's not what I was hoping for: that still means there has to be a
group editor_of_book1, editor_of_book2, etc., while I'd like "editor" to
be a role that is specific for a certain object (book1, book2, etc).
Then you don't have to add more roles when you add more book objects:
the roles can remain relatively static, and only be updated based on
policy changes and such.
I use roles like groups, except "group" feels more concrete, and I'm
talking about something a bit more abstract.
Now, this exactly functionality shouldn't be built into the system, of
course, but hooks should be there.
In my OO notion, lets say each user has an authentication object. That
authentication object can represent composites of other authentication
objects, each of which could be specialized in some way, i.e., you'd be
making subclasses -- like I'd make a "role for book X" subclass that
could deal with a role being directed to a book, with an "editor"
instance that might be given to a particular user.
Then the resources might have a, um, permission object. I'm still not
sure how that would work, though...
> > But I haven't seen a lot of other techniques. Capabilities seem to
> > be ACLs where the action part is better abstracted... but otherwise
> > I haven't seen why it is significantly different. But maybe I'm
> > missing something there. ACLs are really hard to manage. Unix
> > permissions aren't flexible enough. If anyone knows of interesting
> > ideas, I'd be most curious.
> Why are ACL's hard to manage?
Management of ACL's is very imperative. For instance, in my example,
when you wanted to change something about how a group related to
articles -- like, say, you want editors to no longer be able to delete
articles -- then you'd have to go through all the articles and change
the permissions for each one. Tools make this easier, but they don't
make it cleaner.
I don't have a ton of experience with such things, but I found it quite
difficult to figure out what the situation was in NT with permissions in
many cases -- viewing each file's permissions is a lousy way to do an
I think there needs to be more opportunities for abstraction in the
permission system. Also, a more declarative model might be easier to
> > I don't think ownership is a necessary metaphor, though sometimes
> > it is a useful metaphor. Sometimes it is meaningless.
> I agree that in most cases the concept of ownership will be
> meaningless, but some of the AppIdeas on the Webware Wiki would need
> this concept. So it's best to build it into the base system.
I don't think things should be built in because they might be needed --
instead we should build a structure where they can be implemented as
needed. I don't want everything to have an owner just because a few
things need ownership, just like everything shouldn't have an executable
> > The conventional security in Webware is pretty much a
> > throw-exception-when-necessary system.
> That's another thing that needs some thought: what happens when a
> user is authentificated, but tries to access a resoure they don't
> have permissions for. There should be hooks for custom logging and
Well, I think it should just throw an exception, and at some point you
might catch that exception, log it, and forward or request they login or
The permission error might very well happen somewhere there's no access
to the larger context. Which is where exceptions are so nice (I love
exceptions!) If you build in introspection, that might involve checking
if an exception is thrown (like hasattr works, I think), or it might
mean that permission information is built into the object, and an
exception is thrown when illegal access is made. Actually handling that
exception is just a matter of it being caught somewhere, like in
> Correct me if I'm wrong, but it seems that UserKit can't be used with
> non-servlet files.
As far as I can tell UserKit has absolutely no web-based or webkit-based
assumptions. It is totally seperated. It also doesn't address anything
to do with permissions, just users. It's quite minimal.