[for want of a better place I post this here]
With OmniBase finally available under Squeak (/me pats: self on: shoulder), I've started work on the content management system (and more) that will, hopefully, run my cdegroot.com website some time this century. For now, there's some marginal information on http://swiki.squeakfoundation.org/sea/66 - it's still too much vapourware to start a website for.
Anyway, if you read the design note on http://swiki.squeakfoundation.org/sea/75, you will notice that I'm planning to make Sagan completely free of ACL's. And as I don't want to make the mistake of slapping security on as an afterthought, I'd like to sollicit any ideas before commencing work on this layer.
The basic idea I have is that you are always known to the system as a user - where most users will all start out sharing the same 'anonymous' user, with a sort of 'copy-on-write' mechanism creating a private set of capabilities as soon as the user gets new capabilities. The capabilities are kept server-side, the user can access them by authenticating (by whatever means - probably I'll start out with a cleartext password on an unsecured connection ;-)). Capabilities are persisted, of course, in OmniBase.
Ideally(?), there would be a mesh of capabilities between the m users and the n objects to protect. However, I fear that this m*n number may be a tad unmanagable for, say, 1000 users and 10,000 protectable objects.
So, the first thing I'm looking for is ways to lower this count, maybe by grouping objects in some way and handing out a single capability to them, etcetera. Questions to be answered: can this be done without impairing either security or user-friendliness? If yes, what is a good basis for this grouping?
The second issue, more down-to-earth, is how to implement capabilities. On an object with n methods, you can theoretically hand out
n -- \ (n) / (k) -- k=1
different capabilities ("[\sum_{k=1}^{n} \left( \begin{array}{c}n \ k \end{array} \right)]" if you're into LaTeX). That's a tad high to resolve with static classes. So some sort of dynamic wrapper must be made to represent capabilities, and it must be lightweight and space efficient, because Sagan is going to store lots of them.
I had a third issue, but an incoming phone call popped that off the stack.