Re: Censoring SQL access -- ideas?

James,

A couple of thoughts....

The system offers exit points for SQL functions, QIBM_QZDA_SQL1 and
QIBM_QZDA_SQL2.

Also, if you plan for the users to sign on through JDBC with there own
user ID, you could make the tables PUBLIC *EXLCUDE and offer a view
that includes something to the effect of
create view myview
as SELECT col1, col2
from mytable
where SALE_REP = CURRENT_USER;

This would force all access through the a view which would
automatically limit the rows available to be seen. Of course the
example above is overly simplified. In reality, you're probably going
to want a UDF that checks authority so that for example, a manager can
see the data for those he manages. This particular solution is cross
platform and you should be able to find pertinate examples on the web.

HTH,
Charles



On Tue, Mar 15, 2011 at 5:57 PM, James Lampert <jamesl@xxxxxxxxxxxxxxxxx> wrote:

In one of our client-server applications, we provided customer
administrators with an exit program hook that allows extensive
censorship of data delivered to users, particularly in reports. For
example, administrators can block sales reps from even seeing, much less
modifying, accounts assigned to other sales reps, or from seeing certain
fields that should only be visible to supervisors.

For some time, we've been considering direct SQL access using
third-party client-side reporting tools going through JDBC. But since
that effectively bypasses our proprietary communication protocols, it
also bypasses our tools for censoring the data.

Any suggestions? Perhaps something with the new read-triggers?

--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.