There are really two parts to the system: authentication and authorization. They should be kept separate. Both of them should rendezvous on CLR roles.

For authorization, any time access to a particular topic is requested, a call to Thread.CurrentPrincipal.IsInRole should be made. Exactly what happens at that point depends on what granularity we want: wiki-level, namespace-level, or topic-level. I suspect the right granularity is namespace-level: fine enough to support most scenarios, not so fine-grained as to make administration into a "why the hell can't I access this page" mental marathon.

Namespace-level authorization information would be read from the _ContentBaseDefinition topic. It would contain content that looked like this:

 AllowReaders: ?
 AllowWriters: FooGroup, BarUser
 AllowAdministration: AdminGroup

Where the value of those properties is a comma-separated list of either role or user names, with the addition of the special-cases "?" for "any authenticated user", and "*" for "anyone including anonymous". We can debate the additional benefit of having corresponding Deny properties, but I think it's better to leave them out - although they enable more complicated scenarios, they also increase complexity.

There will be similar properties wiki-wide, but they will be administered via the /admin pages. In the future, I hope we can have a special Admin namespace so that it would be exactly the same mechanism, but for now we can just go with a /admin page that edits a very simple file called (say) security.config. Although this creates a problem for web farm scenarios...I'm not totally sure how to handle that. I guess it's no worse than the situation right now. But then again maybe this is the opportunity to add a special namespace provider and start migrating configuration information.

The semantics of reader and writer is pretty obvious. The semantics of "administrator" is in my mind "someone with the ability to edit _ContentBaseDefinition, and additionally to 'lock' pages". Locking a page means making it read-only. It may not be supported by all stores (e.g. the filesystem does, SQL Server doesn't). I know locking pages is out of scope for this feature request, but we've needed it a few times, and I think it's going to get baked in at some point. I include _ContentBaseDefinition as a special case because it's the one page that you can edit that will break the wiki.

The calls to IsInRole should occur in the engine, not in the web pages. Hopefully, they can live in the abstract ContentBase class, so that all derived stores (SQL, filesystem, others) can use them in a uniform manner without having to replicate code. Also, because the web is not the only way to access the content - there's a web service this stuff has to work for too, or the security will be pointless.

On the authentication front, we really need that to be pluggable. We've already heard from at least two users who have their own custom auth, and in my commercial security work I can tell you that it's very common for people to have their own password stores. So we'll need some way for people to override the login mechanism. Fortunately, given the authorization scheme above, all we care about is that they set Thread.CurrentPrincipal at the end of it, using whatever roles correspond to the user they just authenticated.

Out of the box, I think we need to support at least two authorization providers: Windows and a simple custom one. The Windows one would rely on IIS Integrated authentication. That's the easy one, because it'll map NT groups to CLR roles automatically for you. The simple custom one would be be driven by the same persistance mechanism as the wiki security info. That is, ideally it would be stored in a topic in a special Admin namespace, but for now we may wind up shoving it in a file fronted by an /admin page.

Assuming it's a file, I see it looking in concept something like this:

 <users>
  <user name="Alice" passwordSalt="asdlkjasdfa" passwordHash="#@Dasdf1asdf">
    <role name="FooGroup" />
    <role name="BarGroup" />
  </user>
  <user name="Bob" passwordSalt="asdoqnfa" passwordHash="l19lasdfafvd">
    <role name="Administrators" />
  </user>
 </users>

Obviously, we'll also need to hook in to the login/logout infrastructure that's already in place. We'll need a way to make sure the login button always shows up, since the wiki could be configured to allow anonymous users to read, but not to edit.

OK, that's all I can think of for now.

This is exactly what we need in our corporation.

Well, I'm actively working on it. It's coming along pretty well, but I wouldn't hold your breath: it's a part-time effort for me. -- CraigAndera