Bill Karwin wrote:

>
> rfm@... wrote:
> > 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'
>
> I want to repeat my opinion that OS groups should not correspond to SQL
> roles. If we want a SQL mechanism to map to OS groups, then InterBase
> could implement a groups concept (in fact it has it already, doesn't
> it?). But SQL roles ain't it.
>

Ahhh. You're right.

I guess what I'm trying to say here is that the plugins should cover
(as doug nicely describes below) authentication and some influence on
the level of authorization. I'm not trying to say that OS groups should
always map to roles. In fact, refreshing my memory on how roles work,
they don't mix well at all. What I am trying to say is that the person
who deploys the system should be able to set up how the properties of
an authorized person (their groups, for example) are mapped to their
privileges on a database. If there is an OS group 'accounting',
then there should be a simple way to say that 'users who authenticate
and are verified as a member of accounting should have so-and-so
privileges in the database.' Thus, to give a new person accounting
privileges, all they would have to do is add the new user to
the OS accounting group, without doing additional work in the database.
This is pretty much how the group mapping works on unix now, assuming
the user authenticated as a unix user. This admittedly non SQL standard
feature seems like what a lot of people would want to do a lot
of the time, especially if it work across platforms and authentication
mechanisms.

> > 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.
>
> Agreed. Can I suggest that we stop calling this plugin we've been
> discussing a "security plugin"? An "authentication plugin" would be a
> more accurate description.
>

You're right again. And up till now I have been saying authentication
until I slipped up in the comment above ;-).

> The idea of an "encryption plugin" can also be discussed, but at least
> we'll distinguish the features by using different terminology.
>
> Bill Karwin
>

--
Reed Mideke
rfm(at)collectivecomputing.com