Re: [SW2] security model

Hi We have been discussing the security model of SW2 lately and now we're stuck. So this is your chance to say what you need, come up with brilliant ideas or pull the emergency brake ;). We're open for anything, don't hesitate to ask questions or make suggestions. The stock SW2 does not have a security model. Maybe it will get one, maybe not, if it gets one it will likely be very simple. Something like locking of Swiki. But that does not mean there isn't a a security model for SW2, you can load it from the MC repository below. This model is the subject of this message. MCHttpRepository location: 'http://kilana.unibe.ch:8888/adl' user: '' password: '' (contact me if you want write permission) The Present The system is based on access control lists which allow you to define a set of access rules for a structure (page, file, component, ...). It is already working and only has some minor glitches (you don't have to confirm the password, stuff like that). A rule looks like this: <Principal> <Allow/Deny> <Action> Principal: is either a user or a group Allow/Deny: should be clear Action: is either a command or set of commands referred as `Command Set' which can be defined almost like a group. So sample rules might look like this: `students are not allowed to Edit' `everyone is allowed to View' `bob is allowed to Remove' The non-abstract commands currently in my image are generic commands for any structure SW2AddCommand (add anything, file, page, component, ...) SW2CopyCommand SW2MoveCommand SW2RemoveCommand SW2ViewCommand page related commands SW2InplaceEditCommand SW2EditPageCommand file related commands SW2EditFileCommand component related commands SW2SettingsComponentCommand SW2EditComponentCommand user management related commands SVAddUMChildCommand (stupid name, add a user/group/command set) SVEditUMChildCommand (stupid name as well, edit a user/group/ command set) access control related commands SVCopyACLCommand SVViewACLCommand SVAddACLItemCommand SVEditACLItemCommand SVMoveACLItemCommand SVRemoveACLItemCommand always allowed SVLoginCommand SVRetryCommand SVLogoutCommand SVChangePasswordCommand (only change your own) special users: root, can do anything, not affected by any access rules guest, aka anonymous, the user who is not logged in special groups everyone, includes every user everyone but guest, any user who is logged in special command sets everything, includes all commands The user management is a special structure named Management which is attached to the root of the wiki like Environment (the meta wiki). A user, a group, everything is a structure embedded into the wiki. Root \+ whatever \+ Environment \+ Management \+ Users \+ User1 \+ User2 \+ Groups \+ Group1 \+ Group2 \+ Command Sets \+ Command Set 1 Limitations Because we just control commands and the add command is generic we can not allow someone to add pages and deny adding of files to him at the same time for the same structure. Is this a problem for anyone?

However we can allow someone to add users but deny adding of groups to him. We don't do any form of spam or flood protection/recognition. We have no concept of administrator or owner. Just root. You can create a group administrators and add a rule `administrators are allowed to do anything' to all structures (add it to root and check the box to add it to all children), but if someone has the right to edit, add or remove access rules he can disable this rule. That would require root to fix it.

The Future Like you can redefine Environment for structures we are looking for a way to redefine Management too in order to allow locally administrated subwikis (like Zope). We have not started with this because we are still struggling with the semantics (the actual reason for this mail). The problems we have encountered so far are: - Do we have a local root user a subwiki? How do we name it and how do we name it in a subsubwiki?

- Are user names globally unique?

Can you redefine users in a subwiki?

If yes what happens if a user enters a subwiki where he is redefined? What if we leaves? What if a redefined subwiki user enters a superwiki?

- What happens if a subwiki user leaves his subwik (does he become guest)?

What if there exists a user with the same name?

- Who is allowed to add a new Management? This is an issue because the Add command is generic and the Management is just a regular structure so if you can add structures then you can add a Management too (we could actually modify (read hack) the description of the Add command to exclude Management and add a separated command for that). If a also have a local root and initialize it's password with a default value (or even ask the user) then you can get all the rights in this subwiki if you have the add command.

- Do you see any case where you need this? (This is probably the most important question of them all).

Another option we discussed lately was the possibility to just add users and groups in the wiki instead of adding a Management but this doesn't seem to make any difference or solve any problems. What currently makes the most sense to me is: Prevent adding of a Management with the Add command (#isValidForAddCommand or something like that) and make an own command for that.

Which makes sense in the long term because certain kinds of structures can only have or be child of certain kinds of other structures. Make user names globally unique because this solves a lot a problems. If you leave your subwiki you become guest. However I'm still undecided on the subwikiroot.