On 6 Oct 2004 at 10:59, Jim Starkey wrote:

> The security manager is only a (soft) object in the configuration files,
> a place to put attributes needed by a particular security plugin. Maybe
> calling it "SecurityPolicy" would make it easier to understand. Sean?
>
> The SecurityManager is a configuration abstraction that specifies,
> directly or indirectly, a security plugin. The security plugin is code.

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.

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.

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.

Best regards
Pavel Cisar (ICQ: 89017288)
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information