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. Capability would be the (action, resource) pair -- i.e., you have the permission to perform a specific action on a specific resource. I definitely think actions shouldn't be hard-wired. Then you start getting stuff like the x bit on directories in Unix... just weird. 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. 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. > And how about the term 'resource' rather than 'object'? > > We also need to clarify the distinction between 'ownership' and > 'permissions'. In Unix these concepts are directly tied together. > Not so in NT and other OSes. It should be possible for multiple > users and multiple groups to have permissions to do perform various > actions on a resource, just like in NT. But then who owns the > resource? Should there be a concept of ownership built directly into > the system, where only the owner of a resource (and root) can changes > permissions for that resource. I don't think ownership is a necessary metaphor, though sometimes it is a useful metaphor. Sometimes it is meaningless. > > It's not at all clear to me, now, what an object is in Webware, > > with respect to permissions -- obviously not every object is going > > to have permission information. Not every object is viewable. > > 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. The conventional security in Webware is pretty much a throw-exception-when-necessary system. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
