Modularizing Security

[paul90]

Closing #109 - it somehow got the branches reversed when creating the pr

Part of fedwiki/wiki#64

This pull request contains the server changes needed as part of modularizing security.

A very basic security scheme is provided as part of this request, see lib/security.coffee which does not provide authentication, but makes claimed sites read-only while leaving unclaimed sites editable by all.

[WardCunningham]

I have run this branch locally for several weeks now and am excited to see it merged and published. I have encountered one small glitch that I have yet to fully diagnose. More on that later unless it turns out to be my own operator error. I've also realized that the implementation invites a rethinking of the farm site claiming sequence which could be important. Paul confirmed that I wasn't thinking crazy thoughts so I will share my observations now.

Paul has clarified my thinking by separating authentication from authorization. He has nicely maintained the site creation mechanism of wiki farms which only exist because I needed a quick way to make sites while testing the earliest of forking mechanisms. I'm amazed that they have worked as well as they have and now consider them an important part of wiki.

But as implemented the mechanism has this strange property of collecting stray empty sites with all manor of weird domain names. I would like to tighten up the rules for making sites just a little and then we will be in good shape for tightening even more on behalf of organizations (like schools) that have to account for everything they ever store.

The solution, now possible, is that a site would appear to exist but would not store one byte of anything until a site is claimed. The first bytes would in fact be the identity of the claimant. We would call an unclaimed farm site "ephemeral" since it would disappear from the server once the welcome page has been served.

Here is what I find attractive about ephemeral sites as the operator of several farms:

• I have a validated email for every byte I store.
• I could further restrict claims to those with a particular email host.
• My users could still experiment without login (or publication) with temporary storage in the browser.

I haven't yet thought through how this would impact non-farm sites or sites that haven't yet configured their security plugin or run privately on localhost. I've also not thought through what impact this would have on the control flow in the express server. I thought it best to consider this adjustment before moving forward with this pull request.

[paul90]

There are, I think, two issues here:

1. Empty sites being created with unexpected names, and
2. Delaying the creation of new wiki sites to when they are claimed.

Blocking unexpected names

Blocking the creation of wiki with unexpected names is simply achieved by either:

1. Adding a check to the code to ensure that the requested domain matches an expected pattern, or better
2. By running wiki behind a reverse proxy, like Nginx or Apache.

My personal preference is to use a proxy, as they can be used to provide further protection.

Delaying Site Creation

The current farm code just looks at the HOST header and either passes it to the server instance for that host, if it exists, or creates a new server instance.

Before creating a new server we would add a check that the wiki has already been created, if it has the request will proceed as now. If the wiki sites does not already exist, the request would be directed to a read-only sandbox. This will require a slight change to the existing fall-back security scheme to make sites regardless of ownership read-only.

Some new code will be needed to add the ability to claim a site, this would require the user to login, create the new site, and change the farm's routing to direct requests for the newly created site to the correct server rather than to the sandbox.

An alternative route, for those Farm Owners who don't want to enable a read-only sandbox, would be to block access for unknown HOSTS. New sites would then need to be provisioned by creating the site's directory and ownership file.

[WardCunningham]

Our core server code must work well in multiple circumstances. I will list some of these without regard to how various pluggable security mechanisms might be crafted to support them. Working from smaller to larger ...

• Temporary server launched to edit local files such as documentation pages in a plugin under development. wiki -d . -p 4000. I've been having a bit of trouble in this mode which I mention above.
• Localhost server for keeping private notes for oneself. If this is run as a farm then various short names can be added to /etc/hosts to make new notebooks. Some browsers relax this even more providing implicit wildcard subdomains. I run these on port 80 as a personal convenience but this has its own risks.
• Private LAN servers cooperating using Zero-conf or similar mechanisms. David knows more about this than I do. I think it remains a struggle.
• Experimental server open to all as a playpen for learning our cooperation style. This is my favorite case because I use this mechanism nearly daily in my promotion of federated wiki.
• Community server for a specific community creating long-lasting and valuable content. This might be authorized by sharing an event-code that the community would use to authorize.
• Regulated organization like a school or company with strict networking practices in place. Here privacy, security and policy must be observed.

[opn]

@paul90 this basic security scheme for a read only site would be great if it also allowed for that site to disable the drag-and-move interactions. I guess this is an indendent request but the idea that simply by removing an authentication plugin you got a stable read-only site is appealing.

[opn]

An early thought - but I like the idea of integrating an easy to implement form of self-rolled authentication based on IPFS/IPNS. The idea would be that you could give out a long unique url for an IPNS address that would refer in turn to a we page on IPFS. This web page would provide an authentication cookie to your site. By giving out and bookmarking the IPNS entry to this cookie generating page you would control access to your site - first go to the capability url (IPNS url) - and then from there link off to FedWiki.

I think this may allow easy(ish) custom creation of your own login - you roll it on your laptop - while creating it in a globally accessible way through any public IPFS gateway. It also pushes the IPFS integration - which I'm keen on :)

[paul90]

• Temporary server launched to edit local files such as documentation pages in a plugin under development. wiki -d . -p 4000. I've been having a bit of trouble in this mode which I mention above.

Spotted the error, the Mozilla Persona security module was not allowing unclaimed sites to be edited.