----- Original Message -----
From: "Leyne, Sean" <Sean@...>
Date: Friday, September 24, 2004 6:33 pm
Subject: RE: [Firebird-Architect] Re: [Firebird-devel] User semantics vs
authentication

> Jim,
>
> > >One approach to get around the unsatisfying feeling could to
> consider> >FB$Users as having the _minimum_ information
> required/expected to be
> > >provided by all security approaches. Since the engine needs some
> basic
> > >information from which security needs to 'hang'.
> > >
> > Sean, what does the security plugin that emulates the current
> semantics
> > do? Do it replicate FB$USERS from the security database? Does
> it try
> > to intercept references to FB$USERS and redirect to the security
> > database? Replication, of course, is impossible for a readonly
> > database. The redirection, on the other hand, would be massively
> > complicated to implement, requiring a very "rich" security
> plugin API.
>
> Well that brings up a good question: What calls is a security
> plug-in
> responsible for?
>
> - Authenticating Users?
> - Providing User Information (i.e. Name)?
> - Adding/Updating User Information in FB$User table?
> - Providing User's SQL Role on connection (i.e. overriding the value
> provided in the connection 'string')?
> - Providing User's list of Security Groups on connection? (this is
> a new
> thing I'd like -- groups in addition to roles -- but that is another
> discussion)
>
> To my mind, the answer to all these questions is: Yes.

Does it sound too simple to think of security plug-in as a driver
(associated with FB-engine application) accessing secure (or may be not
secure) database through this database secure (or, again, not secure)
protocol ? May be with this approach other FB security-related things
can be easier tackled together ?

Alexander

....
>
> Sean
>