Oracle Access Ctl: Please crit my advice

From: nathan lunn <nathan.lunn_at_pixie.co.za>
Date: 1998/01/27
Message-ID: <01bd2b2b$699e1dc0$293f0bc4_at_nat.pix.za>#1/1


I have a customer who has a bit of mainframe but mostly many Oracle servers, mostly on midrange HP boxes. They have also standardised pretty solidly on Netware and Microsoft. They are beginning to think about adding Tuxedo to the mix.

   I am on the point of giving them some advice which I'd like second opinions on.
Here goes: They have a home grown access ctl system which generates native Oracle grants. This system does things like look after user administrators who can further delegate rights, and synch passwords across multiple machines. (The rights on one DB are not necessarily the same as rights on another).

They asked what they should do about their access control system, - replace it with an Oracle or 3rd party product, etc etc. The system takes a lot of maint - it adds maybe 5 hours on to every front-end 'programlet'. These programlets are typically written in a VB-like language.

I told them it was far more important to straighten out the implementation
(appropriate use of SPs, roles, etc), and in fact no magic package would
cure the problems caused by their odd usages of triggers and roles.

I recommended
1) Fix the implementation - take the access logic out of triggers etc,
(detail below).

Then, once the implementation standards are fixed: 2) Consider that Access Ctl has two axes - User centric and Object Centric, with Roles more or less at the intersection. This being so, I would consider a third party package for the user-centric end - universal user IDs and passwords across Oracle, Netware NDS etc - but I would be inclined to retain the mix of Oracle native features and home grown extensions which looks after the Object centric end.

I'll explain my version of 'best practices' first and then discuss their practices:

My version:
There is no access control logic in triggers and in fact no update rights are given to users or even to roles.
Triggers are reserved for validating things which must always be true
(independent of user and context).

There is one SP for each posssible different molecular business event (EG account withdrawal - an indivisible event that accesses multiple tables). Table Update rights etc are granted only to SPs.

SPs do their own row-level control and any other context-dependant checking Received on Tue Jan 27 1998 - 00:00:00 CET

Original text of this message