Jim et al,

> >currently, firebird/interbase stores security information on a
> >separate isc/security database.
> >
> >I'd like to request an option that allows storage of security
> >information on each separate user database instead.
> >
> I'm committed to a plugable security manager for Vulcan that supports
> both the existing scheme and something useable. Any thoughts on
> requirements or ideas on an API would be appreciated.

John Bellardo was playing with this idea (PAM support) for a while and even
had a draft implementation working, AFAIK. Unfortunately, he wasn't able to
finish this work due to other (non-FB) duties. I'd suggest to contact him
before doing anything in this direction.

> My personal feelings are that security information belongs in a
> database, and that storing a SHA hash of passwords makes the most
> sense. There are other secure hashes. Does anyone has
> strong feelings on the subject?

We should separate database security (users) and authentication
(logins/passwords). Users belong to a database and should be stored there,
whilst logins belong to the external authentication mechanism. There should
be a direct mapping between both. The server should support PAM to allow
different authentication methods (security.fdb, NT domains, Kerberos etc).
The interface should be open and properly documented to allow 3rd party
security plugins. The aforementioned things are key parts of this subject,
IMO.

My local tree contains all necessary ODS changes and slightly reworked SCL
stuff to make it possible inside the engine. SecurityDatabase class is no
longer considered a part of the engine (from the internals POV, as it's
still linked statically). But I've defered this work till (a) proper
discussion here and (b) agreement about PAM interface and implementation. If
you think now it's time to start discussing this topic in details, let's do
it.


Dmitry