>
>I think if the server decrypts it, then you are only solving half the
>problem. The decryption
>should happen in the client software (FB Client).
>--
>Thomas Miller
>Delphi Client/Server Certified Developer
>BSS Accounting & Distribution Software
>BSS Enterprise Accounting FrameWork
>
>http:/www.bss-software.com
>http://sourceforge.net/projects/dbexpressplus

I think I do not express what I mean...

If the encrypt routine are on the client, then EVERY application should
know how to encrypt/decrypt the data, but if it's on the server the server
will check if some user/group/role has rights for that record and then
decrypt it, the client application won't know about record encription, if
the user/group/role do not have privilegie to access that record the record
will be sent to client as null or better do not come to the client.

I think this could be seen not as "encrypt/decrypt data" but as "return/do
not return data" or "visible/not visible" to the client.

Something like this (take easy people it's just to illustrate ok ?)

Create table Customer (
ID Integer PK,
Name varchar(40),
Address varchar(40)
);

here is the uggly part...

grant select record on Customer based on USER|GROUP|ROLE

When user A inserts a record an ownership flag will be set for that record
with the specified OWNER (USER/GROUP/ROLE).

the table will look like this:

ID Name Address OwnerShip Flag (Invisible on selects)
1 ABC BRAZIL USER A ROLE ADMIN
2 XYZ JAPAN USER B ROLE FINANCE
3 DEF USA USER A ROLE ADMIN
4 GHI UK USER C ROLE ADMIN

When USER A perform a select * from customer only record 1 and 3 are
returned, when USER B send the same statment only record 2 will be return.

another SQL standard break...

grant update record on Customer.NAME based on ROLE

Only user that belongs to role ADMIN will be able to change names of
customers that were inserted by users of the ADMIN role.


grant update record on Customer.* to MANAGERS

This grant will enable the users of role MANAGERS to update any column on
that table does not matter who owns the record.

grant delete record on Customer based on ROLE

Only user that belongs to role that owns the record could delete it.

The update and delete ones could be implemented via triggers, ok.... But
the select grant for records could only be done via Stored Procs, and grant
select access only to that SP, ok for simple selects, but for joins as said
before, selectable SP's does not perform well...

The above are simple cases, I am sure this is far more complex than I said,
but my questions is:

Can these features be created ?
Or just messing up with triggers, SP's will perform equal ?

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br

----------


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.437 / Virus Database: 245 - Release Date: 06/01/2003


[Non-text portions of this message have been removed]