On Sun, 2005-08-21 at 20:34 +0000, Firebird-Architect@yahoogroups.com
wrote:

> The security plugin API is defined by the class SecurityPlugin in
> Vulcan. It is intended primarily for user authentication, but could
> be
> extended. An LDAP based security plugin would be an excellent
> addition
> to the product set. That said, I am wary of LDAP rights management,
> tending to believe that objects within a database system should be
> managed by the database system. I'm not going to say that LDAP based
> rights management is out of the question, but I'm going to need a lot
> of
> convincing.

My thought is to follow your PAM architecture through to its logical
conclusions:

1. SQL92 security PAM for the diehards that prefer (or somehow need) the
less secure model. (backwards compatibility/SQL92 compliance - may not
be needed since this crude sort of security is easily implemented with
LDAP-like structures)

2. Internal LDAP-like security PAM that is entirely internal to
Firebird, but offers the full richness of LDAP like structures. (rich
applications type security at whatever level of detail is required, with
the actual security model becoming a configuration issue)

3. External LDAP connectivity PAM for sites that have, as a requirement,
the capability to manage security in accordance with their existing LDAP
environment. This is a request that is becoming a requirement in many
large shops, as they try to unify security to minimize administration.
(security model is literally someone else's problem. Firebird just
checks to see if requested actions are allowed)

SQL92 security can be readily implemented under LDAP. To reduce the
amount of code to 2 modules, the SQL92 security (item 1) should actually
be implemented under the LDAP-like security (item 2), so there would
only be two actual security implementations written - internal LDAP-like
and external LDAP via sockets. Switching off the SQL-92 clone would
force the DBA to administer security directly through one of the newer
interfaces.

Since the LDAP wire protocol has only 9 commands, the internal security
API could conceivably be exposed via an LDAP compliant sockets API.
Firebird the database could then also provide the option of an
integrated security model for the enterprise, which in turn can be
managed by off-the-shelf command line and GUI LDAP tools. I like the
idea of leveraging other pre-existing products for that level of work.

The PAM's can be implemented as a .so (*nix) or .dll (windoze). The
technical issue that remains is how to make it possible to migrate
security without making the plugin architecture itself a security hole.
The design needs to ensure that some goofball couldn't make a "security"
module that let everything pass.