"Claudio Valderrama C." wrote:

>
> > -----Original Message-----
> > From: rfm@... [mailto:rfm@...]
> > Sent: Viernes 28 de Abril de 2000 21:24
> >
> > 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.
>
> Sounds clever. I don't want the plug-in being called for every row of a
> table, as an example.
>

Yeah. What I had in mind would only happen at authentication time,
and could be as simple as saying that 'these OS groups correspond
to the SQL roles of the same name' Or even 'all OS groups correspond
to the SQL role of the same name'. My point being that it should not
just be 'any user who can log onto the OS can use the database'

> > 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.
>
> I can't understand how will it be possible to protect metadata without
> crashing every client package I know. If a client application needs to
> describe/query metadata, the advanced user will find a way to do the same...
> unless one assumes the application already knows ALL ABOUT the database
> schema.

I know. I also know I've heard people ask for this. I don't think it's
possibly to totally protect it. This is the same old copy protection
problem of sending ALL the required data into a hostile environment.
Anyone motivated enough is going to be able to reverse engineer it
eventually.
It might be possible to make it non-trivial, but, as I said, this
is outside of the scope of authentication plugins.

>
> > 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).
>
> I think that hooks for typical security systems are a good candidate.
> Otherwise, if someone happens to create
> yet-another-encryption-schema-for-IB, then surely more than 50% of the
> developers will want another. I don't think scrambled data packets are IB's
> task. On the other side, I'm not sure if the authentication at login time
> should be left as it's now or should be enhanced natively even if there's
> the possibility to use a third plug-in.
>

OK. What I was trying to say is that 1) some people want encryption
of all data that is sent over the wire, or of database files on disk,
2) Security plugins would >NOT< provide this. But, should someone
implement these things (and I agree with you that they probably
don't belong in the engine, but with the source, someone who felt
differently is free to act on it.), there will be a problem of
providing a keys for encryption/decryption which is somewhat similar
the problems of authentication.

> > 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
>
> This is funny. Actually I don't assemble cars, I don't have a car and I
> don't have future plans to own a car, so I should be safe from your
> prohibition. ;-) However, I assembled my computer (including some pieces I
> had to import from the US) but I didn't compile my operating system. Can I
> still use my computer? :-)
>

You can do whatever you want! If you choose to base it on the rantings
of some random person on the internet then... ummm... good luck. ;-)

> C.
>

--
Reed Mideke
rfm(at)collectivecomputing.com