Pavel Cisar wrote:

>On 4 Oct 2004 at 11:54, Jim Starkey wrote:
>
>
>
>>A security plugin is a potentially loadable module that manages an
>>aspect of database security. A security plugin can be built in or
>>loaded dynamically.
>>
>>
>
>Great. I suppose that more than one plugin could be built in.
>
>

Yup. At the moment Vulcan has two, SecurityDb and SecurityRoot. Where
the code comes from isn't important.

>>The API used to communicate with a security plugin
>>and for security plugins to communicate with each other is defined by
>>the C++ class SecurityPlug, from which all security plugins inherit.
>>The initial declaration of SecurityPlugin is:
>>
>>
>
>Hard to judge about API feasibility now, but it's for sure a good start.
>
>

It was a first crack. The prototype has already changed.

>>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). The engine provides a builtin security plugin
>>(SecurityRoot) to backstop all methods, provide default security
>>behaviors, and manage communication between the security plugin chain
>>and the database engine. An authentication plugin can be expected to
>>respond to the methods userInfo() and updateAccountInfo() but ignore
>>methods (not yet defined) controlling page level encryption.
>>
>>
>
>Well, I got lost here a little bit. You mentioned Security Manager later
>down this spec, but you didn't sketch it in any way (except config
>options). Is Security Manager (SM) a real object or just a package of
>configuration parameters ?
>
>

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 arrangement of Security Plugins (SP) etc. as you defined it makes
>more sense for me if SM is not a real object but just a tool to package
>security options. If it's true, then I have trouble with it, because
>architecture with real SM object would make more sense for me. If SM is a
>real object, then I have trouble with the rest of spec.
>
>

The SecurityManager is a configuration abstraction that specifies,
directly or indirectly, a security plugin. The security plugin is code.

>I'll go to details once you clarify this basic question for me.
>
>
>

I hope this has clarified. If necessary, we'll draft Ann to translate
between Jim-ese and english.


[Non-text portions of this message have been removed]