--- In Firebird-Architect@yahoogroups.com, "Dmitry Yemanov"
<dimitr@u...> wrote:

> "Ann W. Harrison" <aharrison@i...> wrote:
> >
> > I disagree here. Giving non-standard behavior to standard syntax is
> > marching into the deep muddy - and you can be certain the water is

going

> > to rise. If we want to do something different from the standard we
> > should use different terminology and be clear that what we're

offering

> > is not what the standard specifies.
>
> I second Ann's opinion.
>
>
> Dmitry

Here's an option that has not been discussed in any depth yet.

1. As a default mechanism, keep the standard syntax and security
mechanisms.

2. As a preferred security mechanism, switch to LDAP for authorization
and authentication. LDAP is only concerned with authorization and
authentication, and while it has a learning curve, it provides a rich
foundation for system and application security models. An LDAP
security model allows, for example, a massively replicated clustered
database set to handle authorization changes without additional
replications.

The folks who designed LDAP knew what they were doing. Rather than
re-inventing security, let's build on their success.

If this approach is used, I see two options that are not mutually
exclusive:

1: embed an LDAP server in Firebird (advantage - performance and
advanced security is available to all Firebird users, disadvantage -
additional code to maintain or dependency on external project)

2: Build an LDAP client sockets library that will talk to any LDAP
server (advantage - Firebird will work with any LDAP server, and the
security question "goes away", becomes the DBA's problem,
disadvantage - advanced security features are outside of the Firebird
envelope)

Note that if both options are pursued, you effectively build the
capacity for Firebird to back the LDAP system.