The aim is to make it relatively simple to apply different security models. Be it using a different authentication provider, or different ways of applying restriction to site access.
While we are chiefly concerned with site access we should not loose sight of any requirements at the farm level.
Currently
The current security is built into the core, with a number of limitations around authentication.
- Read-Access
- Open to all.
- Write-Access
- If site is unclaimed, all have write access.
If site is claimed, only the owner has write access.
If a site is unclaimed, authentication on completion will claim the site.
If site is claimed, authentication will fail for all except the owner.
Step Zero
Step one, is probably getting a little ahead of ourselves. An initial step is to untangle some of the code. Currently you are either anonymous or the owner, this leads to some interesting points that need untangling.
The code needs to cope with you either being an anonymous or authenticated user. An authenticated user, may be the site owner or not.
So, we need to separate the role of being a user, and that of being the owner.
Achieving the separation of user and owner in the server is not so difficult, though in this step authorization is not handled correctly (but that is for the next step.
However, like throwing a pebble into a pond the ripples spread. In this case to the client, which currently determines if it is going to write back to the origin server, or use local storage (from wiki.coffee 
):
wiki.useLocalStorage = -> $(".login").length > 0
Though there is more, as if the site is not owned your edits can be saved back to the origin server. Though as soon as we let more that just the owner authenticate, this will not work.
While we could augment the client so that it attempts to save to the origin server, and if it fails we fall back to using local storage.
First Step
Move all access decision making out of the core, into a security module.
All client access should be checking is the client isAuthorized to perform the action. The security module will simply give a yes/no answer.
The security module might need to ask if the user isAuthenticated, and who they are, to provide an answer.
With the current/default security model authenticating to the site only confers additional rights if the user is also the owner. Authentication and claiming site ownership will be decoupled.
Things to Think About
Cross site authentication - the client that gets data from sites within a neighbourhood, but how do those sites know who we are?
Does the user have to authenticate to each site within the neighbourhood individually, or do we use federated identity, but we would then very probably need a trust model.
Do we have to worry about neibourhoods that contain sites that use different authentication schemes?