Sean,

it looks like I totally missed the point or/and we are talking about
different things.

>
> Alexandre,
>
> > > 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 ?
>
> I don't understand your comment/reply, please elaborate.
>
>
> Sean

When i am thinking about plug-in i think of the replaceable unit which
includes the minimal functionality we need. Further, as the
security/privileges features are the kind of unique features pertinent for
this application (= Firebird engine) so i suppose the security/privileges
functionalities do not depend of what place/database/file (isc4.gdb, inside
database, LDAP or whatever) your security/privileges data are kept in. So,
you need only read/write/translation drivers for realization
security/privileges features to be kept in concrete database (isc4.gdb,
inside database, LDAP or whatever). What i have missed.

Alexander

>