| Subject | Re: [IB-Architect] Re: Some thoughts on IB and security |
|---|---|
| Author | Jim Starkey |
| Post date | 2000-04-28T14:59:18Z |
At 02:39 PM 4/27/00 -0400, dcalford wrote:
1. A cannonical solution does not presently exist.
2. The semantics of authentication are not central to Interbase.
3. No application level code is dependent on one schema or another.
4. There is no disadvantage to a number of different schemes.
There is no reason that Interbase cannot provide an evolving set
of authentication/security modules. Making the module loadable
just means that third parties can offer added value modules without
requiring that Interbase be built on site (which, incidentally,
would essential eliminate the ability for ISC-IV or anyone else
to sell certified kits).
The architecture is simple and extensible. A security module
would be a loadable library with a single external entry point
that returns an entrypoint vector. All subsequent calls would
be made through the entry vector. Initially, the engine would
invoke the module at initialization time and to authenticate
a user. It would probably make sense to also check in on
first access (generally meaning compile time) to objects of
various types -- tables, store procedures, etc. The security
manager would return yea/nay on any call and log stuff to it's
hearts content. It could use isc4.gdb, /etc/passwd, /etc/hosts.equiv,
NT domains -- who cares?
Interbase doesn't have to solve all of the worlds problems. If we
can cleanly delegate a solution to a non-central problem, let's do it.
Jim Starkey
>value to the
>
>> 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
>product, but, security is one of the parts of application design that is verymore than
>specific to the developers needs. For alot of users, they never needed
>what IB provides today.on paying
>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
>for a third party company to make the database specific changes, or doesthem for
>themselves.I favor a loadable security module because:
>
1. A cannonical solution does not presently exist.
2. The semantics of authentication are not central to Interbase.
3. No application level code is dependent on one schema or another.
4. There is no disadvantage to a number of different schemes.
There is no reason that Interbase cannot provide an evolving set
of authentication/security modules. Making the module loadable
just means that third parties can offer added value modules without
requiring that Interbase be built on site (which, incidentally,
would essential eliminate the ability for ISC-IV or anyone else
to sell certified kits).
The architecture is simple and extensible. A security module
would be a loadable library with a single external entry point
that returns an entrypoint vector. All subsequent calls would
be made through the entry vector. Initially, the engine would
invoke the module at initialization time and to authenticate
a user. It would probably make sense to also check in on
first access (generally meaning compile time) to objects of
various types -- tables, store procedures, etc. The security
manager would return yea/nay on any call and log stuff to it's
hearts content. It could use isc4.gdb, /etc/passwd, /etc/hosts.equiv,
NT domains -- who cares?
Interbase doesn't have to solve all of the worlds problems. If we
can cleanly delegate a solution to a non-central problem, let's do it.
Jim Starkey