Hi Jim,

>
> Interbase should support basic account/password security (though I
> think the role model needs expansion). More advanced authentication,
> logging, threat detection, IP address based restrictions, account/IP
> address affinity, and security event logging are currently unavailable
> and unlikely to be implemented as part of the core product in the
> near future, even assuming we were able to figure out the "right"
> semantics.
>

That is true, and is a basic assumption on everyones part. Getting the rights
from Inprise and getting the product out of Beta status is the order of the day,
but should not exclude us from discussing different approaches (and given the
speed that Inprise legal is progressing at in processing the paperwork, we have
alot of time to do so)

> A loadable module allows someone to write and distribute a more
> capable security manager that plays with the mainstream product,
> but doesn't require buy-in (or even source distribution) from the
> entire community. It is the type of added value component that
> we should encourage.

I am for anything that allows third parties to earn money from adding value to the
product, but, security is one of the parts of application design that is very
specific to the developers needs. For alot of users, they never needed more than
what IB provides today.
BUT, for those who do need security, there needs are usually very strict and
beyond any "one size fits all" solution. So, either the Developer keeps on paying
for a third party company to make the database specific changes, or does them for
themselves.

> I don't expect most users will ever feel the urge to even consider
> writing their own security manager -- if we build the hooks correctly,
> they'll be able to acquire one appropriate to their needs.

Most users I have met and discussed things with on the net, all talk about
security. Even today, I recieved two emails asking how to secure Interbase in
some way or another.
A developer who writes alot of custom SP code does not want to give it away for
free with his/her application, nor does a company want some users to have 24 hour
access to thier employees.

> But if they feel compelled to write one, I think it is completely
> appropriate that it be written in a language for grownups.

Alot of users of interbase have never performed any advanced programming
techniques.
Most are Delphi Users who are using Delphi like a faster version of Visual Basic.
Others use ODBC and HTML to access thier data, definately not good low level
languages but used by grownups.
Not everyone uses C. Most Interbase UDF's did not appear until Greg showed how to
do it in Delphi.
Even then, Greg had a hard time coverting alot of those UDF's over to C due to the
learning curve. The only reason he did so was to have his extensions work on *nix
environments because his office outgrew NT.
There was a time when you called Borland tech support to find out how to do
something with Interbase, you were told that you needed to write a UDF to do
that. When you asked where you could buy one that did that job, you got dead air
on the line.
Alot of users got ticked off with IB and went to inferior products because it was
simpler to work with.
I don't want to see that happen again with IB security.

Rob Schieck gave me some ideas at a TDUG meeting some 4 years ago on how he found
some solutions to Interbase security problems, so I know that the issue of
security or lack of, is not a new issue.

> All major platforms support dynamic linking. Although we
> shouldn't preclude Interbase from running on stone-axe platforms,

The question should be, should we even worry about the ability to support
loading? Security is not like a UDF. Security and it's customization should be a
intrinsic part of Interbase, not a patched on afterthought.

BUT, lets forget about the question of why we should go one way or another, lets
look at the mechanics.

If you support a third party authentication module, when does it come into play?
At connection? During Table verification? Does it replace all aspects of the
current IB security system?
If it handles anything more than initial connection, it has the potential to cause
alot of problems with Interbase. Interbase would be constantly calling the
outside authentication module from multiple threads. Any change in Interbase
could make the authentication module unstable and OS software changes constantly,
unlike it's closed source counterparts. Anyone who would want the extra features
would either have to learn to code the authentication module themselves or face
huge support costs for package updates.
If the authentication package only works at login, then it is next to useless for
anyone who wants extended security options.

If the security system is coded inside of the database using Interbases current
Trigger language, then the developer could alter the system to his/her hearts
content. By using Triggers and extra public variables, any form of security
could be implemented. Because of the complexity of the job, (and amount of work
involved) third party companies could write applications that write all the
security code for the developer. Those third party companies would not care about
any underlying api changes as they are coding in a very high level as a standard
client.

What is easier to implement? A Trigger/SP system using already tested and stable
routines, or a new security api that means that all table/procedure/trigger/view
access first needs a call to a third party module?

The nice thing is the new triggers could be used for other purposes, including,
user activity logs (written outside of transaction context in external tables).

Just a few points to ponder.

best regards

Dalton