Pavel Cisar wrote:

>Well, then I have a problem with your proposal. You wrote:
>
>"Security plugins are daisy chained. A security plugin that does not
>manage a particular method is required to passed the call to the next
>security plugin in the chain (this default behavior can be inherited
>from SecurityPlugin)."
>
>I suppose that chain of SP instances is built for each database from
>config cascade (from db to server to engine built-in default etc.), so
>each database can have slightly different chain. So far, so good, but
>your spec deliberately omits other SP types like db or wire comm.
>encryption or whatever and defer their spec to later date. I think that's
>wrong approach, as it's clear that you're trying to define a base
>class(es) or framework for SP's. While your spec would work for
>authentization SP's, i'm not sure that it would also work in future when
>new SP types would be introduced. As is, i worry that it would need
>parallel structures to handle new security plugin types.
>
>

The test of an architecture is to invent plausible new requirements and
see if they can be accomodated. File level encryption, for example,
requires methods to open, create, read header, read page, write page,
and close files. It clearly fits the model. Extension would require
more methods in SecurityPlugin and the engine hooks to call them. Other
plugins might used a password protected file system catching only the
open and create.

So what do you think that you might want to do that the framework
couldn't handle. Hint: I don't buy the argument that something can't
handle things you haven't even thought of.

>While all SP's in general share some functionality and structure,
>different SP types would also differ, greatly. For example I don't see
>any reason why db page encryption plugins should be chained. Of course,
>they could have cascading config, i.e. different encryption plugins could
>be set for db and server and engine built-in default, but only one would
>be active for concrete database at a time.
>
>

OK, lets assume we have authentication and encryption. How does the
engine know which to call for what? Which takes precedence? How many
independent security management types do we need, each with separate
configuration rules and APIs?

>And that bring me to the Security Manager as a real object (with code),
>that would work as one central point for interaction between security
>plugins and other subsystems, and to assemble security "policy" in form
>of SP instances and their specific settings (from config or whatever).
>Each db would have its own SM instance. For start, SM could be just an
>additional level of indirection, and have (almost) the same interface as
>SP with slightly different implementation (initialization of
>authentication SP chain from config, and simple delegation). This
>indirection introduced from beginning would allow us (at least I hope so)
>to extend the security subsystem more easily in future.
>
>
>

This sounds like complexity for the sake of complexity. Why do we need
two levels? What does it do that the proposal doesn't?