On Tuesday 20 November 2001 14:57, Ian Bicking wrote:
> On Tue, 2001-11-20 at 17:34, Tavis Rudd wrote:
> > Let's scrap the term 'role' completely then, and only use the
> > terms of users, groups, actions and permissions. Where 'actions'
> > are things like view, edit, etc. and permissions are the
> > authorization for particular users and groups to be able to
> > perform those actions on an object. An application designer
> > should be able to define custom actions.
>
> Sure, group is fine -- but I generally see role used in exactly the
> same way. If there's a doubt, they should generally be seen as
> synonomous. Group gives the feel of Unix groups, where you have
> group ownership, which isn't the same as roles.
True, that's what I was getting at with the questions about
'ownership'.
> 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'.
> 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?
> 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 think that's going to be very context specific. Pages with
> > distinct URI's are objects, but what about the UI components
> > inside those pages. That's something that best left up to the
> > application designer.
>
> However, it would be nice if the programmer had something to go on.
> For instance, if you have objects which may be usable through
> several views -- which means several URLs -- it should be easy to
> pass the authentication onto the viewed object. Also, it's nice to
> be able to easily access the permissions -- for instance, if you
> show a menu of actions, and you only want to show ones the user is
> allowed to do, you can't have a permission system where you have to
> actually try to do something (and fail) in order to know whether it
> is doable.
Good points.
> 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
forwarding.
In terms of architecture, some of this stuff ties into the
multi-application framework that Jay and I have been working on
independently. The authentificator would be a singleton object that
is accesible via containment or a mixin. But would logging in to any
page on www.mysite.com log you into all the webware applications
running on that site, just one or some of them? In the redesign code
I've been working on it's possible for each of the Applications
running in a single AppServer to have a separate session id and
session data store. Instead of just having _SID_ as the cookie key
you could have _WEBWARE_APP1_SID_ and _WEBWARE_APP2_SID_.
Permissions could be handled by a singleton Authorizer object or you
could hard-code the permissions into particular servlets.
Because of the vague nature of what 'resources' actually are it would
make sense to provide the authentification and authorization hooks
via the Application class. That way the application designer would
be able to do access control at both the URI and file-system level.
Examples:
* require authentification for all resources served by a
particular application
(http://www.mysite.com/MyApp/[AllResources])
* restrict access on all URIs that map to a particular servlet on
the filesystem (http://www.mysite.com/MyApp/Servlet1 or
http://www.mysite.com/MyApp/ExplicitContext/Servlet1)
* restrict access to all URIs that include a particular path,
or qString
Note, that this only makes sense with the multi-application framework
that I've been working on, where it is possible to sub-class and
extend Application.
Correct me if I'm wrong, but it seems that UserKit can't be used with
non-servlet files.
I'm thinking of a system where it is possible to have the Application
handle all authentification automatically. It could manage
permissions via an ACL or delegate the permission handling to the
servlets. The permissions manager would automatically invoke the
authentificator if it is called it before a user has logged in.
Tavis
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
