Hi all,

I wanna 'listen' about your experience about applications security
schema using Firebird. We support a medium-sized application that has
based it's profile permissions on Firebird's roles. This model was
developed without much tought, I must admit, and it's error prone -
more then I would accept.

I'm in charge of designing a new model, so I tought it would be wise
to listen to other experienced developers about how the deal/dealt/are
dealing with this issue.

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. .

I'd like to keep these rules defined on the database; I mean, use
Firebird's security functions to ensure ACL's, so it make me feels
like this could improve security a little. At least, prevent
unauthorized operations even if a user tries direct access to
database, bypassing the interface. OTOH, this may be a cumbersome
work, and it may not be worth/possible. Surelly, I could leave
everything to the interface...

So, this is it. If some of you could share your experience, I'd be
glad to 'listen' :-)
It may be in private, case some of you don't wanna bloat the list or
even if the moderator think this may be an OT topic.

Some of my initials tought follows - initial, more like a 'brainstorm
section', shapeless ideas...

1. I was thinking about something like an 'universal ID', that should
identify uniquely each record on an database. Is there something like
this? If so, is it safe to use - portable across backup/restore
operations, for example? Thinking a filed like an record on db's
catalog, this may led to some place...



TIA,
Ivo

P.S.: I've made some effort to write well, but I'm not this expert in
english, it's not my native language. Forgive anything, ok? :-)