The following is a proposal for a security plugin architecture for
Vulcan / Firebird 3.0. While the configuration issues are necessarily
specific to Vulcan and follow ones, the plugin API and semantics may be
applicable as an internal service in Firebird 2.0.

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. 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:

class SecurityPlugin
{
public:
SecurityPlugin(SecurityPlugin *chain);
virtual ~SecurityPlugin(void);

virtual int getAPIVersion(void);
virtual ConfObject* getConfiguration(void);
virtual Connection* getConnection(void);
virtual void userInfo(int dpbLength, const UCHAR* dpb,
int itemsLength, const UCHAR* items, int bufferLength, UCHAR* buffer);
virtual void updateAccountInfo(int apbLength, const
UCHAR* apb);

protected:
ConfObj configuration;
SecurityPlugin *chain;
};

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.

Error conditions within a security plugin are handled by throwing
OSRIException objects.

Security plugins are controlled by Firebird configuration files. The
attribute "SecurityManager" controls the selection of a named security
manager object within the configuration files, and may be declared per
database, per provider, or globally. A security manager declared within
a database object takes precedence of one declared in a provider object
which takes precedence of a global declaration. An example of a
SecurityManager attribute is:

<database employee.fdb>
filename $(root)/databases/employee.fdb
provider engine8
DatabaseFileShared yes
SecurityManager SecurityDb
</database>

The configuration file security manager object may contains attributes
specific to a particular security plugin and security policy. An
attribute in a database object takes precedence of the security manager
object which takes precedence over the provider object which takes
precedence of a global declaration. In specific, database attribute
"SecurityDatabase" overrides the "SecurityFile" contained in a security
manager object. Two special values are recognized for
"SecurityDatabase". The value "none" means that user authentication is
disabled. The value "self" means that user authentication is to be
performed using local database tables. A security database will
normally have a "SecurityDatabase" value of "self".

A security manager object can reference one or more security plugins to
control different aspects of database security. An example of a
security manager object is:

<SecurityManager SecurityDb>
SecurityDatabase $(root)/security.fdb
AuthAccount user
AuthPassword lookup
SecurityPlugin SecurityDb
</SecurityManager>

The security manager object can, in turn reference a SecurityPlugin
object describing the loadable module. Like the provider object, a
security plugin object may reference a set of library pathnames to
accomodate mixed 32/64 bit platforms. An example of a security plugin
object is:

<SecurityPlugin SecurityDb>
library $(root)/bin/securitydb $(root)/bin64/securitydb
</SecurityPlugin>




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