Dmitry Yemanov wrote:

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

I'm going to quibble with you here. The engine, not the server per se,
is responsible for security. The server, properly speaking, listens to
a variety of network and IPC connections and makes requests against the
Y-valve which passes things off to providers who do the actual work.
Security is implemented in engine, which is a provider. I'm aware that
this is picky, but I've just spent a month re-establishing the component
boundaries, and I'm hoping people will start thinking in layers and
components rather than monolithic masses of amorphic code.

The other quibble is that the engine shouldn't have anything to do with
PAM directly. The engine should be able to instantiate a security
manager that may or may not get nice with PAM.

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

I guess I don't understand why any ODS changes were contemplated or
necessary.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376