Hi Again! Thanks for the response, I'm glad to finally get some feedback. I've added some more thoughts into the message:
> -----Urspr�ngliche Nachricht----- > Von: Christopher Lenz [mailto:[EMAIL PROTECTED]] > Gesendet: Dienstag, 08. Oktober 2002 22:10 > An: Slide Developers Mailing List > Betreff: Re: AW: While List is Alive: Roles !! > > > Hi Richie, > > Unger Richard wrote: > > Let me think about this... Basically, I think the goal should be to > > implement a more 'conventional' system for how the roles > work. The exact > > details of the storage don't matter, I think. The main > point is that users > > expect, based on past experience, to be able to add and > remove roles, and > > assign them to users. Also, roles are a good, clean way to implement > > security policies, and it seems to me completely compatible > to slide's ACL > > permissions system. > > I'm not arguing about the value of roles, I agree they're a nice and > important thing to have. > > > The real question is why the decision was made to associate > each node in the > > namespace with a role. For the users and groups this makes > sense, but it is > > not obvious to me why this is necessary for the other > nodes. What is the > > reason for this? It seems to me that the nodes should be > associated with a > > 'type' (eg: userNode, fileNode, collectionNode) rather than a role. > > Note that nodes can basically have more than one 'type' or > 'role' if you > take collections into account... in particular a user-node is also a > collection-node. > > Currently there is the DAV:resourcetype property that > determines whether > the node is a collection, as well as the role, which > determines whether > the node is a user, for example. I believe that the DAV:resourcetype > concept should be supported directly in Slide, probably by a new and > improved role system, and become a live property. > I have to admit I am not sure what is meant by live property and dead property. Perhaps this is explained in the webdav spec. I think that there should be *one* system for determining the type of a node. Storing some type information as properties, and some as the role, directly in the node, seems inconsistent to me. Also, it is not obvious to me why the role has to have anything to do with the type. In fact, it does not make sense to me to assign roles to nodes of any type except a usernode or a groupnode. Why does a fileNode have to be associated with the role nobody? And what purpose could there be in changing the role to 'rootRole' or some other role? The permissions for accessing the fileNode can be fully controlled with the ACL properties, there seems no need to give this type of node a role. > > However, to answer your question, my specific proposal would be the > > following: > > > > 1) Create 3 special collections: users, groups and roles > (by default in > > /users /groups and /roles) > > 2) Store the users in the users collection, as they have > been so far. > > 3) Store the groups in the groups collection, as > collections with linkNodes > > for each user belonging to the group. > > 4) Store the roles in the roles collection, as collections > with linkNodes > > for each user or group that is a member of the role. > > Then, to repeat a question from my previous email, what is the > difference between roles and groups?? The above description > implies they > are functionally identical. > They are in some sense functionally identical, in the sense that they provide an aggregate function for setting permissions for a whole bunch of users. I do not know exactly how these things are implmented in slide, but in other systems it is possible, for example, to assign the group a password, and allow people to log in using the groupname and password. This is not possible with roles. On the whole I would agree they are functionally idetical to groups, but nonetheless, I think they provide an important second level of flexibility in configuring permissions. > > 5) Define some more 'rules' about how it all works: eg: don't allow > > singlegroupmembers, allow only alphanumeric characters for > user, group and > > role names, etc, to prevent degeneracies. > > Also, allow user nodes only as direct members of the users collection. > Exactly! > > Your proposal also seems reasonable, but there is some issues: > > * If we put the list of roles in the class for the node, > changing the roles > > will require rewriting the node. > > No, it would require *some* code to add/remove the role from the node. > I meant that the node will have to be rewritten to the slide file system. Basically, I was wondering if it is legitimate to rewrite the node when the roles change, without creating a new version of the node. It is a bit confusing that the node can have 'content', but still its own content as well. > > * It seems to me that there is already some 'confusion' > about the storage of > > security data: The users and groups are stored on the slide fs, as > > 'structure'. The ACLs and user Passwords are stored in the > node revision > > properties. And the roles are stored in the nodes > themselves. I think it > > would be better not to mix this up, and store the roles > either on the slide > > fs, like the users and groups, or store them in the node revision > > properties, like the passwords. > > Add actions to the list of security-related entities that live in the > Slide structure > > IMHO, having a node for every tiny piece of information maintained by > Slide is overkill. Retrieving/storing/removing a node is > *substantially* > more expensive than just keeping a list of strings in the node. > > Actually, I would like see much *less* data stored as nodes, ideally > only the *actual content*. But that of course is a quite > radical point > of view ;-). > Perhaps, but it is worth thinking about. My opinion is that things are a bit mixed up in terms of 'where' they are stored, as I wrote in the last email. I think it is worth defining clearly ones goals and purposes. Perhaps it really would be better to find a different system for the users, groups and roles (and actions), and not store them on the slide filesystem. > > Who did the work on the original system of roles and nodes? > I would really > > like to know what the reason was to make every node > associated with a role, > > and whether there is a need for this... > > That would be Remy and Dirk, AFAICT. There was also some talk about > revamping the security subsystem for Slide 2.0, mainly initiated by > Dirk, but it hasn't been further discussed since then. You might have > luck searching the slide-dev archives. > Well, Slide 2.0 is around the corner, perhaps we should do it! :) I think we are more or less in agreement about the function roles have in a security system. I think we should implement a classical system of roles, users and groups, where roles can be added and removed as expected. What remains to be discussed is how to fit it into slide. Here are two proposals for discussion: Proposal One: Use the Slide File System This is basically what I proposed last time: Move the roles onto the file system, store the groups in their own collection, and user link-nodes to create the associations. To me this has the advantage of consistency. All the user related information is stored in a logical way on the file-system. Additionally, it may be possible to manipulate the groups and roles simply using the webdav protocol, also practical. On the other hand, storing this security information in the same place as the content can be a security hazard too. Perhaps it would be better to prevent all webdav access to the groups... Another big advantage of this proposal is that all the storage mechanisms are already in place, and a core part of slide, much tested. The users are stored with the same flexibility as the content, and the slide administrator does not need to worry about aditional setup. An different way of storing the users would require its own code, introduce new bugs and presumably add to slide's configuration. Proposal Two: Use a new storage system Since the users, groups, roles and actions have little to do with the content, there is no pressing reason (other than the practical ones listed above) to store this information on the slide file-system. In fact it may be more secure to put it elsewhere. A specific proposal might be to create a kind of 'userdatabase' object and store all users, groups and roles in this. The entire object could just be serialized to disk (or the slide fs), and loaded again in one piece. The problem with this approach occurs when there are tens of thousands of users, and the userdatabase object gets too large. However, this might be an acceptable trade-off, since I would assume that installations with more than 10000 webdav users are rare. It is worth thinking about... My instincts tell me that the slide file-system is a good way to go. It is all there for us, and gets tested by the test-suite all the time. And it is easy for people to understand and use. In either case, I would propose an API for reading users and user properties, checking role and group membership, and adding and removing users, roles and groups. I don't think it is a good idea to manipulate the node structure directly when creating a new user, and if such an API were used, it would allow slide to change the way the users are stored without too much trouble. The org.apache.catalina.UserDatabase is a good starting point, and I already have some parts implemented. Let me know what you think, and with your permission I would like to start implementing some of this. Thanks, Richie PS: Are you german? Your English is excellent! > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
