[...]

>
> If we decided to use loadable authentication managers, they should
> probably default to a bundled manager that piggybacks on OS
> security. That's more than enough to get started. If somebody
> cares, they can reads the docs. Until they care, however, it
> should do the obvious thing.
>

That was exactly what I had in mind. By plugins, I mean that,
interbase would come, by default, with:
1) native authentication (using isc4 etc)
I'd be happy enough to see this one go away, but for people who
are happy with the existing system don't want to change their
apps, it probably needs to stick around. We just need to be
clear on the limitations.
2) Some other standard methods, for example possibly
* integration with NT domains
* novel NDS
* Kerberos
...

Each of these options would be an 'authentication plugin' which
would have a standardized interface with IB. For 99.9% of users,
configuring this would involve choosing one of the options
listed above. A few people might want to use a plugin
provided by someone else (for example, one contains strong
crypto, integration with and obscure system, or special
hardware like smartcards etc.). A VERY small number of developers
might want to make their own plugins. The specification for the
plugins would, of course, be part of the interbase download.

What I'm getting at is that an authentication plugin would not
be something the typical developer would write along with
their app. Instead, when deploying the app, they would say
'Oh, you already use NDS in your organization. All your
users of the accounting system will need to be in the
accounting_users group' Then they set the NDS account_users
group to be equivalent to the accounting_users SQL role,
and that's the end of it.

To me, the plugins directly address the problems of:
1) verifying that the client is who they claim to be.
2) mapping users/groups to SQL user and ROLE privileges.

It would not directly address the following, although as noted,
some of these problems could logically be addressed at the same
time, or in conjunction with the plugins:
1) Protecting the developers intellectual property (triggers code,
table structure etc.) from the developers customer. But related
security changes (such as eliminating the ability to kidnap
databases if you have your own ISC4) might help. I'm not saying
this isn't a problem, it's just not an authentication problem.
2) encryption of data on disk or over the wire. I believe that
the right way to do this is generic solutions like VPNs etc. In any
case, it is far outside the scope of authentication. If someone does
end up developing these specifically for IB, then some of the
authentication plugin technology could probably be leveraged for
key exchange (once again, by providing connection to existing
key exchange systems).
3) access auditing/logging or on connect/disconnect
triggers. Again, these are note directly part of authentication,
but it might be reasonable to implement these at the
same time, since they could logically sit just on interbase
side of the plugin interface.
4) Providing server level security, such as the right to
create databases and administer the server. Again, this is
related, since the same authentication methods should be usable,
but requires additional work for interbase to have a concept
of privileges outside of a database.

Note that the core IB team would not have to develop all standard
the plugins initially. They would have to do the plugin API, and
the standard default interbase method as reference, and possibly
collaborate with some one knowledgeable on one or two
of the native OS systems.

And now to the off topic side of the thread...
For the record I firmly believe that the binary distribution of
software is evil, that ./configure ; make ; make install is user
friendly, and that VI is the One True Editor. Of course
I also beleive that people who wouldn't build their own
car shouldn't have one. I did and I do. ;-Q.
Direct any flames off list please ;-)

--
Reed Mideke rfm(at)collectivecomputing.com