From: Robert R. II <rk...@ya...> - 2001-11-20 19:59:48
|
Just to say here-here! I'd like to see this (and many more) full-scale examples of Webware-based applications, for non-gurus like myself who don't enjoy single-stepping through existing code (grin). >Hi, > >starting on user management sounds like a good idea. I'd be interested in >builing a (at first primitive) document management system and usermanagement >is definatelly needed. >I'll post some ideas on the twiki about this during the next days. > >Stephan > >On Sunday 18 November 2001 00:51, you wrote: > > ok, > > > > i'm typing onehanded with a baby in my > > other arm so forgive the brevity. > > > > i think a good place to start is > > with some infrastructure i.e user > > management etc. There is > > some interest in the GNUe > > project re:groupware. they use > > python alot and some have played with > > webware. we may be able to collaorate a > > little on backend stuff. table > > design etc. the more open any project like > > this is the more resources we can attract. > > > > userkit seems to be not quite complete enuf > > as it uses middlekit for it's RDBMS persistance > > and middlekit is not feature complete yet. > > > > Groupware could be the "killer app" for > > webware. > > > > Darryl > > > > <More messages snipped> Robert K. Rickenbrode II rk...@ya... |
From: Tavis R. <ta...@ca...> - 2001-11-20 20:39:42
|
On Tuesday 20 November 2001 11:46, Robert Rickenbrode II wrote: > Just to say here-here! I'd like to see this (and many more) > full-scale examples > of Webware-based applications, for non-gurus like myself who don't > enjoy single-stepping through existing code (grin). > > >Hi, > > > >starting on user management sounds like a good idea. I'd be > > interested in builing a (at first primitive) document management > > system and usermanagement is definatelly needed. > >I'll post some ideas on the twiki about this during the next days. I haven't been following all of this, but it sounds interesting and worthwhile. Many of the ideas listed on the Wiki's AppIdeas page are closely related to this idea. UserManagement is an essential component of all the application ideas listed so far. Is UserKit up to the task? I haven't used it. Here's what I consider the essential aspects of a UserManagement system: * secure authentification mechanism that works with or without cookies * concept of both users and groups (completely separate from the OS!) * ability for one user to belong to multiple groups * ability for a group to belong to other groups * flexible, role or action based, authorization (aka permissions) * a user-info interface (passwd-change, personal data, etc) * web-based and command-line management interfaces that allows quick drill-downs on users/groups and addition/update/suspension/deletion of those users/groups * support for multiple data stores(flat file, BDB, various relational databases, etc.) * ability to tie into existing databases without needing to migrate data (i.e. soft-code the fields used) * good logging * clean separation between the backend and the user-interface that permits quick customization of the UI. Tavis |
From: Ian B. <ia...@co...> - 2001-11-20 20:57:00
|
> I haven't been following all of this, but it sounds interesting and > worthwhile. Many of the ideas listed on the Wiki's AppIdeas page are > closely related to this idea. UserManagement is an essential > component of all the application ideas listed so far. > > Is UserKit up to the task? I haven't used it. I haven't used it either, but I've looked at the code > Here's what I consider the essential aspects of a UserManagement > system: > > * secure authentification mechanism that works with or without cookies Not included > * concept of both users and groups (completely separate from the OS!) Yes, calls them roles. > * ability for one user to belong to multiple groups Of course > * ability for a group to belong to other groups Yes, I believe HiarRoles or something in UserKit does this > * flexible, role or action based, authorization (aka permissions) Does include permissions > * a user-info interface (passwd-change, personal data, etc) > * web-based and command-line management interfaces that allows quick > drill-downs on users/groups and addition/update/suspension/deletion > of those users/groups No, probably by design > * support for multiple data stores(flat file, BDB, various relational > databases, etc.) > * ability to tie into existing databases without needing to migrate > data (i.e. soft-code the fields used) It does have flat file and MK -- that implies other stores wouldn't be hard > * good logging This might be incidental to what UserKit actually does -- well, I don't think it is meant to *do* anything, only be a way to query information (about users) -- logging every query is very noisy. > * clean separation between the backend and the user-interface that > permits quick customization of the UI. Well, not including a UI makes for a clean seperation, I suppose :) What UserKit could really use is some good examples and docs -- not thorough, but more like a map. It didn't seem entirely clear to me how it fit together. The code itself seems very compact (all the more reason docs are important). I think permissions should be considered something of a different issue -- ACLs being traditional at this point, but not always appropriate. They are closely tied to the system's notion of a an object and the granularity of permissions. I myself have been thinking about a more OO way of doing permissions -- most of the ways seem to be based on static data structures with explicit algorithms: it's not possible, for instance, to say "anyone can do action X if someone with permission Y requested that they do it" -- you can make the request also grant the permission, but the algorithm itself is external to the security system. You can't, for instance, retroactively change those permissions around, because the actions (the request) have already passed. Anyway, I'm not sure where I'm going with that idea, but it might only be to say that figuring out permissions is distinct from managing users and their roles/groups, and probably more complicated. Ian |
From: Tavis R. <ta...@ca...> - 2001-11-20 21:20:14
|
Here's some notes of Zope's handling of security and permissions: http://www.zope.org/Documentation/ZDG/Security.stx |
From: Tavis R. <ta...@ca...> - 2001-11-20 21:51:15
|
I've added a Wiki topic for discussing authentification, authorization, user-management, etc. http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareUserManager Ian, I've posted your comments underneath mine. |
From: Kendall C. <ke...@mo...> - 2001-11-21 19:10:48
|
On Tue, Nov 20, 2001 at 03:00:06PM -0600, Ian Bicking wrote: > I myself have been thinking about a more OO way of doing permissions -- > most of the ways seem to be based on static data structures with > explicit algorithms: it's not possible, for instance, to say "anyone can > do action X if someone with permission Y requested that they do it" -- > you can make the request also grant the permission, but the algorithm > itself is external to the security system. You can't, for instance, > retroactively change those permissions around, because the actions (the > request) have already passed. Sounds, Ian, like your hunting around in the "E, a capabilities language" neighborhood. It would be very interesting to see how far one could take the E, capabilities trust model into Python/Webware. Best, Kendall Clark |
From: Chuck E. <Chu...@ya...> - 2001-11-28 07:13:56
|
On Tuesday 20 November 2001 01:00 pm, Ian Bicking wrote: > > * a user-info interface (passwd-change, personal data, etc) > > * web-based and command-line management interfaces that allows quick > > drill-downs on users/groups and addition/update/suspension/deletion > > of those users/groups > > No, probably by design Well as the primary author of UserKit, I wouldn't say "by design" so much as "haven't gotten there". I would certainly like to see interface elements come with UserKit, probably under a UserKit/WebKit/ package. eg, the UserKit UI would be an optional integration with WebKit. > > * support for multiple data stores(flat file, BDB, various relational > > databases, etc.) > > * ability to tie into existing databases without needing to migrate > > data (i.e. soft-code the fields used) > > It does have flat file and MK -- that implies other stores wouldn't be > hard I'm glad you noticed that. :-) On Tuesday 20 November 2001 02:10 pm, Ian Bicking wrote: > 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. Geoff and I have played around with some designs for permissions. Interesting questions came up: - Do you ask the user object if he has permission to do X to Y, or do you ask Y if user U can do X? - How should permissions be archived? Particularly in MiddleKit. - Permissions should obviously speak of roles. Should they also be able to speak of specific users? The answers are left as an exercise to the reader. ;-) On Tuesday 20 November 2001 02:27 pm, Tavis Rudd wrote: > Ah, but 'groups' are not the same things as 'roles'. I'm using > 'groups' in the traditional unix sense of the term, but with the > proviso that a group can belong to other groups. 'roles' are > something completely different. A better term for 'roles' is > 'actions'. In the context of web publishing, actions could include > the following: view, edit, delete, rollback, publish, hide, etc. It's immediately obvious that actions are always verbs: what can you _do_. Therefore, I don't see why these verbs would be considered "roles" which are nouns, in the non-action oriented sense. UserKit's roles *are* equivalent to groups. I chose the name "role" simply because I like it better and to avoid any implicit connection that they came from your op sys's groups. Plus we save one character of typing every time we say "role" instead of "group". ;-) On Tuesday 20 November 2001 02:27 pm, Tavis Rudd wrote: > Who's using UserKit??? Chuck, Tom, Geoff? anyone else? I'm using UserKit on a commercial project. In fact, that project funded about half of what's been developed there. However, the UI related to it is baked into the app and we haven't even tackled the permissions issue in any sensible way. On Tuesday 20 November 2001 03:34 pm, 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. See my comment above. "Role" is already there and I'd like to stick with it. > And how about the term 'resource' rather than 'object'? I think this adds another conceptual layer that will obscure more than enlighten. At least that's my thoughts until I see some text that spells things out some more. > 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. My first impressions is "no". We don't need to require a sense of ownership as part of providing a framework for user management and permissions. In fact, granular permissions about who-can-do-what seem to obviate the need for ownership. If an object knows that "chuck can *; tavis can view, edit, delete; others can view" then ownership becomes useless (unless you had other uses intended for it). Of course, permissions shouldn't interefere with adding ownership to objects. On Tuesday 20 November 2001 03:34 pm, Tavis Rudd wrote: > > Well, we can start with authentication if it means we just use > > UserKit, because using code that exists is very easy :) > > If it's suitable. UserKit isn't very prolific but what's there is well designed and tested. In fact, we designed the API together on the mailing list before writing the code. It was fun. :-) Nothing in UserKit would prevent adding in more things like UI, permissions, etc. On Tuesday 20 November 2001 03:34 pm, Tavis Rudd wrote: > 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. In my commercial project, it's the middle objects that are resources to be protected, where as the pages are the implementors of actions (like View.py eg http://localhost/webkit/app/Documents/View.py?doc=foobar). Various sites will take different approaches and I hope whatever permissions framework we come up with is flexible enough for that. At the heart of the design Geoff and I discussed was the method: def userCanPerform(self, user, action): Where users is a UserKit.User and action is a string such as 'view', 'edit', 'create', etc. You might need to flip that method a bit depending on whether your approach asks the user, or the object, or the role. A Permissable mix-in might provide a default implementation and/or convenience methods. Classes could override to do things like chaining of permissions. On Tuesday 20 November 2001 05:10 pm, Tavis Rudd wrote: > Correct me if I'm wrong, but it seems that UserKit can't be used with > non-servlet files. UserKit is currently used to provide a user manager, users, roles, hierarchical roles and persistence (via filesystem or middlekit). That doesn't preclude it from being extended or expanded in some way. On Tuesday 20 November 2001 07:21 pm, Darryl VanDorp wrote: > IIRC in the docs it says middlekit can't actually delete anything yet. > Certainly something of importance. No longer true. MK has deletes now. And let's never forget that while all frameworks having missing features, including MK and UK, that doesn't preclude us from extending them rather than shunning them or even worse, reinventing them. BTW MK has the best test suite of any Webware component. On Tuesday 20 November 2001 09:11 pm, Tavis Rudd wrote: > Ok, I see what you're getting at now. In that case, a 'role' is a > set of permissions to perform certain actions on an resource. Users Couldn't a role just be a label? While it might be true that the "editor" role can edit any document on your site, you might later choose to customize one document (say the corporate mission) with permission specs that say "editor cannot edit this". I'd rather edit the custom permissions for the corporate mission, than refactor my roles. On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > In the more general sense, you might want to have relations. A person > can "own" something, perhaps another person is the "creator", or > "manager", etc. I suppose that's what you were thinking of as > roles...? Ownership could just be another role. > > Okay, I think we've got three ideas of roles just in this one email. > Damn terminology. If you're going to say person X is manager of Y, then I think the right term would be relationship. My idea of permissions though is oriented towards verbs: X can delete Y. That is so much more immediately obvious. On Wednesday 21 November 2001 10:21 am, Tavis Rudd wrote: > But you can't 'import' when you're working with non-servlet files! > How would you protect static content without using Application (or > some funky path manipulations)? Last I checked, all content in WebKit had to go through some kind of servlet that originally came from a servlet factory. Or perhaps the upcoming URL manipulation hooks will provide a place to do this. I'm tired. See ya tomorrow. -Chuck |
From: Ian B. <ia...@co...> - 2001-11-28 08:12:20
|
On Wed, 2001-11-28 at 00:27, Chuck Esterbrook wrote: > On Tuesday 20 November 2001 02:10 pm, Ian Bicking wrote: > > 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. > > Geoff and I have played around with some designs for permissions. > Interesting questions came up: > > - Do you ask the user object if he has permission to do X to Y, or do you > ask Y if user U can do X? You might ask either if they have an opinion, and take the greater (less?) permissive answer. > - How should permissions be archived? Particularly in MiddleKit. > > - Permissions should obviously speak of roles. Should they also be able to > speak of specific users? Well, it's a big pain if there isn't an escape for those few instances when the normal process deviates. While they are seldom long-term, in the short-term user-specific permissions are conventient. > > And how about the term 'resource' rather than 'object'? > > I think this adds another conceptual layer that will obscure more than > enlighten. At least that's my thoughts until I see some text that spells > things out some more. I think the only problem with object is that it is more granular than most (well, all) permission systems are likely to be. Probably every resource will be wrapped in an object, if it isn't already an object, but every object will not be a resource in terms of having permission restrictions. Also, resources may actually be more like a list of parameters and a class -- the resource isn't identicle to the particular instantiated object that represents it at any one time. So you can't use id() to get the ID WTO permissions. > On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > > In the more general sense, you might want to have relations. A person > > can "own" something, perhaps another person is the "creator", or > > "manager", etc. I suppose that's what you were thinking of as > > roles...? Ownership could just be another role. > > > > Okay, I think we've got three ideas of roles just in this one email. > > Damn terminology. > > If you're going to say person X is manager of Y, then I think the right > term would be relationship. My idea of permissions though is oriented > towards verbs: X can delete Y. That is so much more immediately obvious. I don't feel it actually fits how things are managed and thought of. I've been thinking from the general and back to the specific about this. I think for most of the stuff I've done, the real permissions come down to something like this: Resources are parts of projects. Users have roles inside with respect to different projects. Permissions are a mapping of role->(resource class, action) The resource classes are a bit fuzzy in my mind yet, but I think this is equivalent to declaring a resource, say, "confidential", "financial", etc. So you might say, oh, accountants can edit financial resources for their department. Editors can edit normal content for their projects. You might also give that person the role of Advisor globally, such that they could add comments to anything (well, not to confidential documents). I feel this comes close to matching how people actually work with documents and such in real life. The other big thing that most permission systems don't deal well with is delegation -- even though it is extremely important. Zope is actually pretty cool this way -- being able to add users specific to particular folders. But anyway, there needs to be a way for one user to say, "for this activity, this person can act with my authority." Capabilities have some ideas about doing this -- well, actually I guess that's how all permissions are aquired in a capabilities-based system. In this case, it would be good to have the specific command "user X can do action Y on object Z as though they were me", but also the ability for there to be a hierarchy of roles, or perhaps of permissions, so that a user can give another user as many permissions as they themselves have. Or something like that. It's something that most permissions systems leave out -- except perhaps through the notion of ownership -- and lack of delegation causes lots of annoyance for users to get to do what they want (and in turn encourages overly permissive systems, since at least then it won't get in the way). The idea of actually going in and finding documents and changing their permissions is painful to me. It won't be done, or to the degree that it is done, it means the permissions will become a mess and no one will be able to figure them out (i.e., audit them) with any ease or through any larger structure. Especially when you are dealing with lots of small resources, ones which users might not even realize are distinct... it's just messy. Then you have to think about what permissions will exist for newly created object, how permissions might be inherited, how you can do search-and-replace for permissions, how you add new groups and give them access en masse, etc. That's why I really don't like ACLs, and a lot of those criticisms apply to capabilities too, since they aren't that different. Ian |
From: <ir...@ms...> - 2001-11-28 18:08:27
|
On Wed, Nov 28, 2001 at 02:12:13AM -0600, Ian Bicking wrote: > > - Do you ask the user object if he has permission to do X to Y, or do you > > ask Y if user U can do X? > > You might ask either if they have an opinion, and take the greater > (less?) permissive answer. If there's a single, convenient wrapper method that does all this and returns a boolean (or raises a security exception), OK. But I wouldn't want to do this min(userPerm(action), objectPerm(action)) on every protected object, or worse, have to change it everywhere if my policy changes. Perhaps some little plug-in class express the permission policy, and then changing it in certain instances would merely be a metter of overriding the class and somehow attaching the new policy instance to the object/resource. > > - How should permissions be archived? Particularly in MiddleKit. > > > > - Permissions should obviously speak of roles. Should they also be able to > > speak of specific users? > > Well, it's a big pain if there isn't an escape for those few instances > when the normal process deviates. While they are seldom long-term, in > the short-term user-specific permissions are conventient. > > > > And how about the term 'resource' rather than 'object'? > > > > I think this adds another conceptual layer that will obscure more than > > enlighten. At least that's my thoughts until I see some text that spells > > things out some more. > > I think the only problem with object is that it is more granular than > most (well, all) permission systems are likely to be. Probably every > resource will be wrapped in an object, if it isn't already an object, > but every object will not be a resource in terms of having permission > restrictions. > > Also, resources may actually be more like a list of parameters and a > class -- the resource isn't identicle to the particular instantiated > object that represents it at any one time. So you can't use id() to get > the ID WTO permissions. > > > On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > > > In the more general sense, you might want to have relations. A person > > > can "own" something, perhaps another person is the "creator", or > > > "manager", etc. I suppose that's what you were thinking of as > > > roles...? Ownership could just be another role. > > > > > > Okay, I think we've got three ideas of roles just in this one email. > > > Damn terminology. The lowest level are objects/resources. I prefer the term object, keeping in mind that we're not talking about every single Python object, but only the ones that are "significant" in the app's security model: Customer, Widget, SalesOffice, etc. Python objects that are private to one of these significant objects need not be dwelt on, since they just "go along for the ride". One problem with the term "resource" is that external OS resources (file, window, etc) are also called "resources". The next level up are actions, specific to each object/resource: WidgetOrder.View, WidgetOrder.Cancel, WidgetOrder.Update, etc. The third level are roles/groups. Abstract names like "InferiorPeon", "CustServiceRep", "Manager", "God", etc. Users belong to groups/have roles. Groups/roles may also belong to groups/roles (per Tavis' suggestion). Here, the group terminology parses better in English. Permissions are the linkage between a role/group and an action. A role/group has permissions to several actions. Or one can just call the actions themselves "permissions". Ownership is an orthogonical layer Zope has (now) but MySQL doesn't. I would avoid adding it as long as possible. We've already seen several conflicting meanings for "ownership": 1) Which user(s) may change an object's permissions. (Tavis) 2) To support three independent sets of permissions: user/group/other. (Unix filesystem) 3) Some esoteric thing to plug a security hole. (Zope) > Resources are parts of projects. > Users have roles inside with respect to different projects. > Permissions are a mapping of role->(resource class, action) Similar to what I'm saying, I think. > The resource classes are a bit fuzzy in my mind yet, but I think this is > equivalent to declaring a resource, say, "confidential", "financial", > etc. Yes. These would prob'ly map to actual Python objects, even if they are just "empty" convenience objects. > But anyway, there needs to be a way for one user to say, "for this > activity, this person can act with my authority." Zope proxy roles alert! Zope proxy roles alert! Isn't it possible to do this with permissions only? The delegate only needs your permissions, they don't have to "act as you" as a separate concept per se. Allowing users to extend their permissions onto others ("grant/revoke") would effectively do the same thing, no? Proxy roles aren't evil per se, but they do add a whole lot of complication to the model, and prob'ly make ownership more necessary than it would otherwise be. So I'd rather make sure we really need them before adding them. > Capabilities have > some ideas about doing this -- well, actually I guess that's how all > permissions are aquired in a capabilities-based system. Dunno what "capabilities-based system" is... -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Ian B. <ia...@co...> - 2001-11-28 18:50:56
|
On Wed, 2001-11-28 at 12:15, Mike Orr wrote: > On Wed, Nov 28, 2001 at 02:12:13AM -0600, Ian Bicking wrote: > > > - Do you ask the user object if he has permission to do X to Y, or do you > > > ask Y if user U can do X? > > > > You might ask either if they have an opinion, and take the greater > > (less?) permissive answer. > > If there's a single, convenient wrapper method that does all this and > returns a boolean (or raises a security exception), OK. But I wouldn't > want to do this min(userPerm(action), objectPerm(action)) on every > protected object, or worse, have to change it everywhere if my policy > changes. > > Perhaps some little plug-in class express the permission policy, and > then changing it in certain instances would merely be a metter of > overriding the class and somehow attaching the new policy instance to the > object/resource. Oh, of course this would be packaged up in various functions. It might be like: def canaccess(object, actor, action): if hasattr(object, '__restrict__'): result = object.__restrict__(actor, action) if hasattr(actor, '__allow__'): return result or actor.__allow__(object, action) else: return result elif hasattr(actor, '__allow__'): return actor.__allow__(object, action) return 1 Actor might be a user (as in ACLs), a process (as with capabilities), or an explicit permission object (also like capabilities). > > > On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > > > > In the more general sense, you might want to have relations. A person > > > > can "own" something, perhaps another person is the "creator", or > > > > "manager", etc. I suppose that's what you were thinking of as > > > > roles...? Ownership could just be another role. > > > > > > > > Okay, I think we've got three ideas of roles just in this one email. > > > > Damn terminology. > > The lowest level are objects/resources. I prefer the term object, > keeping in mind that we're not talking about every single Python object, > but only the ones that are "significant" in the app's security model: > Customer, Widget, SalesOffice, etc. Python objects that are private to > one of these significant objects need not be dwelt on, since they just > "go along for the ride". One problem with the term "resource" is that > external OS resources (file, window, etc) are also called "resources". Well, not only aren't all objects controlled by permissions, permissions act on something more abstract. All the objects in a system die when the system is restarted (i.e., the AppSerter is restarted). The permissions weren't references those specific instances that existed. (Though, if you are using the ZODB, you could say that they were attached to specific objects) Anyway, with Webware they were probably referencing something more abstract. A customer isn't an object -- the customer object comes and goes. The customer is a class and parameters. > The next level up are actions, specific to each object/resource: > WidgetOrder.View, WidgetOrder.Cancel, WidgetOrder.Update, etc. Of course, if we consider functions to be first-class objects, then actions are just methods, which are just objects themselves. OTOH, not every method will be restricted, and (maybe) not every action will be a method (though I can't think of an example of that). > The third level are roles/groups. Abstract names like "InferiorPeon", > "CustServiceRep", "Manager", "God", etc. > > Users belong to groups/have roles. Groups/roles may also belong to > groups/roles (per Tavis' suggestion). Here, the group terminology > parses better in English. > > Permissions are the linkage between a role/group and an action. A > role/group has permissions to several actions. Or one can just call > the actions themselves "permissions". > > Ownership is an orthogonical layer Zope has (now) but MySQL doesn't. > I would avoid adding it as long as possible. We've already seen several > conflicting meanings for "ownership": > 1) Which user(s) may change an object's permissions. (Tavis) > 2) To support three independent sets of permissions: user/group/other. (Unix filesystem) > 3) Some esoteric thing to plug a security hole. (Zope) > > > Resources are parts of projects. > > Users have roles inside with respect to different projects. > > Permissions are a mapping of role->(resource class, action) > > Similar to what I'm saying, I think. No, quite different I think. In this system you aren't a "Manager", you are a Manager OF something. That's more specific. And when a new project X is added, I don't want to create a new ManagerX, EditorX, PeonX group -- projects should be able to come and go easily, and creation of projects (or subprojects) should not require special authority. So the roles are considerably different -- they are much more granular, really, because they indicate a class of objects that they relate to. Also, resources are classified, they aren't directly attached to permissions. Resources might be classified into projects, or more abstractly (e.g., "financial"). Then the mappings are stored entirely seperately and centrally. They are not attached to users OR to resources. > > The resource classes are a bit fuzzy in my mind yet, but I think this is > > equivalent to declaring a resource, say, "confidential", "financial", > > etc. > > Yes. These would prob'ly map to actual Python objects, even if they are > just "empty" convenience objects. > > > But anyway, there needs to be a way for one user to say, "for this > > activity, this person can act with my authority." > > Zope proxy roles alert! Zope proxy roles alert! > > Isn't it possible to do this with permissions only? The delegate only > needs your permissions, they don't have to "act as you" as a separate > concept per se. Allowing users to extend their permissions onto others > ("grant/revoke") would effectively do the same thing, no? > > Proxy roles aren't evil per se, but they do add a whole lot of > complication to the model, and prob'ly make ownership more necessary > than it would otherwise be. So I'd rather make sure we really need them > before adding them. I hadn't known Zope had proxy roles. I get the impression you don't like them? I wasn't thinking of becoming someone, really, or giving someone your identity. Rather, I was thinking of giving someone your authority -- presuming authority was an abstract notion/object apart from user. So you might say "give person X my permission Y and Z", not "let person X be me". > > Capabilities have > > some ideas about doing this -- well, actually I guess that's how all > > permissions are aquired in a capabilities-based system. > > Dunno what "capabilities-based system" is... I put some links on the Wiki, in UserHandlingProj, if you are curious. Basically, in a capabilities-based permission system, each process has "capabilities", which are essentially permissions. The process can be given new capabilities by other processes, or when it is started up, and the process can choose to do something with only a subset of its capabilities. It makes restricted execution fairly easy, for instance. This is in contrast to ACLs, where a process simply is doing something for a particular user. There isn't any granularity, because the user either chooses to run the process as himself, or not. Also, the process can't be specific about the permission it is trying to use -- for instance, it cannot choose to do something with a subset of the user's permissions. Anyway, that's capabilities for you (for the most part). Ian |
From: <ir...@ms...> - 2001-11-28 17:29:55
|
On Tue, Nov 27, 2001 at 10:27:58PM -0800, Chuck Esterbrook wrote: > > 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. > > My first impressions is "no". We don't need to require a sense of > ownership as part of providing a framework for user management and > permissions. In fact, granular permissions about who-can-do-what seem to > obviate the need for ownership. If an object knows that "chuck can *; > tavis can view, edit, delete; others can view" then ownership becomes > useless (unless you had other uses intended for it). MySQL gets by just fine with just permissions. There is a root user with all permissions. He creates users and gives them add/change/delete privileges on records/tables/databases as he sees fit. One of the permissions is "grant", which allows that user to give permissions to others for the things he has permissions to. I never use the grant feature because it just adds unnecessary complications (a more complex structure to keep track of, and a potential security hole if certain users are untrustworthy--not that that's a problem in my situation), but it does provide a model for avoiding the "ownership" layer. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Darryl <da...@cs...> - 2001-11-29 02:42:54
|
Chuck, Didn't mean to imply (if that's how it was taken) that i believe middlekit was not a solution. However, i wasn't sure how active it was and/if/was being maintained. Just throwing idear's around to see what came up Cheerio, Darryl ----- Original Message ----- From: "Chuck Esterbrook" <Chu...@ya...> Subject: Re: UserKit (was: Re: [Webware-discuss] General inquiry > > On Tuesday 20 November 2001 07:21 pm, Darryl VanDorp wrote: > > IIRC in the docs it says middlekit can't actually delete anything yet. > > Certainly something of importance. > > No longer true. MK has deletes now. > > And let's never forget that while all frameworks having missing features, > including MK and UK, that doesn't preclude us from extending them rather > than shunning them or even worse, reinventing them. > > BTW MK has the best test suite of any Webware component. |
From: <ir...@ms...> - 2001-11-29 03:21:27
|
On Wed, Nov 28, 2001 at 08:42:52PM -0600, Darryl wrote: > Just throwing idear's around to see what came up Gotta watch out for those flying idears. They can hit like a boomerang. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Darryl V. <da...@cs...> - 2001-11-21 03:30:23
|
How do you mean "soft-code"? -D ---------------- * ability to tie into existing databases without needing to migrate data (i.e. soft-code the fields used) |
From: Tavis R. <ta...@ca...> - 2001-11-21 03:44:30
|
On Tuesday 20 November 2001 19:27, Darryl VanDorp wrote: > How do you mean "soft-code"? Instead of mandating that the username be stored in a field called 'username' have a setting called 'usernameField' that stores the name of the field used. Then there's no problem if the existing user database has a field called 'user_name' instead. > -D > > > ---------------- > * ability to tie into existing databases without needing to migrate > data (i.e. soft-code the fields used) > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Tavis R. <ta...@ca...> - 2001-11-20 21:17:47
|
On Tuesday 20 November 2001 13:00, Ian Bicking wrote: > > Here's what I consider the essential aspects of a UserManagement > > system: > > > > * secure authentification mechanism that works with or without > > cookies > > Not included Does it use cookies by default? If we tied up the discussions from the last few weeks about this issue and chose a mechanism then this would be a moot point. > > * concept of both users and groups (completely separate from the > > OS!) > > Yes, calls them roles. Ah, but 'groups' are not the same things as 'roles'. I'm using 'groups' in the traditional unix sense of the term, but with the proviso that a group can belong to other groups. 'roles' are something completely different. A better term for 'roles' is 'actions'. In the context of web publishing, actions could include the following: view, edit, delete, rollback, publish, hide, etc. example: members of group X are allowed to view object Y, but not edit/delete/etc. it. From memory, Zope's concept of 'roles' is not what I'm thinking of. There should also be a catch-all group like 'everybody'. > > * support for multiple data stores(flat file, BDB, various > > relational databases, etc.) > > * ability to tie into existing databases without needing to > > migrate data (i.e. soft-code the fields used) > > It does have flat file and MK -- that implies other stores wouldn't > be hard I guess I should take a look at the code. > > * good logging > > This might be incidental to what UserKit actually does -- well, I > don't think it is meant to *do* anything, only be a way to query > information (about users) -- logging every query is very noisy. I just mean at the authentification stage. > What UserKit could really use is some good examples and docs -- not > thorough, but more like a map. It didn't seem entirely clear to me > how it fit together. The code itself seems very compact (all the > more reason docs are important). Who's using UserKit??? Chuck, Tom, Geoff? anyone else? > I think permissions should be considered something of a different > issue -- ACLs being traditional at this point, but not always > appropriate. They are closely tied to the system's notion of a an > object and the granularity of permissions. Permissions (aka authorization) are a layer on top of the authentification system, so maybe we should start there. I did a whole bunch of this stuff (several thousand lines) in PHP before I got sick of it and moved to Python. I'll see if I still have it sitting around somewhere. |
From: Ian B. <ia...@co...> - 2001-11-20 22:06:58
|
On Tue, 2001-11-20 at 16:27, Tavis Rudd wrote: > > > * secure authentification mechanism that works with or without > > > cookies > > > > Not included > Does it use cookies by default? If we tied up the discussions from > the last few weeks about this issue and chose a mechanism then this > would be a moot point. I meant: it doesn't do logging in or anything connect with the Web by default. > > > * concept of both users and groups (completely separate from the > > > OS!) > > > > Yes, calls them roles. > > Ah, but 'groups' are not the same things as 'roles'. I'm using > 'groups' in the traditional unix sense of the term, but with the > proviso that a group can belong to other groups. 'roles' are > something completely different. A better term for 'roles' is > 'actions'. In the context of web publishing, actions could include > the following: view, edit, delete, rollback, publish, hide, etc. > > example: members of group X are allowed to view object Y, but not > edit/delete/etc. it. I'm not clear on what you are thinking. Roles (to UserKit) are things like, oh, "editor", "contributor", etc. Groups are equivalent. I think what you're thinking of for roles/actions are what I'd call permissions, or maybe capabilities -- you have distinct permissions to edit object X, view object X, etc. > > I think permissions should be considered something of a different > > issue -- ACLs being traditional at this point, but not always > > appropriate. They are closely tied to the system's notion of a an > > object and the granularity of permissions. > > Permissions (aka authorization) are a layer on top of the > authentification system, so maybe we should start there. I did a > whole bunch of this stuff (several thousand lines) in PHP before I > got sick of it and moved to Python. I'll see if I still have it > sitting around somewhere. Well, we can start with authentication if it means we just use UserKit, because using code that exists is very easy :) 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. Zope has a very clear notion of what objects are, but then some of what falls out of that is what I didn't like about it. Ian |
From: Tavis R. <ta...@ca...> - 2001-11-20 22:24:09
|
On Tuesday 20 November 2001 14:10, Ian Bicking wrote: > On Tue, 2001-11-20 at 16:27, Tavis Rudd wrote: > > > > * concept of both users and groups (completely separate from > > > > the OS!) > > > > > > Yes, calls them roles. > > > > Ah, but 'groups' are not the same things as 'roles'. I'm using > > 'groups' in the traditional unix sense of the term, but with the > > proviso that a group can belong to other groups. 'roles' are > > something completely different. A better term for 'roles' is > > 'actions'. In the context of web publishing, actions could > > include the following: view, edit, delete, rollback, publish, > > hide, etc. > > > > example: members of group X are allowed to view object Y, but not > > edit/delete/etc. it. > > I'm not clear on what you are thinking. Roles (to UserKit) are > things like, oh, "editor", "contributor", etc. Groups are > equivalent. 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. 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. > > Permissions (aka authorization) are a layer on top of the > > authentification system, so maybe we should start there. I did a > > whole bunch of this stuff (several thousand lines) in PHP before > > I got sick of it and moved to Python. I'll see if I still have > > it sitting around somewhere. > > Well, we can start with authentication if it means we just use > UserKit, because using code that exists is very easy :) If it's suitable. > 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. > Zope has a very clear notion of what objects are, but then some of > what falls out of that is what I didn't like about it. Ditto!! |
From: Ian B. <ia...@co...> - 2001-11-20 22:54:30
|
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 |
From: Tavis R. <ta...@ca...> - 2001-11-20 23:59:57
|
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 |
From: Ian B. <ia...@co...> - 2001-11-21 02:12:13
|
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 audit. I think there needs to be more opportunities for abstraction in the permission system. Also, a more declarative model might be easier 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 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 bit, etc. > > 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. 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 something. 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 Servlet, perhaps. > 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. Ian |
From: Tavis R. <ta...@ca...> - 2001-11-21 04:04:19
|
another thing we should consider is that if the permissions system is to be able to manage non-servlet files in situations where cookies aren't available we might need to use an IP based system ... unless we were to pass on the session ID in a query string even though it is a non-servlet file that won't be using the query string. Clark's path-based sessions might come in handy for this. |
From: Tavis R. <ta...@ca...> - 2001-11-21 04:01:42
|
On Tuesday 20 November 2001 18:15, Ian Bicking wrote: > 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. Ok, I see what you're getting at now. In that case, a 'role' is a set of permissions to perform certain actions on an resource. Users and groups that are given the 'role' editor for a resource are allowed to edit but not delete it. By allowing a group to belong to other groups you get this behaviour. What you're suggesting would internally be implemented like this anyway ('editor_of_book1'). The question then, is whether the implementation details should be hidden from the user. > > 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 audit. There are ways to allow inheritance of permissions that would get around this. > I think there needs to be more opportunities for abstraction in the > permission system. Also, a more declarative model might be easier > to manage. More declarative in what sense?? > > > 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 bit, etc. I just mean for the hooks to be built-in. That would not require that everything have an owner. > > > 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. > > 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 something. > > 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 Servlet, perhaps. Yeah, that makes sense. So it's just a matter of providing an exception handler for unhandled permission exceptions. > > 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. Ok, then so the only way to use UserKit to manage permissions for non-servlet files would be to call it from the Application class like I was suggesting. |
From: Ian B. <ia...@co...> - 2001-11-21 05:25:22
|
On Tue, 2001-11-20 at 23:11, Tavis Rudd wrote: > > 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). [...] > Ok, I see what you're getting at now. In that case, a 'role' is a > set of permissions to perform certain actions on an resource. Users > and groups that are given the 'role' editor for a resource are > allowed to edit but not delete it. By allowing a group to belong to > other groups you get this behaviour. What you're suggesting would > internally be implemented like this anyway ('editor_of_book1'). The > question then, is whether the implementation details should be hidden > from the user. I suppose roles (or whatever -- I don't have a word for quite what I was thinking about) could be implemented as groups. You could have an editor group, to which editor_for_book1 would belong. But I don't want to have an editor_for_book1 group at all. I guess what bothers me about that is that book1 is local to some context -- the books section or whatever -- but editor_for_book1 is global. If every local permission issue has to be resolved with changes to the global permission system (i.e., by adding a group), then it discourages sufficiently granular or accurate localized permissions. > > I think there needs to be more opportunities for abstraction in the > > permission system. Also, a more declarative model might be easier > > to manage. > > More declarative in what sense?? Well, the process to deal with ACLs is usually procedural -- when something happens, you (or your script) go in and manipulate the ACLs just so, to represent whatever happened. A more declarative way would have permissions be more rule-based (where rules might rely on data structures). So when you wanted to express an abstract change of permissions -- like, uh... designers should be able to edit any .tmpl files -- you would add a rule that would say just that, as opposed to doing a chmod like operation. When you can express intentions, I think the result is much more manageable. OTOH, it's easier for people to understand concrete operations... > > > > 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 bit, etc. > > I just mean for the hooks to be built-in. That would not require > that everything have an owner. In the more general sense, you might want to have relations. A person can "own" something, perhaps another person is the "creator", or "manager", etc. I suppose that's what you were thinking of as roles...? Ownership could just be another role. Okay, I think we've got three ideas of roles just in this one email. Damn terminology. > > > 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. > > Ok, then so the only way to use UserKit to manage permissions for > non-servlet files would be to call it from the Application class like > I was suggesting. I suppose -- but I don't really see how Application is necessary. You can always just import the module and use it directly. Isn't that good enough? I don't see what Application gives you that plain modules don't -- they are both similarly global. Ian |
From: Tavis R. <ta...@ca...> - 2001-11-21 17:15:48
|
just curious... |