Ivo,

> ...
> The present scheme uses Firebird's (SQL) default permission (select,
> insert, update, delete) on entities (relations), using roles to
> enforce it. Many operations, obviosly, must access a bunch of
> tables/procedures/views and this is very hard to mantain. Also,
> business rules demand control over not only 'full' entities, but over
> some fields too - who may change this or that field, etc. .
>

To get finer grained security with Firebird you can define views
and grant specific roles access to the views without granting access
to the underlying tables. You can also grant privileges to procedures
and then grant some roles access to the procedures even though those
roles don't have full access to the underlying tables (or other
procedures.)

For example, consider a personnel table that has sensitive information.
Almost no one except the most senior people in the personnel office
have full access to the table. However, you could create a view that
shows only names and internal phone numbers and grant read access to
that view to anyone in the company. You could also create a view
based on that table and a department table and grant managers
read-write access to more information about their direct reports
through the view. You could also create a procedure that allows
any user to update certain parts of his or her own records. The
procedure itself has read-write access to the records and users
have execute access to the procedure.

Regards,


Ann